V2Ray 故障排查手册

无法上网：先确定连接断点

建立直连与代理两组对照

“无法上网”不是一个足够精确的故障描述。先区分所有应用都失败、只有浏览器失败，还是只有某个网站失败。退出代理客户端并恢复系统原有代理设置，访问日常可直连的网站。如果此时仍然失败，优先检查网络接入、无线连接、网关和需要网页登录的网络认证。基础网络不可用时，反复更换节点通常只会增加干扰。

直连恢复后，启动客户端并选定一个已有合法使用权限的节点。桌面端优先使用 v2rayN，安卓端使用 v2rayNG；已有 V2Fly 配置需求时再考虑 v2flyNG。不要同时运行多个接管系统流量的工具。先关闭 TUN 和复杂分流，只在已确认支持系统代理的浏览器里验证普通代理路径，缩小问题范围。

按请求经过的层级检查

一次访问通常依次经过应用代理设置、本地监听端口、路由规则、节点连接和目标服务。客户端界面能打开，只说明管理程序还在运行；节点被选中，也不代表内核已经启动。查看客户端运行日志，先找启动成功、监听地址与端口，再看发起访问时是否出现对应请求。没有请求记录时，应先查应用是否真的把流量交给了客户端。

如果日志显示本地端口绑定失败，检查是否有另一份客户端或其他程序占用端口。调整监听端口后，应用端的代理端口也必须同步修改。不要把本地入站端口误填成远端节点端口。前者负责接收本机应用请求，后者负责连接服务端，两者数值即使相同也没有自动关联。

用单变量测试收敛原因

保留同一节点，只把客户端路由临时改成明确的代理路径，再访问同一目标。若恢复，问题更可能在分流规则；若仍失败，再换一个已知可用节点，保持其他设置不变。每次记录修改项与结果，避免出现“改了很多项后突然好了，却不知道哪项有效”的情况。测试结束后恢复原模式，防止把临时全量代理当成最终配置。

若只有单个站点失败，先查看其服务状态，并用其他正常站点作对照。网页主文档可以打开而图片或登录失败，可能是附属域名走了不同路径，也可能是目标服务拒绝当前出口。此时需要观察失败请求对应的域名和路由，而不是直接判定节点整体失效。

恢复标准是能够重复验证：关闭后失败、按既定设置启动后恢复，且日志中的目标、出站与预期一致。保存这份最小可用配置，之后再逐项开启分流、TUN 或应用专用设置。连接验证的具体操作可继续阅读首次连接与真连接测速指南。

节点超时：区分端口、握手与协议

先读超时发生的位置

节点超时可能发生在域名解析、建立传输连接、TLS 握手或协议认证阶段。先从日志中找到第一条相关错误，而不是只看最后一行笼统的连接失败。记录目标主机、端口、错误类型和出现时间。同一节点在不同网络下结果不同，通常比一次测速数值更有诊断价值；测试时仍应保持节点参数与客户端模式一致。

TCPing 主要观察端口建立连接的表现，不能验证完整代理协议、认证信息和目标网站访问。端口可达但真实请求失败，可能是用户标识不匹配、传输路径错误或 TLS 参数不一致。反过来，某些测试方式失败也不代表所有真实流量都不可用。应把端口测试和客户端的真连接测试结合使用，避免把两者当成同一种指标。

核对远端地址与传输参数

先确认节点地址没有前后空格，端口在有效范围内，并与服务端提供的信息一致。再检查协议、用户标识、密码、传输类型及附加字段。WebSocket 的路径和 Host、gRPC 的服务名称都需要精确匹配；看似细小的斜杠或大小写变化，也可能造成请求落到错误服务。不要根据其他节点的填写习惯补猜字段。

地址使用域名时，需要先确认该域名当前能解析。暂时换成服务方确认的地址只能作为受控诊断，不应随意修改依赖域名验证的配置。连接地址、TLS 的 serverName 和 HTTP Host 具有不同职责：分别决定连到哪里、验证哪个服务身份、发送哪个应用层主机名，不能简单要求三者永远相同。

处理 TLS 与 REALITY 报错

证书尚未生效或已经过期的提示，可能来自设备时间错误，也可能确实是服务端证书问题。先同步系统日期、时区与时间，再核对 SNI 是否与服务端要求一致。不要把关闭证书验证当成常规修复。这样可能掩盖域名填错、证书链缺失或连接到了错误主机等根因，之后即使能访问，也无法证明配置正确。

