V2Ray 故障排查手册

建立可比较的基线

先退出客户端或关闭系统代理，用浏览器访问一个平时稳定可达的站点，同时确认本地网络能够正常获取地址。若直连也失败，应先处理路由器、无线网络、网线、认证页面或本机网络栈问题。代理客户端无法修复底层网络中断。直连正常后，重新启动 v2rayN、v2rayNG 或 v2flyNG，保持原节点与原路由模式不变，再访问同一站点。这个对照可以把“网络本身不可用”和“代理链路不可用”分开。

桌面端还要区分“核心运行”和“系统流量已经导入核心”。v2rayN 的运行日志中应出现本地入站监听成功的信息；若端口被其他进程占用，核心可能启动后立即退出，界面托盘图标却仍然存在。检查设置中的本地 HTTP、SOCKS 端口，再确认浏览器或系统代理使用的是相同端口。手动配置过浏览器代理扩展时，还要防止扩展指向旧端口。

1. STEP 01关闭代理验证直连
2. STEP 02确认核心与端口监听
3. STEP 03核对系统代理地址
4. STEP 04更换节点进行对照

确认本地端口是否真正监听

Windows 可在 PowerShell 中查看对应端口。下面以常见的本地端口示例演示，实际检查时应替换为客户端设置页显示的值。若没有任何输出，说明端口未建立；若拥有进程记录但进程并非当前客户端，则存在端口冲突。不要仅通过“端口号看起来正确”判断，监听进程才是有效证据。

WINDOWS / LOCAL LISTENER

Get-NetTCPConnection -State Listen |
  Where-Object { $_.LocalPort -in 10808,10809 } |
  Select-Object LocalAddress,LocalPort,OwningProcess

Get-Process -Id (Get-NetTCPConnection -LocalPort 10809 -State Listen).OwningProcess

macOS 与 Linux 可以使用系统自带的网络工具查看监听状态。结果中若只监听在 127.0.0.1，表示仅本机程序可以访问，这是桌面单机使用时的正常边界。只有明确需要局域网设备接入时才考虑允许局域网连接；排查单机故障时不应先扩大监听范围，因为这会增加变量，也不能解决系统代理指向错误的问题。

MACOS / LINUX / LOCAL LISTENER

ss -lntp | grep -E '10808|10809'
lsof -nP -iTCP:10809 -sTCP:LISTEN

按现象区分代理、路由与远端故障

路由模式是这一症状中最容易被忽略的变量。规则模式会根据域名、目标地址和规则集选择直连或代理；全局模式通常把更多流量交给代理出站。可短暂切换全局模式进行诊断：若全局模式恢复，节点本身大概率可用，问题集中在规则匹配或 DNS 返回结果；若全局模式仍失败，则继续检查节点与传输层。诊断完成后应恢复原模式，再针对具体规则修正，不应把临时诊断模式当成永久解决方案。

最后使用第二个已知可用节点做对照。只更换节点，不改路由、DNS 和系统代理。如果第二个节点恢复，故障在原节点或其传输参数；如果所有节点都失败，回到本地监听、系统代理和客户端核心。通过这种单变量替换，可以避免把节点故障误判为软件故障，也能避免无意义地反复安装客户端。

先确认服务器地址与端口

打开当前节点的编辑页，逐项核对地址、端口、用户标识、加密选项、传输方式、TLS 开关、服务器名称、路径与 Host。订阅导入的节点通常不需要手工改写这些字段；如果曾为排查问题修改过单项，优先与订阅原始内容重新对照。地址字段只能放主机名或地址，不要连同协议前缀、路径或端口一起粘贴。端口必须是有效数字，并与服务端监听一致。

当节点使用域名时，先确认本机可以解析该域名。解析成功只说明得到了地址，不能证明对应端口可达。Windows 可以使用 Test-NetConnection 检查 TCP 建连；macOS 与 Linux 可使用 nc。命令中的示例域名和端口需要换成节点实际值。若 TCP 检查失败，继续调整客户端协议参数没有意义，应先确认网络路径、地址和端口。

TCP / REACHABILITY

Test-NetConnection server.example.net -Port 443

nc -vz server.example.net 443

测试结果要结合场景解释。域名可解析但端口失败，可能是远端未监听、地址已经变化、中间网络阻断或本地安全软件拦截；端口成功但客户端仍超时，则故障更靠近 TLS、WebSocket、gRPC 或协议认证层。不要用浏览器能否打开节点域名来判断服务是否正常，因为浏览器访问的是 HTTP 请求，而节点可能使用完全不同的路径和握手格式。

