V2Ray 故障排查手册

无法上网：先拆开连接链路

客户端显示运行，只能说明界面进入了某个状态，不等于浏览器请求已经通过节点。先记录故障范围：所有应用失效，还是只有浏览器；所有网站打不开，还是只有某个域名；关闭客户端后，普通直连访问是否恢复。这三组对照分别对应系统网络、应用接入和目标服务。测试时固定一个平时能够正常打开的 HTTPS 页面，避免不断更换目标，让网站自身的异常混进结论。

建立最小测试环境

先退出其他代理程序，暂停浏览器代理扩展，关闭 TUN，仅保留 v2rayN 的普通本地代理入口。选定一个已知参数完整的节点，确认它是当前活动服务器，再检查主窗口日志是否显示内核正常启动。如果尚未完成首次配置，不要从高级路由入手，先回到快速上手教程完成基本连接。退出其他程序是为了排除端口争用和双重接管，不是要求长期改变使用习惯。

打开参数设置，记录本地 SOCKS 或混合监听的实际端口。本页命令中的 10808 仅在该端口确实提供 SOCKS 服务时适用；若已修改端口，应同步替换命令。监听地址为 127.0.0.1 时仅接收本机请求，这是正常的本地使用方式。不要为了修复本机浏览器而开启局域网连接，也不要把监听地址改成所有网卡地址，这会增加不必要的接入范围。

curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 30 --head https://example.com/

这条命令显式使用本地 SOCKS 代理，并将目标域名交给代理端解析，适合绕过浏览器的代理设置做链路对照。Windows 若没有直接可用的同名命令，可在终端使用 curl.exe。返回 HTTP 响应说明请求至少到达了某个响应方；状态码不是成功页，也不必立即判定代理失败。证书错误、连接被拒绝和连接超时属于不同层次，应保留完整报错，不要只记“打不开”。

依据结果选择下一条分支

同时观察日志：执行命令的时间点附近是否出现对应目标请求。如果没有日志，先确认当前日志级别足以记录访问，再核对命令是否指向正在运行的实例。若能看到目标，但出站标签与预期不同，应检查路由命中和最终默认出站。临时使用“全部经代理”的路由进行对照可以缩小范围，但测试结束应恢复原策略，不能把模式切换当成所有故障的固定修复。

只有某个网站失败时，再比较同一节点下其他目标、同一目标下其他节点。单站返回拒绝访问、验证码或地区提示，通常表示已经建立了应用层连接；继续修改本地监听端口并不能解决目标侧限制。若浏览器报证书日期异常，先检查系统时间和时区。不要关闭证书验证来掩盖错误，也不要把任何能够返回页面的连接都视为安全正确的结果。

节点超时：区分探测与实际连接

列表中的超时不是单一故障类型。某些测试仅检查 TCP 端口是否可达，某些测试会通过节点请求指定网址，还有些结果受到测速目标、握手过程和本机 DNS 的影响。先确认点击的是哪种测试，再用正常网页访问复现。TCP 可达只代表对应地址有服务响应，不能证明协议参数、认证信息和传输设置正确；探测超时也可能只是测试目标不可用，不能直接推出整个节点失效。

按地址、端口、握手顺序核对

打开当前节点的编辑窗口，先核对服务器地址、端口和协议，再检查传输方式、TLS、服务器名称以及相关传输字段。订阅导入的配置应优先与服务提供方给出的原始参数对照，不凭节点备注推断设置。备注只是显示名称，可以任意命名，不能代表真实协议或线路。复制地址时注意前后空格、中文标点和换行；端口字段应是数字，不应混入协议前缀或网址路径。

如果服务器地址是域名，客户端必须先获得这个入口的地址，随后才能建立远端连接。日志若在连接目标服务器之前就报告解析失败，应先检查节点域名的解析，而不是修改目标网站的分流规则。可以在系统终端查询该服务器域名，比较当前网络与另一条可信网络的结果。不要把查到的某个地址永久写死作为通用修复，因为入口可能采用多地址调度，固定地址可能绕开后续更新。

