V2Ray 故障排查大全

“连接后无法上网”不等于节点本身失效。客户端显示已启动，只能说明本地进程完成初始化，不能证明远端握手、DNS 查询和应用流量都已经成功。第一步应明确范围：是所有网站都打不开，还是只有域名打不开；关闭系统代理后能否恢复直连；同一节点在另一网络中是否可用；只有浏览器异常，还是命令行和其他应用也异常。四个问题可以把故障快速缩小到网络、解析、代理接入或节点配置。

先恢复基线，再逐层启用

在 v2rayN 中先关闭系统代理与 TUN 模式，保留客户端进程运行，然后确认普通直连网络是否正常。若直连也失败，应先处理路由器、网络认证、网卡或本地 DNS，不要继续修改 V2Ray 配置。直连恢复后，选择一个已知可用的节点，仅开启系统代理，并把路由切换为全局代理做短时测试。全局模式可用而规则模式不可用，故障通常位于路由规则、GeoSite 数据或 DNS 分流；全局模式仍不可用，则继续检查节点和本地代理端口。

1. 退出其他代理、加速或流量接管程序，避免多个程序同时修改系统代理与路由表。
2. 检查系统时间和时区。时间偏差会导致 TLS 证书判断错误，也可能使带时间字段的认证失败。
3. 在客户端中重新选择节点并启动核心，确认日志中出现本地入站监听，而不是启动后立即退出。
4. 只开启一种接入方式。普通浏览器测试优先使用系统代理，不要同时开启系统代理和 TUN。
5. 分别访问一个纯 IP 目标和常用域名，判断问题是否集中在 DNS。

Windows 可以用下面的命令确认本地端口是否处于监听状态。端口号应以 v2rayN 当前设置为准，常见配置会同时存在 SOCKS 与 HTTP 入口。若命令没有输出，说明核心没有监听该端口，可能是端口冲突、配置生成失败或核心进程已退出。

netstat -ano | findstr LISTENING
curl.exe -x http://127.0.0.1:10809 https://example.com/

第二条命令用于绕过系统代理设置，直接向本地 HTTP 代理发起请求。能够返回页面响应，说明“应用到本地代理再到节点”的基本链路成立，问题更可能在系统代理开关或浏览器自身设置；若提示无法连接本地端口，应检查入站端口；若已经连接本地端口但远端失败，则查看核心日志中的握手、证书、地址或路由信息。

识别配置错误与网络阻断

节点配置需要逐项核对服务器地址、端口、用户标识、传输方式、TLS 开关、服务器名称与路径。VMess、VLESS、Trojan 的字段含义不同，不能仅替换地址和端口后继续使用旧传输参数。若订阅提供的节点由客户端自动生成，优先重新更新订阅并重新选择节点；手工录入时，应与提供方给出的完整参数逐字段对照，尤其注意 WebSocket 路径前导斜线、gRPC 服务名以及 TLS 的服务器名称。

若同一配置在移动网络可用、家庭网络不可用，应检查家庭网络是否存在 DNS 劫持、路由器过滤、双层代理或异常的 IPv6 路由。反过来，家庭网络可用而移动网络失败，则需要检查移动端后台限制、专用 DNS 和当前接入点。不要根据一次请求就认定网络侧故障，应至少在两个不同网络、两个不同节点之间交叉测试。交叉结果能区分“特定节点异常”“特定网络异常”和“客户端全局配置异常”。

连接恢复后，应把路由从全局模式切回实际使用的规则模式，再验证国内直连、代理目标与局域网地址是否分别走向预期出口。有关模式差异可参考系统代理、全局模式与绕过大陆模式的区别。若切换后再次断网，说明基础连接没有问题，下一步应集中检查路由规则和 DNS，而不是重新安装客户端。

超时表示某一层在规定时间内没有得到有效响应，但日志中的“timeout”可能对应 TCP 建连、TLS 握手、协议认证、DNS 查询或目标站点响应。处理前先记录超时发生的位置和持续时间。如果多个节点同时超时，应优先检查本地网络、系统时间、DNS 和客户端核心；如果只有单个节点超时，优先检查该节点的地址、端口、传输参数与远端状态。