REALITY 连接还要核对服务端公钥、shortId、serverName、指纹以及服务方要求的 flow。字段支持取决于所选内核和客户端实现，不能因为节点名称包含某个术语就推定兼容。遇到未知字段或不支持的协议提示，先查内核类型，再核对配置来源。相关差异见Xray 与 V2Fly 内核差异。

跨网络对照与服务端检查

同一设备分别使用可信无线网络和移动数据测试。若只有其中一种网络失败，检查网络认证、访问策略、地址族以及运营网络路径；若所有网络都失败，而其他节点正常，重点核对该节点本身。测试期间暂停其他下载任务，避免本机拥塞把握手时间拖长。不要无限提高超时阈值，以免掩盖明确不可达的问题。

具有服务端管理权限时，核对服务进程是否监听正确地址、主机防火墙与上游安全规则是否允许目标端口，并查看同一时间的服务日志。没有管理权限时，把脱敏后的时间、错误阶段和测试网络交给服务方确认。不要公开完整节点链接。若日志只在重连时偶发超时，但随后持续可用，还应检查休眠恢复与网络切换，而非直接重装客户端。

完成修改后，用同一目标连续进行几次轻量访问，确认握手能稳定复现，再恢复正常分流。证书问题的详细判断可参阅TLS 证书与 SNI 排查。若端口可达而认证仍失败，应回到参数核对，不要继续围绕系统代理反复调整。

订阅失败：检查获取、格式与解析

把一次更新拆成三个阶段

订阅更新包括获取地址内容、识别内容格式、把节点写入客户端三个阶段。提示更新失败时，先看是网络错误、HTTP 状态异常，还是内容解析错误。原有节点仍能使用，并不代表订阅地址可以正常获取；订阅更新成功，也不代表每个新节点都能连接。两条链路需要分别验证，不能用其中一条的结果替代另一条。

在客户端订阅分组中核对地址完整性，注意复制时遗漏查询参数、换行或混入说明文字。地址里的访问凭据属于敏感信息，不应发到公共截图或在线转换页面。不要为便于展示而改动地址编码；其中的百分号编码和分隔符可能参与服务端识别。先保存原地址副本，再重新粘贴服务方提供的完整内容。

确定更新请求实际走哪条路径

部分客户端允许订阅更新使用直连或经过当前代理。直连无法访问订阅服务时，可以在已有可用节点的前提下测试代理更新；当前节点已经失效时，继续依赖它获取订阅又可能形成循环。检查更新设置，而不是只切换浏览器代理。没有可用节点时，使用正常网络获取服务方提供的有效配置，避免随意寻找不可信的转换服务。

超时通常指向访问路径或解析问题，连接被拒绝可能是服务端端口未开放，身份验证相关状态则需要检查订阅权限。遇到请求频率限制，应按服务方规则等待，不要连续点击更新。返回服务器错误时，保留时间与状态信息，稍后重试；反复删除重建分组并不能修复远端服务异常，反而可能丢失已有可用节点。

识别返回内容而非只看扩展名

订阅可能包含编码后的分享链接集合，也可能是客户端支持的其他结构。原生 JSON 配置、单条分享链接和订阅地址不是同一类输入，应放入对应导入入口。服务端返回的登录页面、过期提示或错误页面，即使状态看似正常，也不是节点数据。解析错误时需要确认内容类型，不能仅凭地址结尾是否包含某种扩展名判断。

分享链接中的协议字段与传输参数需要客户端支持。某些导入器能够识别基本节点，却忽略额外参数，最终造成“导入成功但连接失败”。比较导入后的节点编辑页与原始参数，重点检查 TLS、安全层、传输类型和特殊协议字段。格式差异及转换边界见订阅格式与分享链接互转。

更新成功后的列表核查

先取消节点列表的搜索和筛选，再选择刚更新的订阅分组。有些客户端保留旧的活动服务器或列表选择，导致新节点存在却没有进入视野。若服务端确实返回空集合，应确认订阅权限、套餐状态或服务方的节点筛选条件，而不是盲目重复导入。同一地址建多个分组也不会增加可用性，只会让节点来源难以追踪。