Test-NetConnection -ComputerName example.com -Port 443

上面是 Windows PowerShell 的 TCP 连通性检查语法，示例域名并非可用节点。排查时使用实际节点地址与服务端口；该命令不会完成代理协议认证，也不会验证 UDP 传输。若 TCP 测试成功而客户端握手失败，重点检查 TLS 服务器名称、传输路径、认证字段和设备时间。涉及 REALITY 的配置，应与提供方资料逐项对应服务器名称、公钥和短标识，不能通过随机修改字段碰运气。

用交叉测试缩小异常范围

选择两个原本能用的节点，在当前网络分别连接；再让同一个节点通过另一条网络连接。所有节点仅在一个网络失效，更像本地网络、路由器或网络路径的问题；某个节点在多个网络持续失败，更接近远端服务或该节点配置的问题。更换网络时保持目标网址和客户端设置不变，避免同时切换内核、协议与路由。热点测试可能产生移动流量，应控制请求规模，不需要下载大文件。

日志中的 connection refused 常见于目标端口没有服务或被明确拒绝；timeout 只说明等待超过期限，并不直接指出哪一方丢弃了数据；EOF 或连接重置表示连接提前结束，还需结合它发生在拨号、TLS 握手还是认证之后判断。把错误中的目标地址与活动节点对上，防止误读订阅更新或后台探测产生的日志。连续重试只会增加噪声，找到同一请求的前后几行更有价值。

若电脑从睡眠恢复、网络从有线切到无线后才出现超时，先停止连接再重新启动内核，让旧连接和旧路由退出。必要时关闭再打开客户端，而不是直接删除所有服务器。长连接在网络变化后可能保留失效路径，重建连接足以解决这一类问题。若重启后只能短暂恢复，则记录断开所需时间、是否与屏幕休眠相关，再检查网络节能和后台策略，不要将短暂恢复误当成远端已经修复。

订阅失败：分开检查获取与解析

订阅更新包含两个阶段：客户端先请求订阅地址，再把响应内容解析为节点。下载失败、返回空内容、格式不识别和节点重复，应当分别处理。更新按钮没有增加节点，不一定是网络故障，也可能是内容没有变化、分组筛选隐藏了结果，或订阅只包含当前内核不支持的字段。先保存现有可用配置，记录当前分组名称与节点数量，再进行更新，不要通过清空列表来验证地址是否有效。

核对订阅入口与地址类型

在 v2rayN 的订阅分组设置中检查对应分组的 URL，确认复制的是完整订阅链接，而不是登录页面、购买页面或单节点分享字符串。在 v2rayNG 中进入订阅设置，核对该条订阅的地址与启用状态，再执行更新。单节点分享链接与返回多节点内容的订阅地址承担不同任务；把前者放入只接受订阅 URL 的输入框，可能得到不支持地址或空内容提示，重复点击更新不会改变格式。

链接中的查询参数往往用于识别订阅身份，漏掉尾部内容可能使服务器返回登录页或错误信息。聊天工具和笔记应用可能在换行、标点或自动链接识别时截断地址，应从原始入口重新复制。检查时只在本地查看完整值，截图应遮住参数。浏览器能打开地址，只能说明浏览器按它自己的网络路径取得了响应，不能证明客户端使用相同代理、相同请求头，也不能证明响应是节点内容。

先查看更新日志里的 HTTP 状态。认证失败应检查链接是否失效或权限是否变化；请求过于频繁应停止连点，按提供方的更新限制等待；服务器错误应保留时间并稍后重试。状态成功但解析失败时，响应可能是网页、访问提示或另一种配置格式。不要把响应全文粘贴到公开转换工具，订阅地址和节点认证字段都可能随之暴露。格式转换应基于来源明确、可在本地处理的方式。

检查更新请求走哪条路径