用交叉测试划分责任边界

建立一个二乘二测试：同一节点分别在当前网络和另一网络测试，再在当前网络测试另一个节点。节点换网后仍失败而其他节点正常，问题集中在该节点；当前网络下所有节点失败、换网恢复，问题集中在本地网络路径；所有组合都失败，则应检查客户端通用设置或订阅参数。交叉测试应保持客户端版本、路由模式和 DNS 配置不变，否则无法比较结果。

“连接被拒绝”与“连接超时”含义不同。被拒绝通常说明数据包到达了目标主机，但指定端口没有服务监听，或中间设备主动返回拒绝；超时则可能是数据包没有到达、返回路径中断或服务没有回应。前者应先核对端口和远端服务，后者应先检查地址解析、网络路径和防火墙。日志里若连续出现短间隔重试，不要让客户端长时间反复连接，应暂停节点，避免重试信息淹没真正的首个错误。

TLS 与传输参数的核对顺序

启用 TLS 的配置至少涉及远端地址、服务器名称和证书匹配。服务器地址可以是 IP，也可以是域名；服务器名称通常用于 TLS 握手，二者不一定相同。手工编辑时把服务器名称留空、误填成节点备注或使用错误域名，都会造成握手失败。若配置使用 WebSocket，还要检查 Host 与 path；使用 gRPC 时检查 serviceName；使用 REALITY 时核对公钥、短标识、服务器名称和流控字段。不要通过关闭证书验证来掩盖字段错误，这会使故障表象消失，却无法证明配置正确。

IPv6 也会造成不稳定的超时。域名可能同时返回 IPv4 与 IPv6 地址，而当前网络只有不完整的 IPv6 连通性。表现通常是首次连接等待较长时间，随后回退到 IPv4，或同一节点时好时坏。可暂时在客户端 DNS 或系统网络中优先 IPv4 进行验证，但不应直接删除所有 IPv6 配置。确认原因后，再根据实际网络能力选择优先策略。

节点能够建立连接但访问特定网站超时，应检查目标域名是否被错误分流到直连、是否命中阻断规则，以及 DNS 返回地址是否与路由规则一致。可以临时把目标域名加入明确的代理规则并置于宽泛规则之前。规则修改后重启核心或重新加载配置，再通过日志确认命中的出站标签。有关 domain、ip 与 geosite 的顺序，可继续阅读V2Ray 路由规则配置实战。

完成修复后至少验证三类请求：节点服务器域名解析、普通 HTTPS 站点访问、持续数分钟的连接稳定性。只有一次握手成功不足以说明问题消失。若固定时间间隔后断开，应继续检查网络切换、路由器连接跟踪、移动端省电策略与服务端空闲超时，而不是单纯增加客户端连接超时时间。

订阅更新包含三个独立步骤：客户端请求订阅地址、服务器返回内容、客户端解析并写入节点列表。失败提示往往只显示最后结果，因此要判断请求是否真正发出、HTTP 状态是否正常、返回内容是否属于客户端支持的格式。节点列表为空不一定是网络问题，也可能是订阅内容过期、地址复制不完整、返回登录页面、筛选规则隐藏全部节点，或者解析时遇到格式错误。

先检查地址本身

重新复制订阅地址时，应从来源页面使用完整复制操作，不要手工截取。重点检查地址开头的协议、路径、查询参数和末尾字符。聊天软件或文档编辑器可能把连接符替换为其他符号，也可能在末尾加入句号、换行或空格。地址中若包含临时凭据，不应放入公开日志或截图。确认系统时间准确，因为部分订阅服务会判断请求时间，时间偏差也会影响 HTTPS 证书校验。

在 v2rayN 中可以先单独更新指定订阅，不要同时更新全部分组。这样能够确认失败属于单个地址还是全局网络。如果指定订阅失败，保留错误提示并查看日志中的 HTTP 状态；如果全部订阅失败，检查系统代理、直连网络、DNS 和客户端是否把订阅请求错误地送入一个尚不可用的节点。部分场景需要先直连获取订阅，另一些场景需要通过已有代理获取，应根据订阅来源的实际可达性选择更新方式。