保留一个仍可用的旧节点或配置备份，再进行订阅清理。自动更新可能覆盖手动修改的订阅节点，长期调整应使用客户端支持的独立配置或分组策略，不要依赖临时编辑结果永久保存。恢复后验证一个新节点的实际连接，并确认下一次更新仍能获取内容。常见导入入口疑问可在常见问题中继续查阅。

速度慢：分离延迟、吞吐与应用等待

先定义慢的是哪一个过程

网页开始显示前等待很久、文件下载持续缓慢、视频偶发停顿，是不同的现象。前者可能与 DNS、建连或握手有关，后者更依赖路径带宽、丢包和目标服务负载。先记录发生时间、使用网络、节点和目标类型。不要用某一次短连接延迟直接推算下载速度，也不要把浏览器界面里的等待时间全部归因于代理链路。

选择同一个可信目标，在相近时间分别测试直连和代理路径。测试目标应能代表实际使用场景，避免把缓存命中的静态页面与大文件下载直接比较。暂停后台同步、系统更新和其他设备的大流量任务，再观察结果。无线信号不稳定或本地上行被占满时，即使节点本身正常，也会出现明显的请求排队与响应变慢。

建立可重复的节点对照

保持网络和目标不变，只切换节点；随后保持节点不变，再切换网络。这样能够区分节点路径问题与本地接入问题。真连接测速更接近完整请求，但结果仍受测速目标、服务负载与测试时机影响。不要连续高并发测试所有节点，这本身可能占用带宽、触发服务端限制，并让测量结果失去可比性。

节点地理名称不等于真实端到端路径。距离较近不保证拥塞更少，延迟较低也不保证可用吞吐更大。若只有特定服务慢，可能与出口到该服务的路径、内容分发选择或目标服务限流有关。此时换一个出口进行对照比反复修改本地监听端口更有意义，但仍需排除该服务本身正在异常。

查看是否存在重复接管与错误分流

检查系统代理、TUN、浏览器扩展代理和其他网络工具是否同时生效。多个接管层叠加可能造成连接绕行，甚至把客户端自身的出站再次送回入站。临时保留单一路径进行测试。若关闭某一层后恢复，继续检查该层的排除规则和路由，而不是长期依靠不明来源的性能开关掩盖问题。

分流错误也会表现为“部分内容慢”。例如主页面直连而资源域名代理，可能产生额外建连；本应代理的目标被规则送到不合适的直连路径，也会反复等待超时。结合日志查看实际出站，再调整具体规则。规则通常按顺序匹配，宽泛规则放在前面可能覆盖后面的精细规则，详见路由分流配置实战。

协议与设备资源的边界

传输复用、并发连接或其他高级选项并不是通用加速按钮。不同网络、目标和服务端设置下，效果可能相反；不匹配的参数还可能导致连接重置。先恢复服务方提供的基础参数，确认稳定后再单独试验。不要为了追求更短的测试时间关闭身份验证或安全层，这与吞吐问题不是同一种调整。

同时观察设备资源。低电量模式、持续高温、CPU 长时间繁忙、磁盘空间不足，以及详细日志持续写入，都可能影响客户端响应。若界面卡顿而已有下载速度正常，问题更可能在管理界面或本机资源，而非远端带宽。关闭不必要的实时刷新和长期调试日志，再比较同样的访问过程。

若只在 TUN 下大文件卡住，小请求却正常，可考虑路径 MTU 或封装相关问题，但应先排除 DNS 与路由。仅在客户端提供相应设置且理解恢复方式时做小范围测试，不要随意照抄网络参数。最终以真实任务持续完成、连接不反复重置为恢复标准；保存测试条件，避免把某一时刻的偶然峰值当成长期性能结论。

DNS 问题：检查解析器与请求路径

区分节点域名和目标域名

DNS 至少涉及两个不同对象：客户端要先找到节点服务器，代理请求还可能需要解析目标网站。节点域名无法解析时，连接在进入远端协议前就会失败；目标域名解析异常时，则可能出现节点已经连接、部分网站仍无法打开的现象。先从日志确认失败域名是谁，不要看到解析报错就立刻把所有 DNS 设置全部替换。