部分客户端允许订阅更新使用直连或经代理，不同界面的选项位置与默认行为可能不同，应以当前版本设置和日志为准。当现有节点已经失效，而更新又依赖该节点时，会形成循环：需要更新才能恢复连接，却需要连接才能更新。可以先尝试直连更新；若该地址只在代理路径可达，则临时使用一个已确认可用的连接。一次只切换更新路径，不同时修改订阅地址，以便判断哪项改变有效。

若提示 TLS 或证书异常，先核对设备时间、系统证书环境和地址拼写。单位网络或需要网页登录的公共网络可能返回认证页面；应先在浏览器完成网络本身的登录，再更新订阅。不要通过忽略证书错误解决订阅问题。订阅内容会影响后续远端连接，来源是否正确比一次成功下载更重要。若地址发生重定向，可向提供方确认最终入口是否变化，而不是将陌生中转地址直接替换进配置。

能够获取内容但节点仍为空时，检查分组筛选、搜索条件、去重选项与节点类型。某些订阅内容面向其他配置体系，扩展名相似并不代表可直接导入。另有一些字段依赖特定内核能力，旧内核可能在解析或启动阶段拒绝它们。先更新与系统架构匹配的客户端，再重新导入原始订阅；不要手动删除所有无法理解的字段，否则可能得到能保存却无法认证的残缺节点。

完成一次成功更新后，核对活动节点是否仍存在、路由引用是否依赖旧分组，以及自动选择是否切换了服务器。名称重复不必然代表地址重复，名称变化也不必然代表服务端变更。更细的操作入口与格式区别见订阅链接导入步骤。如果需要向他人描述问题，提供响应状态、解析报错和客户端名称即可，避免分享可直接使用的订阅 URL。

速度慢：区分延迟、吞吐与抖动

“慢”至少包含三种现象：网页开始响应前等待很久、下载持续速率偏低、连接时快时慢。列表中的一个延迟数字无法描述全部体验。首先确定瓶颈发生在建连阶段还是持续传输阶段，再比较同一时段、同一目标和同一网络。短时间反复切换几十个节点，既难以形成可比较的样本，也可能触发目标服务限速；少量受控对照通常比大规模自动测速更能说明问题。

先建立直接访问的基线

暂停系统更新、云盘同步和其他大流量任务，确认无线信号与本地网络正常。在客户端关闭时访问平时可直连的服务，观察是否同样缓慢；若基线已经异常，应先处理本地带宽占用、无线干扰或路由器负载。基线测试只说明接入网络状态，不能据此推算节点实际速度。下载测试还会消耗服务流量，若订阅有额度限制，宜选短时间、可中止的测试，并提前了解计费方式。

接着在固定节点下重复打开同一页面，区分首次访问与后续访问。第一次慢、随后正常，可能与 DNS、TLS 建连或连接复用有关；每次都缓慢，则应看日志是否频繁重连、目标地址是否反复变化。浏览器开发者工具能帮助区分等待首字节与内容下载，但页面本身的脚本和广告请求也会影响完成时间。测试代理链路时，不要把整个复杂页面的加载结束时间当成唯一指标。

逐层排除额外路径与资源竞争

检查应用是否同时使用了浏览器代理扩展、系统代理和 TUN，是否还配置了额外的前置代理。多层路径可能增加握手成本，也可能形成回环。先保留一种明确的接入方式，再测试同一请求。若普通系统代理正常而 TUN 较慢，应优先检查虚拟网卡路由、DNS 接管和其他网络软件冲突，不要立刻更换所有节点。节点到目标服务的路径与本机到节点的路径，都可能成为性能瓶颈。

观察内核进程的 CPU、内存和网络占用，尤其在小型设备、大量并发或复杂路由规则下。资源占用较高时，先减少同时运行的任务和不必要的调试日志，再重新测量。不要把随机开启复用、关闭加密验证或添加不明参数当作加速方法。复用是否有益取决于协议、服务端支持与连接形态；配置不匹配可能反而增加失败率，性能调整应建立在连接稳定和兼容明确的前提上。