检查 TLS 与传输参数是否成组匹配

TLS 场景中，服务器名称通常参与证书与握手匹配。节点地址可以是地址值，而服务器名称仍需填写配置提供方指定的域名；把两者机械改成相同内容可能导致握手失败。若日志出现证书名称不匹配、握手提前关闭或协议版本协商失败，应恢复订阅中的服务器名称与安全设置，而不是关闭验证来绕过错误。时间明显不准确也会影响证书有效期判断，因此要先让系统时间和时区恢复自动同步。

WebSocket 节点要同时核对路径与 Host。路径通常以斜杠开头，大小写和尾部字符都可能参与服务端匹配；gRPC 节点则要核对服务名称。VMess、VLESS 等协议字段不能脱离传输层单独判断：协议认证正确而传输路径错误，仍会在认证前失败。订阅更新后如果只有少数旧节点超时，也可能是服务端参数已经调整，而客户端仍保留旧节点副本，应删除旧副本后从订阅重新生成。

用对照组缩小故障范围

准备三个对照：同一客户端的另一个节点、同一节点在另一条网络、同一订阅在另一台设备。另一个节点可用，说明客户端基础链路正常；同一节点换网络后可用，说明原网络路径存在差异；同一节点在所有设备都失败，则更可能是远端节点状态或订阅参数问题。每次只改变一个条件，并记录结果，三次对照通常比反复重启更有信息量。

延迟测试也需要正确理解。客户端显示的连接延迟通常是某种探测请求的完成时间，不等同于所有业务流量的速度。部分节点可能不响应特定探测方式，但实际连接可用；也可能探测很快，后续 TLS 或应用请求却失败。因此应同时观察真实网页请求和运行日志。遇到所有节点同时超时时，再检查系统时间、DNS、系统安全策略和客户端核心是否正常加载，而不是把所有节点分别编辑一遍。

若节点由订阅管理，最终修复路径应回到订阅源：确认订阅仍有效，更新后检查节点参数是否变化，再删除手工修改产生的重复项。节点参数已经确认无误但远端持续不可达时，本地客户端没有可继续修复的配置项，应保留日志中的阶段信息并更换可用节点。这样能够把“远端不可用”与“本地配置错误”清楚分开。

确认链接本身与更新路径

先从订阅管理页复制当前链接，检查开头和结尾是否混入空格、换行、中文标点或重复字符。通过聊天工具转发的长链接可能被折行，复制时也可能只取到可见部分。不要手工解码后再粘贴，客户端需要的是完整原始链接。若服务方更新过订阅地址，应删除旧条目后重新添加，避免两个相似名称的订阅并存，导致实际更新的是旧链接。

接着区分“更新订阅时使用代理”和“直接更新”。当当前网络无法直接访问订阅地址，而客户端设置为直连更新时，请求会在解析或建连阶段失败；反过来，如果客户端强制通过一个已经失效的节点更新，订阅同样无法请求。v2rayN 中可检查订阅更新相关的代理选项，Android 客户端则要确认更新动作发生时 VPN 连接状态和分应用规则。切换更新路径只能作为诊断，确认可用路径后再固定设置。

1. STEP 01核对完整链接
2. STEP 02判断是否成功请求
3. STEP 03识别响应内容
4. STEP 04处理解析兼容性

根据响应结果判断问题层级

如果日志提供 HTTP 状态，可先按类别判断。重定向并不一定是错误，但客户端需要能够跟随到最终地址；权限相关响应通常表示链接凭据、有效期或访问条件变化；服务器错误则说明订阅端暂时未正常生成内容。状态成功也不代表内容可解析：登录页面、提示页面或网关错误页同样可能以成功状态返回，客户端随后会报告格式错误或节点数为零。

不要把订阅链接粘贴到公开检测页面，也不要在求助截图中完整展示。链接通常承担访问凭据作用，排查时只记录域名、响应状态和错误类型即可。需要对比链接时，可以比较长度、开头和末尾少量字符，但应遮住中间参数。客户端日志若原样输出完整地址，分享前也要移除查询参数。

解析失败与节点列表为空

请求成功但解析失败时，先确认客户端类型。桌面端首推 v2rayN，Android 可使用 v2rayNG，v2flyNG 作为使用 V2Fly 内核的备选。较旧客户端可能不认识订阅中新增的协议字段或传输选项，此时应从下载页获取当前安装包，再重新执行订阅更新。不要在旧客户端中逐个删减陌生字段，因为这会让节点表面可保存、实际握手仍然失败。