curl.exe -L --connect-timeout 15 "https://example.com/subscription?token=xxxx" -o subscription.txt

命令中的地址仅展示请求结构。实际检查时不要在公共终端记录或分享完整凭据。返回文件如果是 HTML 登录页、错误说明或空文件，客户端自然无法生成节点；若返回一长段编码文本或节点链接，再检查客户端是否支持对应格式。HTTP 301、302 表示重定向，命令中的 -L 会跟随跳转；401、403 通常与凭据、权限或请求条件有关；404 表示路径不存在；429 表示请求过于频繁，应停止重复刷新并稍后再试；5xx 则更可能是订阅服务端临时异常。

内容已下载但解析失败

日志显示下载成功、节点仍为空时，应检查订阅分组的筛选条件。正则筛选如果写得过窄，可能把所有节点排除；去重规则也可能把名称相近的节点合并。先停用筛选并重新更新，确认原始节点是否出现。若出现，再逐条恢复筛选条件。节点名称含括号、加号或其他正则字符时，需要注意这些字符在表达式中有特殊含义，直接复制名称不一定按字面匹配。

订阅返回格式和客户端内核是两个概念。v2rayN 负责管理桌面配置，v2rayNG 使用 Xray 内核，v2flyNG 使用 v2fly 内核；同一订阅中的某些传输或协议字段，可能只被部分客户端识别。更新成功但特定节点导入失败时，应查看解析日志并确认节点类型，而不是反复删除订阅。Android 上可分别用 v2rayNG 与 v2flyNG 做兼容性对照，但不要同时启动两个本地 VPN 接管。

当订阅地址已失效，应从原提供渠道重新获取，而不是自行修改 token 或猜测路径。把旧地址删除后立即新建，也不会修复服务端权限问题。若浏览器能够获取内容而客户端失败，检查客户端的用户代理限制、系统代理路径和 TLS 日志；若客户端成功但浏览器失败，可能是浏览器扩展、缓存或独立代理设置造成差异。可参考下载页常见问题核对客户端选择，再回到本章按请求、响应、解析三个阶段定位。

修复后不要只看“更新成功”提示，还要确认节点数量合理、更新时间变化、旧节点是否按预期替换，并随机打开两个节点核对服务器地址和协议字段。随后选择一个节点执行连接测试。订阅成功只证明配置数据进入客户端，不代表其中每个节点都能建立网络连接；连接失败时应转到上一章继续检查超时和握手阶段。

速度问题需要先区分带宽不足、延迟偏高、丢包、单连接限制和客户端资源瓶颈。网页打开慢不等于下载带宽低，测速结果高也不代表交互延迟稳定。排查时固定测试时间、目标文件、网络和节点，至少重复三次，避免把目标站点拥塞或短时无线干扰误判为客户端问题。不要同时运行多个测速工具，它们会竞争带宽并改变测试结果。

建立直连与代理两组基线

先关闭代理，在同一网络测试直连延迟、下载速度和丢包，再启用一个节点重复测试。若直连本身波动明显，应优先处理 Wi-Fi 信号、路由器负载、网线协商或运营网络。若直连稳定、所有节点都慢，检查本地 CPU、杀毒软件网络扫描、TUN 驱动和 MTU；若只有单个节点慢，则更可能是节点线路、远端负载或节点到目标站点的路径问题。

测速应覆盖小请求和持续传输。小请求用于观察 DNS、握手与首字节时间，持续传输用于观察稳定带宽。网页首次打开慢、后续资源正常，常见原因是 DNS 或 TLS 建连耗时；下载开始快、随后下降，可能与远端限速、无线拥塞、丢包重传或 CPU 达到上限有关；速度呈周期性归零再恢复，应检查网络切换、移动端省电和连接重建。

检查传输、MTU 与路由

TUN 模式会增加虚拟网卡和路由处理环节。系统代理速度正常而 TUN 明显变慢时，应检查虚拟网卡驱动、严格路由、IPv6 与 MTU。MTU 过大可能导致分片或部分路径丢包，表现为小请求正常、大响应停顿。可以逐步降低 TUN 接口 MTU做对照，但每次只调整一个档位，并在修改后重新连接。不要把 MTU 设置得过低，额外分片会降低效率。