如果下载前几秒正常，随后持续下降，比较不同目标与不同时间段，确认是否为目标限速、服务额度策略或共享链路拥塞。若所有目标在相同时段都下降，记录时段后换一个节点做对照；若只有一个下载源异常，换节点也未必有用。测速网站可能选择不同服务器，结果不能直接等同于日常应用体验。可以用同一来源的同一文件进行短时对照，但无需为排查下载来源不明的大文件。

UDP 类应用与网页使用的 TCP 路径可能表现不同。网页正常而实时通信卡顿时，应核对该协议、节点和接入方式是否支持所需 UDP 流量，再观察丢包和网络切换情况。不要仅因为某项功能慢就启用所有流量接管。MTU 不合适可能造成部分连接停顿，但不应在没有证据时随意减小；若只有 TUN 下大响应卡住，应保留原值，小幅单变量测试，并在没有改善时立即恢复。

连续使用一段时间后才变慢，还需要检查设备温度、节能模式、后台任务和日志文件增长。电脑长时间唤醒后可以重建连接作对照，但重启只应作为定位手段。若问题稳定复现，应记录触发条件，而不是每次重复重启。讨论“哪个内核更快”之前，先确认两次测试使用同一节点参数、同一路由和相同目标，否则结论往往只是网络条件变化，无法证明内核差异。

DNS 问题：先确认由谁解析

DNS 排查的起点不是更换公共解析地址，而是确认哪个组件在查询。系统解析器、浏览器的加密 DNS、客户端内核 DNS 和 TUN 接管可能同时存在。节点服务器域名与最终网站域名也属于两次不同的解析：前者用于找到代理入口，后者用于连接目标。入口无法解析时，即使目标域名的 DNS 配置正确也无法联网；把这两段混在一起，会导致设置越改越多而问题始终不变。

用可控请求比较解析位置

先记录报错中的域名及发起进程，判断是订阅地址、节点入口还是目标网站。系统终端的查询仅测试系统当下可用的解析路径，不能代表浏览器或内核的实际结果。若浏览器正常、其他程序失败，检查浏览器是否启用了独立加密 DNS；若显式代理正常、直连异常，则可能是系统解析或直连网络的问题。对比时保留相同目标，不要用另一个域名的成功结果替代当前域名的诊断。

nslookup example.com

curl --proxy socks5://127.0.0.1:10808 --connect-timeout 10 --head https://example.com/
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --head https://example.com/

两条代理命令的差别在于目标域名的处理位置：socks5 通常由本机先解析，socks5h 则把域名交给代理端。后者成功、前者失败，可优先检查本地解析；两者都失败则继续查看远端连接和内核日志。命令中的本地端口仍需与实际设置一致。这个对照并不能证明所有应用都采用相同方式，应用可能自行解析，也可能直接使用缓存地址。

检查 DNS 的访问路径与路由关系

在 v2rayN 中查找 DNS 设置与路由设置，先阅读现有值，再判断 DNS 请求自身应该直连还是经代理。配置远端加密解析时，还必须能连到解析服务，不能假设写入一个地址就会自动建立可用路径。如果解析服务的域名又依赖尚未建立的同一条代理连接，可能出现启动依赖循环。需要分别验证入口解析、解析服务可达性和目标查询结果，而不是一次替换所有解析项。

下面是 V2Ray 兼容配置中常见的 DNS 字段结构，用于理解服务器与查询策略的作用，不是可直接导入的完整节点配置。图形客户端可能会在启动时重新生成配置，应通过相应设置界面修改，不要直接编辑运行中的临时文件。不同内核和客户端对扩展字段的支持存在差异，若日志提示未知字段或策略无效，应回到当前内核支持的设置范围，不照搬其他体系的完整配置。

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