节点列表为空还可能来自订阅分组、筛选或去重设置。先取消名称筛选，查看全部分组，并确认更新动作确实针对当前订阅。若设置了按备注去重，多个同名节点可能只保留一个；若启用了自动移除旧节点，响应为空时也可能导致原列表被清理。重要配置应在更新前导出备份，排查阶段则关闭会改变列表结构的自动化规则，避免响应问题与本地筛选叠加。

如果同一订阅在一台设备可更新、另一台失败，优先比较两端的客户端版本、更新代理、DNS 和系统时间；如果所有设备都得到相同错误，则应把重点放在链接与响应端。恢复后不要只看“更新成功”提示，还要确认节点数量合理、旧节点是否按预期替换，并随机选择一个节点完成实际连接。只有请求、解析和连接三步都通过，订阅链路才算恢复。

使用固定对象建立对照

选择一个直连时稳定、内容大小相对固定的网页或文件，分别在关闭代理、当前节点、另一节点三种状态下测试。每次测试前等待当前下载结束，关闭占用带宽的同步、更新和视频任务，并保持同一网络。不要同时使用多个测速页面求平均，因为测试端位置和连接数不同，会引入新的变量。目标不是得到漂亮数字，而是确认瓶颈跟随节点、网络还是特定目标站点变化。

首次打开慢但打开后传输正常，重点检查 DNS、TCP 建连和 TLS 握手；持续速率低但延迟正常，重点检查节点出口带宽、链路拥塞和传输方式；速度周期性下降并伴随重传，通常与无线网络质量、丢包或路径波动有关；只有单一站点慢，则可能是该站点到节点出口的路由或站点自身限制。把这些现象分开，比单看客户端延迟更有效。

检查本地链路与协议开销

先在同一设备上测试直连网络。无线信号弱、频段拥挤、后台上传占满上行，都会显著拖慢代理连接。上行被占满时，确认包和控制包难以及时发送，即使下载带宽仍有余量，网页也会表现为卡顿。可暂时关闭云同步、系统更新与大文件上传，再用有线网络或更靠近接入点的位置复测。如果直连已经波动，继续切换协议通常不会得到稳定结论。

传输封装会增加头部和握手成本，但不应把所有性能问题归因于某个协议名称。WebSocket、gRPC、TLS 等组合的表现取决于实际路径和服务端配置。订阅提供的节点参数通常是成组设计的，不要仅为了追求速度手工关闭安全层或改变传输方式。错误组合可能偶尔建连，却在持续传输时产生重试。正确方法是选择配置完整的另一节点做对照，而不是拆改现有节点。

路由、并发与测试误差

规则模式下，不同域名可能走不同出站。测速页面的主页面、测试接口和静态资源也可能分属多个域名，最终测到的是混合路径。诊断时可短暂使用全局模式，确认所有相关请求经过同一节点；若全局模式明显改善，应检查规则命中，而不是直接认定节点性能异常。日志中的出站标签可以帮助确认请求究竟走了代理还是直连。

并发连接数同样会改变结果。有些测速工具通过大量并发连接填满带宽，而实际浏览主要由许多短连接组成；前者高不代表后者一定顺畅。反过来，单连接速度低也不代表总吞吐必然低。排查网页慢应观察 DNS 与握手，排查下载慢则固定单个下载对象，排查视频缓冲还要考虑内容分发节点选择。每种场景使用对应指标，避免用一个数字解释所有体验。

若所有节点只在某条网络上慢，换网络后恢复，问题更可能位于本地接入或网络路径；若同一节点在所有设备都慢，而其他节点正常，则优先更换节点；若只有特定目标慢，则检查路由与目标侧路径。完成定位后，把临时关闭的后台服务、路由模式和测试设置恢复，避免为了测速形成不符合日常需求的配置。

识别系统解析与内置解析

普通系统代理模式下，应用可能先通过系统 DNS 得到目标地址，再把地址交给代理；部分应用会自行启用加密 DNS，不再遵循系统设置；虚拟网卡模式则可能把更多 DNS 请求交给客户端处理。三种路径并存时，同一域名可能得到不同结果。排查前应暂时关闭浏览器单独配置的 DNS 功能，让测试路径尽量单一，再查看客户端日志中是否出现对应域名。