还要确定解析由谁完成。应用可能使用系统解析器，也可能启用自己的加密 DNS；代理内核也可以具有独立 DNS 设置。SOCKS 请求还存在由应用先解析，或把域名交给代理端处理的区别。因此，系统命令查询正常，只能证明该次查询路径正常，不能直接证明浏览器或内核采用的解析路径也没有问题。

读取系统查询结果

在 Windows、macOS 或 Linux 的终端中，可以用下面的查询观察系统默认解析器对示例域名的响应。若系统没有该工具，使用系统提供的网络诊断界面即可，不必额外安装不熟悉的工具。命令成功只说明获得了结果，仍要注意返回的是 IPv4、IPv6 还是明确的不存在响应，以及是否出现查询超时。

nslookup example.com

排查实际故障时，应查询日志里的目标域名；示例域名只是用于展示语法。与代理客户端日志交叉核对：系统查询成功但内核查询失败，优先检查内核 DNS 的地址与出站路径；系统查询本身就超时，则检查本地网络、路由器或所选解析服务。不要把证书错误误判成解析失败，二者发生阶段不同。

识别解析循环与地址族问题

如果连接某个 DNS 服务需要先使用代理，而代理节点的域名又必须依赖这个 DNS 才能解析，就可能形成启动循环。应给节点域名保留可达的引导解析路径，并确保 DNS 服务本身不会被错误路由送回客户端。配置加密 DNS 时尤其要区分服务的域名解析与后续请求，不能只填写一个地址就认为全部依赖已解决。

以下片段展示 V2Ray 内置 DNS 的基本结构和仅查询 IPv4 的诊断思路，不是一份完整代理配置。它依赖当前网络能够访问所列解析服务；不同内核的字段支持与 DNS 路由方式需要分别确认。使用图形客户端时，优先通过对应设置项调整，避免直接修改随后会被客户端重新生成的运行文件。

{
  "dns": {
    "servers": [
      "1.1.1.1",
      "8.8.8.8"
    ],
    "queryStrategy": "UseIPv4"
  }
}

仅在 IPv6 路径明显异常时，临时限制地址族来做对照。如果限制后恢复，继续检查网络的 IPv6 可达性、路由和客户端配置，而不是把禁用 IPv6 当作所有设备的固定答案。域名同时返回多个地址时，不同应用可能选择不同结果，因此同一设备上的表现也可能不同。

处理缓存与浏览器独立设置

修改 DNS 后，旧缓存可能让测试继续访问原地址。关闭并重开测试应用，按操作系统提供的方法清理解析缓存，再重新发起请求。浏览器的安全 DNS、应用内部缓存和系统缓存并不总是同步清除。排查时记录清理了哪一层，避免在同一页面反复刷新却以为已经使用新解析结果。

最后把目标域名、查询方式、结果地址族和实际出站对应起来。若只有一个域名失败，检查是否存在 hosts 覆盖或专用分流；若所有域名失败但已建立的连接仍能传输，解析层的可能性更高。恢复后重新开启必要的浏览器设置，并确认节点启动与首次访问都能独立完成，避免留下只在缓存存在时才可用的配置。

系统代理失效：核对应用与本地入站

明确系统代理的覆盖范围

系统代理通常是向支持该设置的应用提供代理地址，并不是把设备所有网络连接自动改道。浏览器可用而某个应用直连，可能只是该应用没有读取系统代理。命令行工具、后台服务、部分游戏或自带网络组件的程序，还可能使用独立代理配置。先确认应用支持哪种入口，再决定使用系统代理、应用内代理还是 TUN。

v2rayN 中的系统代理状态与路由模式也不是同一概念。前者决定应用是否被引导到本地端口，后者决定进入内核的请求走哪个出站。选择某种分流模式，不会自动替所有应用设置代理；系统代理开启，也不保证路由一定选择代理出站。两层状态要分别核对，不能只看托盘菜单的一项文字。

检查监听地址、端口与协议

先在客户端设置和启动日志中确认实际监听地址及端口。仅供本机使用时，回环地址通常更合适。应用填写的 HTTP 代理端口需要对应支持 HTTP 的入站，SOCKS 入口则需要相应协议支持。混合端口是否可用取决于客户端与内核设置，不应仅凭其他教程的端口数值推断。

下面的片段用于解释两个独立入站。它不是节点配置，也不包含远端出站；端口只是示例，必须以本机设置为准。应用在这类配置下应根据协议选择对应端口。若客户端已经生成了监听配置，不要直接把片段追加进去，避免重复绑定导致整个内核启动失败。