能查询到地址仍不等于地址可用。检查结果是否同时包含 IPv4 与 IPv6，并确认当前网络具备对应地址族的实际连通性。若只在返回 IPv6 后失败，可以临时采用仅 IPv4 的查询策略作对照，再决定是否修复本地 IPv6 路径。不要把永久关闭 IPv6 作为默认建议，也不要只因一个网站异常就更改全系统设置。路由中的域名匹配与解析后的地址匹配可能产生不同结果，应同时核对最终出站。

清理缓存应放在路径修复之后，否则错误结果很快会重新进入缓存。Windows 可用 ipconfig /flushdns 清理系统 DNS 缓存，但这不会清除浏览器、内核与所有应用的独立缓存。完成调整后，重启相关连接或应用，再重复相同测试。涉及 TUN 的虚拟地址映射时，旧连接可能仍携带先前映射，不宜把切换前后混合的日志作为结论。先停止连接，再以干净的测试窗口观察。

系统代理不生效：检查应用接入方式

系统代理是系统向应用提供的一组代理配置，不是对所有网络流量的强制接管。有些应用读取系统设置，有些使用自身设置，也有些终端程序只读取环境变量。TUN 则通过虚拟网卡和路由接入流量，两者不是同一个开关。先判断需要接入的应用采用哪种方式，再选择对应配置；不要因为一个程序不响应系统代理，就认定节点或内核已经失效。

先验证端口，再验证系统设置

先关闭 TUN，通过本页第一章的显式代理命令验证本地入口。如果该请求也失败，回到内核与节点排查，不继续调整系统设置。显式代理成功后，在 v2rayN 的系统代理菜单选择自动配置系统代理，再打开操作系统的网络代理页面，核对地址和端口是否与客户端一致。某些客户端入口同时支持 HTTP 与 SOCKS，另一些入口分开监听；不要把仅提供 SOCKS 的端口直接填进只接受 HTTP 代理的字段。

配置写入后，退出并重新打开测试应用，让它重新读取代理。浏览器扩展、应用内固定代理和组织管理策略可能覆盖系统值，应该先暂停这些覆盖再做对照。若系统字段被改回旧端口，检查是否有另一款网络程序仍在后台运行；如果设备受管理，也可能由策略周期性恢复。不要通过反复写注册表或持续抢占设置解决，先识别真正的设置来源，才能避免客户端退出后留下失效代理。

区分规则问题与未接入问题

日志中没有目标请求时，更像应用没有接入；能看到请求但显示直连，则检查路由规则、绕过列表和默认出站。系统代理的例外列表也可能让本地地址或某些域名绕过代理，这与客户端内部路由是两道不同的判断。测试时可以临时移除对应的自定义例外，但不要删除所有系统默认项。涉及局域网设备、打印服务和内部域名时，先明确预期路径，避免修复网页连接的同时破坏本地服务。

终端工具若不使用系统代理，可先用单次命令参数验证，确认有效后再决定是否设置代理环境变量。环境变量可能只影响当前终端及之后启动的子进程，已经运行的应用未必会更新；某些工具还区分大小写与不同协议变量。排查完成后删除临时变量，防止客户端关闭后，终端仍指向没有监听的本地端口。不要把含账户信息的代理地址放进公开脚本或命令历史说明中。

TUN 单独启用，单独验收

只有明确需要接入不读取代理设置的应用时，再测试 TUN。先保存当前路由，按客户端提示授予必要权限，并确认虚拟网卡成功创建。权限不足、残留网卡、其他隧道程序与网络过滤软件都可能干扰接管。客户端自身到节点的出站需要正确绕行，错误的自动路由可能把它再次送回虚拟入口，形成回环。应使用客户端支持的默认策略验证，而不是直接添加大范围静态路由。

若开启 TUN 后连本地网络也失效，立即关闭 TUN，检查默认路由、DNS 与局域网绕过。切换网络、睡眠恢复后，旧网卡索引或路由可能失效，重建连接可帮助判断。不要在尚未退出接管时手动删除所有虚拟网卡；先让客户端正常停止，再检查残留项。若必须恢复系统网络，记录原有设置并只撤销本次修改，避免清理命令影响其他正常使用的网络服务。

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