使用系统查询工具可以建立基线。Windows 可运行 Resolve-DnsName，macOS 与 Linux 可使用 nslookup 或 dig。先不指定服务器，观察系统默认结果，再与客户端日志中的目标地址比较。如果系统可以解析而客户端报告解析失败，应检查客户端内置 DNS 配置；如果两者都失败，则检查当前网络提供的解析服务、系统网络设置和域名拼写。

DNS / BASELINE

Resolve-DnsName example.com

nslookup example.com

dig example.com A
dig example.com AAAA

理解地址族与路由匹配

域名可能同时返回 IPv4 与 IPv6 地址。当前网络的 IPv6 路径不完整时，应用可能优先尝试 IPv6，等待失败后才回退，表现为首次访问明显延迟。可通过查询结果与连接日志确认实际使用的地址族，而不是直接关闭整个系统的 IPv6。若客户端提供地址策略，应选择与本地网络能力一致的策略；修改后分别测试只返回 IPv4、同时返回两种地址的域名，确认没有引入新的访问差异。

路由规则既可以按域名匹配，也可以按解析后的地址匹配。若域名规则没有启用相应的嗅探或域名保留机制，应用提交的只有目标地址时，域名规则可能无法命中；反过来，过度依赖地址规则也会受到内容分发地址变化影响。诊断时应在日志中查看匹配到的规则和出站标签。临时全局模式可验证是否为规则问题，但最终修复应回到明确的域名或地址规则。

V2RAY / DNS STRUCTURE EXAMPLE

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

这段示例用于说明结构关系，不应直接覆盖客户端自动生成的完整配置。servers 的顺序和域名范围会影响查询去向，localhost 表示使用系统解析路径，queryStrategy 决定可接受的地址类型。图形客户端可能在保存时重新生成配置，因此应优先通过界面提供的 DNS 设置修改；只有明确了解生成逻辑时，才编辑自定义配置片段。

缓存、污染结果与验证闭环

修改 DNS 后仍得到旧地址，可能是系统、浏览器或客户端缓存未清理。Windows 可使用 ipconfig /flushdns 清理系统缓存；浏览器需要完全退出后重开；客户端则可重启核心。缓存清理只应在配置改变后执行，不必在每一步反复运行。若清理后短暂恢复又再次异常，应继续检查查询实际去向，而不是把缓存当成根因。

WINDOWS / CLEAR SYSTEM DNS CACHE

ipconfig /flushdns

有效的修复闭环应包含三项：系统工具能够得到合理结果，客户端日志显示查询经过预期路径，实际连接命中了预期出站。只更换 DNS 地址而不确认后两项，往往只是暂时改变结果。完成测试后恢复浏览器原有设置，再检查多个应用，确保修复覆盖真实使用路径，而不是只让某一个测试页面通过。

检查地址、端口和代理类型

v2rayN 设置系统代理后，Windows 代理页面应出现本机地址与对应 HTTP 端口。常见错误是把 SOCKS 端口填到只接受 HTTP 代理的位置，或者客户端端口调整后系统仍保留旧值。先在客户端设置页记录 HTTP 与 SOCKS 的具体端口，再与系统页面逐项比较。地址通常为回环地址；如果写成已经变化的局域网地址，离线或切换网络后就可能失效。

系统中可能还有自动配置脚本、企业策略、浏览器扩展或其他代理软件争夺控制权。表现通常是客户端刚写入设置，过几秒又被改回，或者浏览器与系统页面显示不同代理。排查阶段应暂时关闭其他会修改代理的程序和浏览器代理扩展，只保留一个控制来源。若设备受管理策略约束，应查看系统提示，不要通过反复写入注册项对抗策略。

WINDOWS / CURRENT USER PROXY

Get-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' |
  Select-Object ProxyEnable,ProxyServer,AutoConfigURL

输出中的 ProxyEnable 可用于确认手动代理是否启用，ProxyServer 显示当前地址与端口，AutoConfigURL 则表示是否存在自动配置脚本。读取结果只用于诊断，优先通过系统设置与客户端界面修改，不建议直接编辑注册项。若客户端退出后代理仍保持开启，浏览器可能继续向已经关闭的本地端口发送请求，于是出现“退出客户端后完全无法上网”。此时关闭系统代理即可恢复直连。

区分系统代理与虚拟网卡模式