规则分流也会造成“部分网站慢”。目标域名可能直连，而页面中的图片、脚本或接口走代理，两个出口的 DNS 和连接状态不同，最终表现为页面等待。打开核心访问日志，观察同一页面相关域名命中的出站标签。临时全局代理后速度恢复，说明节点本身可用，应修正域名规则；全局模式仍慢，则继续检查线路和传输参数。GeoIP 与 GeoSite 数据过期也会造成规则归类偏差，更新方式可参考GeoIP 与 GeoSite 数据库更新说明。

客户端核心加密、TLS 与流量转发会占用 CPU。低功耗设备或路由器上，单核达到上限时带宽会被处理能力限制。桌面端可在传输期间观察 CPU 和内存，确认是核心进程持续占用，还是浏览器、同步程序或安全扫描占用资源。若 CPU 充足但速度仍低，不应通过增加并发或连接数盲目解决，因为高并发可能进一步加剧丢包。

无线网络测试尽量靠近接入点，并关闭大流量同步任务。若 2.4 GHz 与 5 GHz 表现差异明显，先处理本地无线环境。跨网络比较时要记录网络类型和时间段，不应把不同条件下的结果直接归因于协议。完成调整后，恢复原有路由模式，分别测试浏览、视频、大文件与长连接；若只有某一种业务异常，再围绕对应目标和连接模型继续分析。

DNS 问题常表现为域名打不开、同一网站时好时坏、代理连接成功但目标被错误分流，或者浏览器与命令行得到不同结果。排查重点不是简单更换一个 DNS 地址，而是确认“谁发起查询、查询发往哪里、返回哪个地址、该地址如何进入路由匹配”。系统 DNS、客户端内置 DNS、浏览器安全 DNS和 TUN 劫持可能同时存在，多条解析路径会造成结果不一致。

先判断是否为解析故障

关闭客户端后使用系统命令查询目标域名，再开启客户端重复查询，并记录返回的 IPv4、IPv6 与解析耗时。若系统查询失败但指定公共 DNS 能成功，问题可能在本地 DNS 或路由器；若命令行成功而浏览器失败，应检查浏览器缓存、独立 DNS 设置和扩展；若解析成功但访问失败，继续比较日志中实际连接的地址是否与查询结果一致。

nslookup example.com
nslookup example.com 1.1.1.1
ipconfig /flushdns

nslookup 用于观察系统或指定服务器的查询结果，刷新系统缓存只会清理操作系统维护的记录，不会清除浏览器和客户端内部缓存。执行刷新后应完全关闭测试应用再重新打开。若客户端启用了 FakeDNS，返回的可能是保留地址，这属于映射机制的一部分，不能直接按普通公网地址判断。此时应查看 FakeDNS 映射是否被核心接管，以及目标流量是否仍进入对应代理入口。

理解 DNS 与路由的先后关系

路由规则既可以按域名匹配，也可以按解析后的 IP 匹配。若域名在进入核心前已由系统解析，核心可能只看到 IP，域名规则就无法按预期工作；如果核心负责解析，则可保留域名信息并根据规则选择不同 DNS 和出站。配置时需要明确解析策略，不要同时依赖互相冲突的系统 DNS、浏览器 DNS 和客户端 DNS。

下面是一个简化的 Xray 风格 DNS 片段，用于说明服务器列表与查询策略的结构。具体地址和策略应根据所在网络调整。修改前应保留原配置，并确认图形客户端是否会在保存设置时重新生成该文件。

{
  "dns": {
    "servers": [
      {
        "address": "1.1.1.1",
        "domains": [
          "geosite:geolocation-!cn"
        ]
      },
      {
        "address": "223.5.5.5",
        "domains": [
          "geosite:cn"
        ]
      }
    ],
    "queryStrategy": "UseIPv4"
  }
}