界面打不开、界面闪退、界面正常但内核停止，是三类不同问题。图形客户端负责管理配置和启动进程，内核负责处理连接；其中一个正常，并不能证明另一个正常。先观察故障发生在程序启动、选择节点、更新订阅还是启用 TUN 的瞬间，记录是否每次都能复现。不要先删除整个用户目录，因为日志、订阅和配置都可能位于其中，删除后既丢失证据，也增加恢复难度。

安装与运行环境先行检查

从下载页重新确认操作系统与处理器架构。macOS 要区分 Apple Silicon 与 Intel；Linux 要区分架构和包格式；Windows 的 v2rayN 桌面版与经典 WPF 版也应按当前系统条件选择。不要把一个平台的程序目录复制到另一个平台继续使用。压缩分发形式应完整解压到可写入的位置后运行，直接从压缩浏览窗口启动可能导致依赖文件和工作目录不完整。

安装包与便携分发形式对运行库的要求可能不同，以安装提示和当前包说明为准，不从不明来源下载单个依赖文件。若系统安全软件提示隔离，应先查看检测记录、文件来源和处理原因，不把关闭所有安全防护作为通用修复。程序放在受保护目录、只读介质或受同步工具控制的文件夹中，也可能无法写入配置。可以在用户可写目录新建独立测试环境，保留原目录不动。

内核启动失败先找第一条相关错误

在 v2rayN 主窗口查看内核日志，按启动时间找到首个错误，而不是只看最后一行“进程已退出”。常见方向包括端口占用、配置格式错误、内核文件缺失、参数不兼容和权限不足。访问日志与启动日志用途不同：前者描述请求，后者说明进程为什么没有进入工作状态。更详细的报错定位见内核启动失败日志诊断，查阅时仍应以本次日志中的实际字段为准。

Get-NetTCPConnection -LocalPort 10808 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

上面命令用于 Windows PowerShell 查看指定 TCP 端口的监听进程，端口应替换为实际值；某些环境需要相应权限。得到进程编号后，先在任务管理器确认它属于哪个程序，不要直接结束未知系统进程。若是另一份客户端实例，正常退出重复实例即可；若该端口必须由其他服务使用，可修改本客户端监听端口，并同步更新系统代理和应用设置。只修改监听而不更新入口，会产生新的“无法连接”。

配置报错应依据日志给出的字段路径处理。自定义 JSON 中的多余逗号、错误引号、字段类型或不支持参数都可能使内核拒绝启动；图形界面生成的配置则应优先回到相关设置界面修正。临时配置通常会在下一次启动时被覆盖，不应把修改临时文件当作长期方案。理解字段关系可阅读配置文件结构解析，但不要把文章片段直接覆盖整个现有配置。

采用渐进恢复，不覆盖全部状态

如果界面持续闪退，先备份配置和日志，再在独立用户目录或客户端支持的新配置环境中启动。空白环境能启动，说明问题更可能来自现有设置、窗口状态或导入内容；仍然失败则继续检查安装、依赖与系统事件。恢复时先加入一个节点并验证，再恢复订阅、路由和其他设置，每一步单独测试。一次导回全部备份，可能同时把触发故障的配置也恢复进去。

更新程序前正常退出界面与内核，不在进程仍运行时混合覆盖文件。出现问题后可保留旧目录作为回退材料，但不同构建之间的配置兼容性并非必然，应先复制再尝试读取。不要为了修复一个启动错误而频繁切换 Xray 与 V2Fly；先确认节点所需功能与当前内核兼容。提交问题时附系统、架构、操作步骤及脱敏报错，隐藏节点认证信息、订阅地址和个人目录名称。

移动端专项：权限、后台与网络切换