{
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    },
    {
      "tag": "local-http",
      "listen": "127.0.0.1",
      "port": 10809,
      "protocol": "http",
      "settings": {}
    }
  ]
}

检查平台设置是否被覆盖

Windows 中查看当前用户的代理设置，区分手动代理与自动配置脚本。某些应用读取的网络栈设置不同，不能假设浏览器可用就代表后台服务也使用相同代理。退出客户端后若系统仍指向本地端口，而该端口已经没有程序监听，会出现直连网络正常、应用却全部报连接失败的残留状态。

macOS 的代理设置与当前网络服务有关。切换无线网络、有线连接或新增网络服务后，应检查当前实际使用的服务，而不是只看以前修改过的那一项。Linux 桌面环境的代理设置也未必覆盖终端与系统服务；应用读取环境变量时，还要检查旧进程是否保留了启动时的值。设置改变后重新启动测试应用更可靠。

排除扩展代理与绕过规则

浏览器代理扩展、自动配置脚本、应用内代理与系统设置可能互相覆盖。暂时关闭额外代理来源，只保留一种入口，观察访问时是否产生内核日志。若仍无日志，检查应用的绕过列表，目标可能被明确要求直连。若已有日志但走错出站，应转查路由规则，不要继续反复开关系统代理。

TUN 可以覆盖更多类型流量，但需要系统权限、虚拟网络接口和正确路由，不能作为系统代理不明原因失效时的盲目替代。先验证普通入站路径，再单独启用 TUN。恢复标准是目标应用产生预期请求日志、命中正确出站，并且退出客户端后系统网络设置能够按预期还原。其他模式疑问可对照使用文档中的连接步骤。

客户端崩溃：区分界面、内核与配置

先确认退出的是哪个进程

窗口消失、界面无响应和内核退出是三类不同问题。窗口关闭后托盘图标仍在，可能只是最小化到托盘；管理界面正常但连接全部中断，可能是内核启动失败；整个程序直接退出，则应检查系统错误记录和客户端日志。先记录发生动作，例如启动、切换节点、更新订阅或休眠恢复，才能缩小触发条件。

不要在第一步删除配置目录。先退出程序并确认相关进程结束，再备份配置、订阅分组与必要的用户设置。日志可以保留，但分享前应脱敏。若程序无法进入界面，仍可通过系统提供的文件管理与诊断工具查看最近修改的文件和应用错误记录；不要从不明来源下载所谓修复脚本。

核对系统、架构与安装方式

重新安装前，先确认安装包与系统及芯片类型匹配。桌面端 v2rayN 的桌面版和经典 WPF 版具有不同界面实现，系统要求应以实际安装包说明为准。缺少运行环境、系统过旧或架构不匹配，可能导致程序在显示主窗口之前退出。安装入口与平台选择见客户端安装包，不要依据文件名片段自行猜测兼容性。

检查安装目录是否可写、用户目录是否有足够空间，以及程序是否被放在受限制的网络位置或临时目录。需要写入配置的程序，如果无法创建文件，可能表现为设置丢失、更新失败或反复退出。先把程序放在符合其安装方式的本地位置，再测试；不要长期以最高权限运行来掩盖目录权限问题。

读取第一条启动错误

内核日志中，端口占用、配置解析错误、无法读取资源文件和不支持字段往往有明确提示。先解决最早出现的有效错误，后续连接失败可能只是连锁结果。检查是否同时启动了两份客户端，或旧进程仍占用监听端口。关闭重复实例后重新启动，比随意更换整套网络参数更容易验证原因。

手动编辑配置后出错，应优先回退最近一次改动。JSON 中的逗号、引号、数组与对象括号都必须符合语法；配置语法有效，也不代表字段一定受当前内核支持。图形客户端通常会重新生成运行文件，因此直接修改生成文件可能在下次启动时被覆盖。长期定制应使用客户端明确支持的配置入口。

用隔离配置复现问题

在有备份且理解客户端数据位置的前提下，用独立的测试数据目录或重新命名原数据目录，让程序以初始设置启动。不要让测试实例与原实例同时运行。如果初始状态正常，逐步恢复一个订阅、一个节点和必要设置；恢复某一项后故障重现，就能够把范围缩小到对应数据或功能。