queryStrategy 控制返回地址族。将其设为仅 IPv4 可用于验证 IPv6 路径是否异常，但不应在没有测试的情况下长期固定。若网络具备稳定 IPv6，保留双栈可以获得更合适的路径；若 IPv6 只有地址而没有可靠出口，域名解析出 AAAA 记录后可能产生长时间等待。判断依据应是系统路由和连通测试，而不是仅看网卡是否显示 IPv6 地址。

分流 DNS 需要让解析出口与访问出口保持逻辑一致。例如按规则直连的域名通常使用可在直连网络稳定访问的 DNS，代理域名则可由核心通过代理出口查询。若先用本地 DNS 得到一个地区化地址，再把访问送到远端代理，目标可能返回不合适的内容节点；反过来，所有域名都通过远端解析，也可能让本地服务解析到不必要的远端地址。规则应以实际访问路径为准。

如果只有少量域名异常，可先用明确的域名规则和指定 DNS 做最小验证，不要立即重写整套 DNS。确认规则有效后，再扩大到 geosite 分类。数据库更新后也要检查规则名称是否仍存在、客户端是否加载了正确文件。有关数据文件位置、加载机制和更新后的验证方法，可阅读GeoIP 与 GeoSite 数据库怎么更新。

最终验证应包含系统查询、客户端日志和实际访问三部分：查询结果是否稳定，日志是否显示预期 DNS 服务器与出站，浏览器是否连接到对应地址。三者一致才说明解析链路清晰。若日志中完全看不到目标域名的 DNS 请求，说明查询可能发生在核心之外，应回到系统、浏览器或 TUN 接管设置继续定位。

系统代理本质上是向操作系统写入代理地址与端口，只有主动读取这些设置的应用才会使用。客户端显示“系统代理已开启”，并不表示所有进程流量都被接管。浏览器通常支持系统代理，部分命令行工具、游戏、商店程序和自带网络栈的软件可能忽略它。遇到某个应用不生效时，先确认其他应用是否正常，再判断是系统设置写入失败，还是目标应用没有使用系统代理。

核对本地入口与系统设置

在 v2rayN 中记录 HTTP 与 SOCKS 入站端口，然后查看系统代理是否指向 127.0.0.1 和正确端口。端口不能被其他程序占用，也不能误填为远端节点端口。使用前一章的 netstat 命令确认监听进程，再用显式代理参数测试。显式代理成功而浏览器失败，说明核心和节点正常，问题集中在系统代理写入、浏览器策略或扩展。

curl.exe -x http://127.0.0.1:10809 https://example.com/
curl.exe --socks5-hostname 127.0.0.1:10808 https://example.com/

第一条通过 HTTP 代理测试，第二条通过 SOCKS5 并让代理端解析域名。两个端口必须按客户端实际配置替换。HTTP 成功、SOCKS 失败时检查 SOCKS 入站；SOCKS 成功、HTTP 失败时检查 HTTP 入站或混合端口。两者都成功而目标应用不生效，通常意味着应用没有读取系统代理，或应用内部配置覆盖了系统设置。

浏览器代理扩展可能覆盖系统代理。排查时临时停用扩展，并关闭所有浏览器进程后重新打开。部分浏览器的安全 DNS 会独立发起解析，即使 HTTP 流量经过系统代理，DNS 仍可能走另一条路径，产生域名解析差异。企业策略、家庭安全软件和网络过滤程序也可能改写代理设置，应检查系统设置是否在开启后立即被还原。

区分系统代理与 TUN

系统代理适合支持 HTTP 或 SOCKS 代理的应用，修改范围清晰，出现问题时容易回退。TUN 模式通过虚拟网卡与路由接管更多流量，适合不读取系统代理的程序，但会引入 DNS 劫持、路由优先级、MTU 和驱动兼容问题。不要因为单个应用忽略系统代理就立刻长期启用 TUN，先检查该应用是否提供独立代理设置；确实需要全局接管时，再按最小配置启用 TUN。

TUN 开启后完全断网，应先关闭系统代理，避免两条接入路径重叠，再检查虚拟网卡是否创建成功、默认路由是否写入、局域网网段是否被错误代理。远程桌面、局域网共享和路由器管理地址应保留直连规则，否则启用 TUN 后可能失去本地连接。存在其他虚拟网卡时，应检查路由优先级，尤其是容器、虚拟机和企业网络软件创建的接口。