安卓端优先使用 v2rayNG；需要 V2Fly 内核兼容路径时，可将 v2flyNG 作为备选。两者的图形入口和可用参数并不保证完全相同，应根据正在使用的客户端核对。移动端比桌面更容易受到电池策略、应用范围和网络切换影响。先区分从未连通、亮屏正常但锁屏断开、无线网络正常但移动网络失败这三类症状，再沿对应分支排查，不要把所有问题归为节点不稳定。

连接权限与当前活动配置

首次启动连接时，系统通常会请求建立 VPN 连接的授权；若拒绝或被设备策略阻止，界面可能保留启动动作却没有实际接管流量。重新发起连接并阅读系统提示，确认当前应用获得授权。系统 VPN 图标只能说明连接服务处于某种活动状态，不代表远端可达。检查活动服务器是否选中、内核是否报告启动完成，再使用内置连接测试或浏览器固定页面验证，不以通知栏文字作为最终结论。

Android 的 VPN 服务通常不能让多个同类应用同时独立接管。若另一个网络过滤、隧道或代理应用正在使用该入口，应先正常停止，再启动当前客户端。系统若为旧应用启用了始终开启连接或阻止未经过 VPN 的流量，也可能让切换后的网络表现异常。进入系统 VPN 设置核对当前绑定对象，不要盲目删除其他应用的数据；测试结束后按原用途恢复相关设置，避免无意改变设备的网络策略。

只有部分应用失效时检查范围

在客户端的应用代理或分应用设置中，确认采用的是仅代理所选应用，还是绕过所选应用。两种名单语义相反，选中图标并不一定代表流量进入代理。先选择一个明确的测试应用，停止再启动连接，让应用范围重新生效；必要时完全退出并重新打开测试应用。若该应用使用独立 DNS、固定地址或自身网络组件，还应结合日志判断请求是否进入客户端，不能仅根据浏览器成功推断所有应用都已接入。

锁屏后断开时，先检查系统电池管理、后台运行和自动启动权限。不同设备界面名称不同，应以允许当前客户端在后台保持连接为目标，而不是关闭整个系统的节能功能。保留客户端的运行通知，观察服务是否被系统停止；通知消失、进程重启与远端超时是不同证据。可以在同一网络、同一节点下分别进行亮屏和锁屏对照，记录经过多久失败，再决定是否调整电池优化例外。

网络切换与数据网络单独验证

无线网络切换到移动数据后，原有连接可能失效，DNS 与入口地址也可能变化。先停止连接，确认手机本身已取得可用网络，再重新启动。公共无线网络需要网页登录时，应先完成该网络的认证；尚未认证的网络可能把请求重定向到登录页，使订阅与连接同时失败。若只有移动数据异常，核对当前 SIM 的数据权限、流量限制和客户端是否允许使用移动网络，不先修改节点协议。

某些移动网络主要提供 IPv6 或采用地址转换，不能仅凭桌面上的 IPv4 测试结果判断手机路径。记录客户端日志中的地址族和解析错误，并比较同一节点在无线网络与移动网络的表现。系统私人 DNS 设置也可能影响入口解析；可以临时恢复系统自动解析作对照，但测试后应恢复原设置。不要同时修改接入点、DNS 和节点字段，否则即使恢复也无法确定原因，更可能破坏原本正常的数据连接。

安装失败应先核对包架构与系统安装提示。主流较新设备通常可选择 arm64，无法确认时按安卓下载说明选择合适入口；通用包体积可能更大，但不等于连接能力更强。更新时保留同一客户端的配置备份，不把 v2rayNG 与 v2flyNG 的完整备份互相覆盖。跨设备迁移优先使用兼容的订阅或节点分享方式，具体边界见电脑与安卓配置迁移。

最后按“应用进入接管范围、内核收到请求、节点建立连接、目标返回响应”逐层验收。若桌面与手机在同一无线网络使用同一节点却表现不同，重点比较权限、分应用范围和 DNS；若两端同时失败，回到节点与网络路径。求助时说明系统版本、客户端名称、网络类型、锁屏关联和脱敏错误即可。保持可复现的最小场景，比连续更换多个客户端更容易定位真正的故障层。