系统代理适合遵循操作系统代理接口的应用；虚拟网卡模式工作在更低层，可处理更多没有代理设置的程序。两者并非越多越好。若同时开启并配置不当，流量可能重复进入客户端或形成回环。诊断系统代理时先关闭虚拟网卡模式，确认浏览器能够通过本地 HTTP 入站访问；需要覆盖不读取系统代理的应用时，再单独评估虚拟网卡模式及其路由范围。

命令行工具通常有自己的代理变量。例如某些工具读取 HTTP_PROXY 与 HTTPS_PROXY，但不会自动采用桌面系统代理。测试时可以为当前终端会话设置变量，不要一开始就写成全局永久值。代理地址应使用客户端实际 HTTP 端口，关闭客户端后也要清除变量，避免后续命令持续连接失效端口。

SHELL / SESSION PROXY EXAMPLE

export HTTP_PROXY=http://127.0.0.1:10809
export HTTPS_PROXY=http://127.0.0.1:10809

unset HTTP_PROXY
unset HTTPS_PROXY

按应用验证请求是否进入核心

清空客户端日志，只在目标应用中发起一个可识别请求。如果日志出现对应域名或地址，说明应用流量已经进入核心，后续应检查路由与出站；如果没有任何记录，则问题仍在应用到本地入站之间。浏览器可以先关闭所有代理扩展并重启，办公软件和开发工具则检查各自网络设置。不要因为浏览器可用就推断所有应用都会使用系统代理。

修复完成的标准不是系统开关显示开启，而是目标应用的一次请求能够出现在客户端日志中，并通过预期路由成功返回。若日志始终没有请求，继续更换远端节点不会产生作用。若请求已经进入但失败，则返回节点、DNS 或路由章节继续排查。用日志作为边界，可以把“应用没有交出流量”和“核心没有送达流量”准确分开。

区分界面进程和核心进程

v2rayN 桌面端包含图形界面与实际处理流量的核心进程。界面仍可操作但所有请求失败，可能是核心没有成功启动；界面直接关闭，则要检查应用日志和系统事件。先记录崩溃发生在启动时、切换节点时、更新订阅时还是开启虚拟网卡时。能够稳定触发的动作是定位依据，描述“偶尔崩溃”不如记录“导入某条配置后点击连接立即退出”有效。

检查任务管理器或活动监视器，确认是否残留旧核心进程。旧进程占用端口时，新核心可能启动失败；多个客户端同时运行也可能争用系统代理、虚拟网卡或监听端口。退出所有相关客户端，等待进程结束，再只启动一个客户端测试。若进程无法正常退出，可先保存日志后结束对应进程，不要直接重启设备掩盖残留关系。

处理配置损坏与权限问题

崩溃如果紧随某次配置编辑或订阅更新出现，应先导出当前配置，再创建一个最小测试环境。删除最近导入的异常节点，关闭自动启动、自动更新订阅和虚拟网卡，只保留一个结构明确的节点。如果最小环境可以启动，再逐项恢复设置。不要一次性复制整个旧数据目录到新安装位置，否则损坏配置和旧路径会被完整带回。

安装目录权限也会影响日志、数据库和核心文件写入。桌面客户端应放在当前用户可读写的位置，避免放进需要持续提升权限才能修改的目录。若从压缩包运行，应完整解压后再启动，不要直接在压缩工具的临时视图中执行。安全软件隔离了核心文件时，客户端可能只剩界面而无法连接；应查看系统安全记录，确认文件处置原因，再从安装包页面重新获取与平台匹配的客户端。

Windows 桌面版与经典 WPF 版使用的界面技术不同。如果某一界面在当前系统环境中无法稳定启动，可先确认运行环境和系统更新，再使用下载页提供的另一桌面入口进行对照。切换版本前保留订阅地址与路由设置，首次启动时使用干净目录，不要覆盖原目录。这样可以判断问题位于界面运行环境，还是由共享配置触发。

日志、资源与可复现信息

日志级别过高可能在长时间运行时产生大量磁盘写入，尤其是把每个连接都记录为详细调试信息时。日常使用应保持常规级别，只有复现问题的短时间窗口才提高详细度。复现前清空旧日志，执行一次触发动作，随后立即保存。这能减少个人配置内容暴露，也避免在数万行旧记录中寻找真正错误。

还要观察磁盘剩余空间、内存占用和系统休眠恢复。磁盘空间不足会使数据库或日志写入失败；休眠恢复后网络接口变化，旧连接和虚拟网卡状态可能没有正确重建。若崩溃只发生在唤醒之后，可先关闭客户端再重新启动，确认是否为恢复流程问题。若全新启动也会发生，则继续检查配置与运行环境。