如果退出客户端后仍无法浏览，进入系统网络设置关闭手动代理，并检查自动配置脚本是否仍指向旧地址。随后重新打开浏览器。若代理设置不断自动恢复，检查启动项和其他网络工具。v2rayN 中也应使用“清除系统代理”而不是只关闭窗口，因为关闭窗口可能仅最小化到托盘，核心仍在运行。

完成修复后，分别验证一个遵循系统代理的浏览器、一个带显式代理参数的命令行请求以及原先异常的应用。三者结果可以说明问题位于系统设置还是应用自身。关于三种代理方式的流量范围和选择，可继续查看系统代理、全局模式与绕过大陆模式的区别。

客户端窗口关闭、核心进程退出和界面无响应是三类不同问题。窗口崩溃可能与图形运行库、配置数据库或界面组件有关；核心退出通常由生成的配置无效、端口冲突、内核文件不可执行或系统权限导致；界面无响应则可能是大量节点、日志刷新、订阅解析或安全软件扫描造成。排查前先确认退出的是图形客户端还是核心进程。

保存日志与复现条件

不要在首次崩溃后立即清空配置或反复重装。先记录崩溃发生的动作，例如启动核心、更新订阅、打开设置、切换 TUN 或导入配置。保存客户端日志、核心日志和系统事件时间点，并记录当时使用的路由模式和节点类型。可重复复现的问题比偶发崩溃更容易定位；若每次都在同一动作发生，优先检查该动作读取的配置或系统组件。

v2rayN 启动后核心立即退出时，先关闭系统代理，避免本地端口失效造成断网。查看核心输出的第一条错误，常见类别包括 JSON 语法错误、字段类型不正确、路由标签不存在、入站端口占用和文件访问失败。后续大量重试信息通常只是结果。若使用图形界面生成配置，可切回默认路由和默认 DNS，再选择一个普通订阅节点，判断是否由自定义配置引起。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "socks-in",
      "port": 10808,
      "listen": "127.0.0.1",
      "protocol": "socks"
    }
  ]
}

以上片段展示一个合法的 SOCKS 入站结构，可用于对照字段类型和 JSON 标点，不是完整的出站配置。JSON 不允许尾随逗号，字符串必须使用双引号，端口应为数字。手工配置验证失败时，先恢复客户端自动生成的配置，不要在多个位置重复编辑。图形客户端可能在启动时覆盖临时文件，直接修改生成文件通常不会成为长期设置。

端口、权限与运行环境

端口冲突会使核心无法监听。使用 netstat -ano 查到占用进程后，应确认该进程用途，而不是直接结束所有网络进程。可以在客户端中调整本地入站端口进行验证。若新端口可以启动，说明原端口已被占用；随后决定保留新端口，或关闭冲突程序。修改端口后，系统代理和应用内代理地址也必须同步，否则会继续连接旧端口。

桌面客户端依赖对应运行环境。窗口完全无法打开、系统事件记录运行库错误时，应根据Windows 安装包页面重新确认桌面版与经典 WPF 版的适用条件。不要混用不同目录中的程序文件和配置文件，也不要只覆盖部分文件。更新时先正常退出客户端和核心，保留配置备份，再把新安装包放到独立目录测试。

安全软件可能阻止核心创建进程、监听本地端口或建立虚拟网卡。处理时应查看拦截记录和文件来源，再按最小范围放行必要程序。不要关闭全部系统防护作为长期方案。若客户端在普通模式正常、TUN 模式崩溃，重点检查虚拟网卡驱动、管理员权限和其他网络过滤驱动；若仅在更新订阅时无响应，检查节点数量、筛选表达式和订阅返回内容。

配置文件损坏时，可在备份原目录后建立全新配置，让客户端生成默认文件，再手工加入一个节点进行测试。若新配置正常，逐项迁移订阅、路由和设置，不要直接复制整个旧目录。迁移到某一项后再次崩溃，即可确定问题来源。若新配置仍崩溃，则检查运行环境、权限、图形驱动和系统日志。