若空配置也崩溃，重点检查系统兼容性、运行环境、安装文件和安全软件的拦截记录。发现拦截时，应先阅读事件详情并确认来源，不要直接关闭整个防护体系。若仅开启 TUN 时失败，检查权限与虚拟接口；普通代理能够运行，说明不必把所有节点数据清空重建。

休眠后卡住、运行很久才退出等问题，还要观察内存、句柄、磁盘和网络切换。缩小自动测速、频繁刷新或定时更新等任务范围，判断是否由特定操作触发。恢复后至少验证启动、导入、连接和正常退出四个环节，再恢复自动任务。整理反馈时提供客户端名称、系统架构、复现步骤与脱敏错误，不要只写“打不开”，也不要上传完整配置数据库。

安卓专项：VPN 授权、后台与应用分流

区分本地 VPN 接管与远端连接

v2rayNG 和 v2flyNG 可以通过 Android 的 VPN 服务接口接收应用流量。系统显示 VPN 标识，只能说明本地接管服务处于活动状态，不能证明远端节点已经握手成功。先查看客户端日志和真实访问结果，再判断故障层级。首次启动时需要处理系统授权；授权被拒绝或被其他服务替换，客户端就无法按预期接管流量。

同一用户空间通常只能有一个活动 VPN 服务。另一个 VPN、安全类网络工具或使用同类接口的应用，可能抢占当前连接。先停用其他接管服务，再重新启动需要测试的客户端。系统中的始终开启 VPN 与阻止未通过 VPN 的连接，也可能让客户端未启动时整机无法联网；调整前记录原状态，测试后按使用需求恢复。

安装包与内核选择

安装时按设备架构选择 arm64 或通用包。较新的主流手机通常使用 arm64，但不能只凭购买年份作唯一判断；不确定时查看系统或设备信息，或使用提供的通用包。安装失败还可能涉及存储空间、安装来源权限、已有应用签名差异等原因，不要把所有安装错误都归为网络问题。

安卓端优先考虑采用 Xray 内核的 v2rayNG；需要 V2Fly 配置兼容时可选择 v2flyNG。两者不是单纯换个界面的同一应用，协议特性和字段支持需要按内核判断。包含 REALITY 等特性的节点应先确认对应支持情况。安装入口见Android 客户端下载，迁移前备份必要配置，不要假设应用数据能够直接互换。

处理锁屏断线与后台终止

前台可用、锁屏一段时间后失效，优先检查电池优化、后台运行和后台数据限制。不同设备的设置名称不同，应在系统应用管理中找到对应客户端，允许必要的后台活动，并按设备提供的方式排除过度节电。不要一次关闭所有应用的节电限制，只对需要持续连接的客户端做最小范围调整。

还要区分进程被终止与网络空闲连接失效。前者常见表现是客户端通知或 VPN 标识消失，后者可能仍显示连接但首次请求需要重连。查看恢复前后的日志，再决定处理后台策略还是节点连接。屏幕亮起后立即恢复，也可能是系统重新允许联网，不能仅凭这一现象断定服务端主动断开。

检查按应用代理与网络切换

只有部分应用不能访问时，检查按应用代理的包含或排除模式。两种模式含义相反：选择列表中的应用，可能表示只代理它们，也可能表示绕过它们。新增或重装应用后，列表与实际应用标识也可能需要更新。先选一个明确的测试应用，确认其请求进入日志，再逐步恢复完整列表。

无线网络切换到移动数据后，旧连接可能因地址变化而失效。停止再启动连接，观察是否恢复；若每次切换都失败，检查客户端网络变化处理与系统后台限制。同时检查数据节省模式、移动网络权限和当前接入点。只有某个无线网络失败时，还应先完成网页认证，避免把接入认证页面当成节点或 DNS 故障。

手机上的 VPN 接管不必然覆盖共享热点中其他设备的流量，手机浏览器正常也不能证明热点设备已走同一路径。不要为解决热点问题随意开放本地监听或扩大访问范围。恢复后依次验证前台访问、锁屏后访问、无线与移动数据切换、停止连接后的正常直连。若仍有异常，把症状对应回本页的节点、DNS 或订阅章节；若需要重新建立基础流程，则返回使用文档，从导入与连接验证重新检查。