重装应放在配置与环境对照之后。正确的重装测试是：保留旧目录不覆盖，在新目录启动当前安装包，不导入全部旧设置，只添加最小配置。若新环境稳定，再逐步迁移订阅和路由；若新环境仍在相同动作崩溃，则问题更可能与系统环境、驱动或特定配置格式有关。参照v2rayN Windows 安装配置与常见坑可进一步检查桌面运行环境和系统代理残留。

确认 VPN 接口与唯一占用

启动连接时，系统应出现 VPN 授权并显示对应状态。Android 同一时间通常只允许一个应用占用系统 VPN 接口，因此其他 VPN、网络过滤工具或工作资料中的网络服务可能让 v2rayNG、v2flyNG 无法建立接口。先断开其他 VPN 类应用，再重新连接当前客户端。如果授权对话框不再出现但状态立即关闭，可在系统 VPN 设置中移除旧授权后重试。

始终开启 VPN 与“阻止未使用 VPN 的连接”是系统级策略。配置正确时它们可以约束流量路径，但在客户端核心启动失败、订阅失效或节点不可用时，也会让设备看起来完全断网。排查阶段先关闭这两项，确认普通连接能够恢复，再单独测试客户端。故障定位完成后，是否重新启用应根据实际网络策略决定，而不是把系统阻断误判成客户端无法关闭。

解除后台与电池限制

部分设备会在熄屏、切换应用或一段时间无前台活动后限制后台进程。典型现象是刚连接正常，锁屏数分钟后所有请求停滞，重新打开客户端又恢复。应在系统应用设置中允许客户端后台运行，电池策略设为不限制，并允许必要的后台数据。不同设备的菜单名称可能不同，但判断依据一致：客户端进程是否在熄屏后仍保持、VPN 状态是否被系统回收。

不要同时给多个客户端设置自动连接。v2rayNG 与 v2flyNG 可安装用于不同内核场景，但一次排查只运行其中一个。两个应用交替争用 VPN 权限，会造成状态栏图标闪动、连接刚建立就断开，或系统始终恢复到另一应用。先强制停止未参与测试的客户端，再清理当前客户端的电池限制和自启动策略。

检查分应用、私人 DNS 与网络切换

分应用代理可以选择哪些应用进入 VPN，也可以采用排除方式。规则方向理解错误时，常见表现是浏览器正常但目标应用直连，或者只有被排除的应用可用。诊断时先关闭分应用功能，让全部应用走统一路径；确认连接正常后，再逐个加入或排除应用。每次修改规则后完全结束目标应用并重新打开，避免旧连接继续使用原路径。

系统私人 DNS 与客户端内置 DNS 可能同时生效。若私人 DNS 主机不可达，域名请求可能在进入客户端前就失败；若应用自行使用加密 DNS，客户端路由看到的也可能只是解析服务连接。排查时将私人 DNS 暂时恢复为自动，关闭浏览器独立 DNS，然后测试系统查询路径。若恢复正常，再决定使用系统私人 DNS 还是客户端 DNS，尽量避免多层重复接管。

从无线网络切换到移动网络时，本地地址、默认路由和可用地址族都会变化。部分已有连接不会自动迁移，表现为 VPN 仍显示连接但请求停滞。切换网络后等待系统网络稳定，再断开并重新连接客户端。若只在一种网络失败，保持节点与客户端设置不变，重点比较该网络的 DNS、IPv6 路径和认证页面。公共无线网络需要先在直连状态完成网页认证，再启动 VPN。

订阅更新在 Android 上还受后台数据与当前 VPN 路径影响。更新返回空列表时，不要立即删除现有节点；先确认客户端允许联网、订阅链接完整，并分别测试连接状态下更新与断开后更新。v2rayNG 使用 Xray 内核，v2flyNG 使用 V2Fly 内核，订阅内某些字段的支持范围可能不同。作为对照时应保持同一网络与同一订阅，不要同时改变内核、节点和 DNS。

最后检查应用日志中的时间顺序：VPN 接口是否建立、核心是否启动、节点是否完成握手、DNS 是否返回结果。若接口没有建立，处理系统权限；接口建立但核心退出，检查配置和客户端；核心运行但节点超时，返回节点章节；只有特定应用失败，则处理分应用规则。按这个边界推进，可以避免清除整个设备网络设置，也能保留已经验证有效的配置。