故障处理完成后，需要验证冷启动、更新订阅、切换节点、开启系统代理和正常退出五个动作。正常退出后确认系统代理已清理，重新启动后确认配置能够读取。只有连接一次成功，不能证明配置数据库和退出流程都正常。Windows 安装与运行环境的完整检查可参考v2rayN Windows 安装配置全流程。

Android 上的 v2rayNG 与 v2flyNG 通过系统 VPN 接口接管流量，故障除节点配置外，还常与后台限制、专用 DNS、电池策略、网络切换和其他 VPN 应用有关。v2rayNG 使用 Xray 内核，v2flyNG 使用 v2fly 内核；两者可用于不同内核兼容性的对照，但同一时间只能保留一个活动的 VPN 连接。排查时先完全停止另一客户端，不要只把界面切到后台。

连接按钮成功但应用无法访问

先观察状态栏中的 VPN 标识是否出现，再检查客户端日志是否建立本地 VPN 接口。标识没有出现，通常是系统授权未完成、已有 VPN 占用或客户端被系统阻止；标识存在但所有应用断网，应检查节点、DNS 和路由；只有部分应用异常，则检查分应用代理、绕过列表和应用自身的专用网络设置。

分应用代理配置容易因模式理解错误造成反向结果。“仅代理所选应用”和“绕过所选应用”含义相反，更新应用或重新安装后，应用标识也可能变化。排查时先关闭分应用功能，让所有应用使用同一路径；基础连接正常后，再逐个加入名单。若启用后某应用仍直连，应确认它是否使用独立进程、系统组件或内嵌服务。

Android 的专用 DNS 可能与客户端 DNS 接管冲突。症状包括节点显示连接成功、域名请求长时间等待，但直接访问部分 IP 正常。可临时把专用 DNS恢复为自动，再重新连接客户端测试。若问题消失，应决定由系统专用 DNS 还是客户端负责解析，不要让两者形成不清晰的串联。浏览器自身仍可能启用安全 DNS，也需要单独检查。

后台断连与网络切换

锁屏后断线通常与电池优化、后台活动限制或系统清理有关。为正在使用的客户端允许后台运行，并检查省电模式是否限制 VPN。不同设备的设置名称不同，但核心目标一致：允许客户端和核心进程在锁屏后维持网络。不要同时为多个同类客户端开启自启动和常驻，它们可能争用 VPN 权限并增加状态混乱。

从 Wi-Fi 切换到移动网络后，原有连接的本地地址和路由会变化。部分节点能够自动重连，另一些连接会停留在旧网络。遇到切换后无流量，可在客户端中停止连接，等待系统网络稳定后重新启动。若频繁发生，查看日志是否出现网络不可用、接口关闭或 DNS 超时。把“切换网络后失败”和“固定网络持续失败”分开记录，两个问题的处理方向不同。

订阅更新失败时，应先确认浏览器在当前网络能否打开订阅请求，再查看客户端更新日志。移动网络可能对后台数据、漫游数据或省流量模式有限制。订阅成功但节点无法连接，按本手册的超时章节核对地址、端口、TLS 和传输字段。对于 2015 年后的主流设备，通常优先选择 arm64 安装包；无法确认架构时可使用通用版，具体入口见Android 客户端下载。

v2rayNG 与 v2flyNG 的内核支持范围不同。某个节点在 v2rayNG 中可用、在 v2flyNG 中失败，不应直接归因于网络，先比较协议与传输字段是否被对应内核支持。对照测试必须使用相同网络、相同节点、相同 DNS 条件，并完全停止另一客户端。若两个客户端都失败，再检查节点和系统网络；若只有一个失败，保存该客户端的首条核心错误用于判断兼容性。

移动端最终验证应包含前台访问、锁屏恢复、Wi-Fi 与移动网络切换、订阅更新和分应用规则。每一步单独测试，避免一次改变全部系统设置。若基础连接已经稳定，再恢复专用 DNS、省电策略和应用名单；恢复某项后问题复现，即可确定冲突来源。仍未完成首次订阅导入的用户，应返回快速上手教程按主线配置，避免把初始化遗漏当作运行故障。