V2Ray 故障排查
节点、订阅与系统代理

无法上网：先区分基础网络与代理链路

“无法上网”不是一个足够明确的故障结论。先记录三个现象：关闭代理后普通网站是否可访问，开启代理后是否所有网站都失败，以及问题是否只出现在某一个应用。暂时退出其他代理或 VPN 工具，避免多套规则同时接管流量。保存当前节点与路由模式的名称，后续测试始终使用同一目标页面，不要在更换节点、切换网络与调整 DNS 之间来回跳转，否则很难判断哪项修改有效。

关闭代理，建立直连对照

在 v2rayN 中先选择清除系统代理，再关闭 TUN 模式。仅关闭主窗口未必会退出客户端，应检查托盘是否仍有后台进程。重新打开浏览器访问一个平时能够直连的网站。如果此时也失败，先检查无线网络、网线、网关和网络登录页面；公共网络可能要求先完成认证。不要在基础网络尚未恢复时继续改节点参数。若其他设备在同一网络正常，而当前电脑仍失败，再检查本机防火墙、固定代理和手动 DNS 设置。

直连恢复后，启动 v2rayN，确认节点列表中有可用配置并选为活动服务器。观察日志是否出现内核退出、配置解析失败或端口绑定失败。客户端窗口能够打开，只说明图形界面在运行，不代表代理内核已经监听端口。找到参数设置中的实际本地端口，再与日志中的监听地址核对。不要默认所有客户端都使用同一个端口，也不要把服务端连接端口填成本地代理端口。

分开验证本地监听与远端连接

确认本地 HTTP 或混合入口后，可以绕开系统代理设置，显式指定代理进行测试。下面命令适用于 Windows PowerShell，示例假定客户端的 HTTP 或混合监听端口确为 10808；如果实际配置不同，先替换为对应端口。测试地址用于确认 HTTPS 请求链路，不代表业务网站一定可访问。若该端口仅提供 SOCKS 服务，应使用下一章的 SOCKS 测试方式，不能直接套用 HTTP 参数。

curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com

如果命令立即提示无法连接到本地地址，优先查内核是否启动、端口是否一致；如果已经连上本地代理，随后报告远端握手失败，则转到节点章节。命令成功而浏览器失败，通常应检查浏览器独立代理、扩展设置和系统代理，而不是继续更换服务器。网站返回重定向、拒绝访问或其他 HTTP 状态，说明已经收到应用层响应，不应简单归为“网络不通”。

缩小到路由、应用或目标网站

暂时切换到客户端提供的全局代理路由，用同一节点重试一次。若全局可用而分流模式失败，重点检查目标域名是否被直连规则命中、规则数据是否正常加载，以及 DNS 结果是否影响地址规则。全局模式只是诊断对照，确认问题后应恢复原模式。若只有一个应用失败，检查它是否遵循系统代理；有些应用需要自己的代理设置，有些连接只能在正确配置的 TUN 或 VPN 接管范围内处理。

修复后至少验证两类访问：一个应当直连的页面、一个应当经过代理的页面。随后关闭并重新启动客户端，确认状态能够保持。若退出后直连再次失败，通常有残留的系统代理或网络设置，应继续阅读系统代理不生效章节。首次操作不熟悉时，可回到快速上手对照主线；概念类疑问集中放在FAQ。

节点超时：按地址、端口与握手逐层定位

先区分“客户端测试超时”和“实际访问超时”。不同测试入口可能使用 TCP 建连、指定网页请求或其他检测方式；某一种测试失败，不能直接证明整个节点失效。使用浏览器和显式代理命令交叉确认，再判断是单个节点异常、同一订阅内全部异常，还是所有来源的节点都异常。单个失败更接近节点参数或服务端状态问题，全部失败则应先排除本机、当前网络和内核启动异常。

核对服务器地址与远端端口

打开节点编辑页，核对服务器地址、服务端端口、协议和传输方式。地址栏不应混入协议前缀、路径或多余空格，除非该字段明确要求完整 URL。端口必须对应服务提供方给出的入口，不能因为看到 10808 就把远端端口也改成该值。刚更新订阅后，确认当前选中的确实是更新后的配置；有些界面保留旧条目或旧选择状态，需要重新选定活动服务器。

在 Windows PowerShell 中，下面的命令可检查指定主机与 TCP 端口是否能建立连接。示例域名是文档示例，实际排查时替换为节点服务器域名和真实端口。结果只反映 TCP 建连，不验证协议认证、传输路径和 TLS 参数，也不适用于把 UDP 服务直接当成 TCP 服务判断。若失败，先换一个网络进行相同测试，再向服务提供方确认入口是否变更。

Test-NetConnection -ComputerName example.com -Port 443

域名解析失败时先进入 DNS 章节。能够解析但 TCP 失败，可能涉及网络路径、远端监听、防火墙或服务不可用；本地反复修改加密选项一般没有帮助。TCP 成功仍然超时，则继续看客户端日志中的握手与认证信息。排查时保留错误前后几行即可，分享日志前删除订阅地址、用户标识和认证字段，不要把完整配置公开发送。

区分 TLS、传输层与协议参数

TLS 证书错误先检查系统日期、时区与时间同步，再核对 SNI 或服务器名称。服务器地址与 SNI 可能不同，不能用“两个字段保持一样”的办法代替服务方配置。使用 WebSocket 等传输时，还需要匹配路径、Host 和安全层；路径通常区分大小写，开头的斜线也可能影响结果。出现握手被关闭并不一定是证书问题，也可能是请求发到了错误的服务入口。

VLESS、VMess、Trojan 等配置的认证与传输要求不同，不能只改协议名称沿用其他字段。REALITY 配置还需要匹配服务端给出的公钥、短标识与服务器名称等参数，应以原始配置为准，不要从网上拼凑参数。不要把允许不安全连接作为通用修复方式；跳过证书验证既不能修好错误路径，也会削弱身份验证。证书问题可进一步查看TLS 握手与系统时间排查。

用单变量对照确认故障归属

如果客户端提供 SOCKS 入口，可用下面命令让目标域名通过代理侧处理。这里同样假定本地 SOCKS 监听为 10808，必须先确认入口类型。与 HTTP 代理测试相比，这能帮助判断应用代理方式是否配置错误，但不能证明所有路由与 DNS 请求都在远端完成，具体仍取决于内核规则。

curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com

同一配置换网络后恢复，说明当前接入网络值得重点调查；同一网络换节点后恢复，说明原节点或其路径更可疑。若所有对照都失败，检查内核是否支持该配置包含的字段，再考虑从下载页选择对应平台客户端。不要为排查随意切换多种内核并覆盖原配置。完整分层顺序见节点超时排查文章，提交问题时附上已完成的对照结果。

订阅失败：区分下载错误与内容解析错误

订阅更新包含两个独立过程：先取得内容，再把内容解析成客户端支持的配置。“更新失败”可能发生在任一阶段。先看提示是否属于连接超时、HTTP 状态错误、证书错误，还是格式无法识别、没有有效节点。前一类应检查访问链路，后一类应检查响应内容与订阅格式。不要一开始就删除整个订阅分组，否则旧配置和故障前后的对照信息都会丢失。

检查订阅地址与响应类型

从服务提供方重新复制订阅地址，检查首尾空白、换行和聊天软件附加的标点。部分地址包含查询参数，复制时遗漏后半段会导致身份识别失败；不要自行删改看似复杂的参数。账号页面链接、购买页面链接和客户端订阅链接用途不同，能在浏览器打开一个网页，不代表它就是可导入订阅。完整链接可能具有访问权限，应按敏感信息保管，不要放在公开截图、搜索框或第三方解析页面。

若返回未授权或禁止访问，先检查订阅是否到期、链接是否被重置，以及服务端是否限制访问方式；若返回找不到资源，核对路径是否已变更。请求成功却解析为空，可能拿到登录页、维护页、访问验证页或错误说明。不要看到成功状态就断言是客户端损坏。可以在本地查看响应开头是否明显属于网页文本，但查看时避免把包含凭据的完整内容复制进日志或公开工单。

选择合适的更新链路

若当前网络无法直连订阅服务器，但已有可用节点，先选中该节点，再使用客户端提供的通过代理更新方式。普通更新与代理更新是否独立于系统代理，取决于客户端实现，不能只看系统代理开关判断。反过来，如果客户端把更新请求送进一个已经失效的节点，切换为直连更新反而可能恢复。每次只改变更新方式，保留同一订阅地址，才能确认链路差异。

首次配置没有可用节点时，不能依赖尚未建立的代理来取得订阅。应在允许访问的网络环境重试，或向服务提供方索取客户端支持的其他导入方式。不要为绕过失败随意关闭证书验证，也不要使用来源不明的订阅转换服务。更新频率保持适度；连续快速点击可能触发服务端限流，遇到明确的限流响应应等待后重试，而不是重复创建多个相同分组。

确认格式、编码与客户端能力

分享链接、编码后的链接集合和结构化配置并不是同一种格式。某些订阅提供方按客户端生成不同内容，应选择适配 v2rayN、v2rayNG 或 v2flyNG 的入口。手动处理编码前先保留原文，避免二次编码、截断或把换行转成普通字符。不要把其他软件的配置直接改扩展名导入；文件名不会改变内部结构。解析提示不支持协议或字段时，应核对客户端及内核能力，而不是随意删除报错字段。

更新提示成功但列表未变化时，检查当前显示的分组、搜索条件和隐藏规则，确认没有只看收藏或其他筛选结果。节点被移除也可能是订阅端主动调整，并非客户端漏导入。必要时新建一个临时分组做对照，但不要立即覆盖原分组。恢复后手动选定节点并实际访问一次，因为订阅更新成功不等于节点连通。具体导入操作见订阅导入教程，内容检查见订阅解析失败自查。

速度慢：分开测建连、吞吐与应用体验

先描述“慢”发生在哪个阶段：打开页面前等待很久、页面主体出现后图片慢，还是持续下载时速率低。建连等待可能涉及 DNS、握手或目标站响应，持续传输则还受带宽、丢包、拥塞与服务端负载影响。客户端里的延迟结果只是某种检测方法的输出，不代表可用下载带宽；更不能用一次测试高低推断节点长期质量。先保留当前模式与节点，建立可以重复的测试条件。

排除本地带宽和设备负载

关闭系统更新、大型下载、云同步和其他占用网络的任务，观察同一接入网络中的设备是否也在传输。无线信号看似满格仍可能受到干扰，可靠近接入点或用有线网络做对照。若直连访问同样缓慢，应先解决基础网络，而不是持续替换代理配置。移动热点与固定网络是有用的对照，但测试时注意移动网络的计费和流量限制，不要反复运行大文件下载。

同时观察任务管理器或系统监视器中的 CPU、内存和磁盘活动。设备高负载、存储空间不足或过热都会影响浏览器与客户端响应；此时网络看似卡顿，实际瓶颈可能在本机。TUN 接管大量应用流量、复杂规则和高频日志也可能增加负担。先暂停无关任务，再比较普通系统代理与 TUN 模式，不要通过降低验证要求或关闭系统防护来换取表面上的速度提升。

建立公平的节点与路径对照

测试节点时保持目标网站、网络、客户端模式和测试时段尽量一致，一次只替换一个节点。不要同时测试多个节点的大流量下载，它们会争用同一本地带宽。地理距离近不必然更快，网络互联、远端出口和拥塞状况同样重要。一个目标站慢而其他站正常，可能是该站本身、内容分发路径或对远端出口的限制，不应立即把问题归到所有代理连接。

如果全局路由快、分流模式慢，先确认慢请求最终走的是代理还是直连。网页通常涉及多个域名，主页面加载正常而图片迟迟不出，可能是资源域名匹配到了不同出口。临时启用适量访问日志，找出失败或等待较久的资源域名，再修改相应规则。不要仅凭地址栏里的主域名添加规则，也不要长期启用极详细日志进行日常下载，以免增加磁盘压力和暴露访问记录。

识别连接复用、UDP 与 MTU 边界

多路复用不是必开的提速选项。它可能减少重复握手，也可能在某些链路上放大拥塞或产生兼容问题，应按节点要求并用相同场景对照。网页采用的 HTTP/3 等机制涉及 UDP，系统 HTTP 代理并不等于接管所有 UDP 请求；应用可能回退到其他连接方式，表现为首次加载等待。优先确认应用实际使用的传输与接管范围，不要把所有延迟都解释成节点带宽不足。

只有在 TUN 模式下出现特定大页面、上传或长连接卡住，而普通系统代理正常时，才把 MTU 作为后续排查项。先记录默认值，参考当前网络与客户端说明逐步调整，每次修改后重建连接并复测。过小会增加分片与处理开销，随意套用网络文章里的固定值也可能掩盖真正问题。MTU 并不能修复认证失败、证书错误或远端服务停机，应在基本连通已经确认之后检查。

修复后的判断标准应回到真实任务：页面能否稳定打开、会议或长连接是否中断、持续传输是否保持。若只在特定时段慢，记录多个时段的对照结果并向服务提供方反馈，避免在本机频繁改动全部参数。若等待集中在首次访问、按 IP 与域名访问表现不同，转到下一章检查 DNS；若只有某个应用慢，则检查其独立代理与分流规则，而不是继续全局换节点。

DNS 问题：查清解析位置与请求出口

DNS 负责把域名转换成地址，但一次访问可能同时涉及系统解析器、浏览器安全 DNS、客户端内置 DNS 和代理服务器侧解析。出现域名打不开而其他连接正常时，先确定是哪一层失败。日志里的服务器域名解析失败与目标网站域名解析失败并不相同：前者可能让代理连接根本无法建立，后者发生在已经选择出口之后。不要只修改一个公共 DNS 地址，就认定整条解析链路已经改变。

先检查系统解析与缓存

下面的 Windows 命令用于查看系统可用的解析结果与清理本机 DNS 缓存。查询示例域名只是建立对照，实际故障还应查询目标域名和节点服务器域名。能够得到地址不代表地址一定符合目标服务预期；不同解析器、网络和地理出口返回不同结果也可能正常。执行清理前先记录原结果，清理后重开应用并再次查询，避免只凭页面偶然恢复判断原因。

nslookup example.com
ipconfig /flushdns

如果查询直接超时，检查系统当前配置的 DNS 服务器是否可达，以及是否被固定到已经离线的局域网设备。企业或校园网络可能依赖内部 DNS 解析专用域名，盲目替换成公共地址会让内部服务失效。恢复自动获取可以作为对照，但修改前记录原设置。缓存清理只能移除旧结果，不能修复上游不可达、错误的路由规则或服务端没有记录等问题。

分辨浏览器、系统与代理解析

浏览器可能启用独立的安全 DNS，因此命令行查询正常而浏览器失败并不矛盾。先检查浏览器是否使用自定义解析器、代理扩展或独立网络配置，再用其他遵循系统设置的应用做对照。不要同时修改浏览器安全 DNS、系统 DNS 和客户端 DNS，否则无法判断是哪一层起作用。使用加密 DNS 时还要确认解析服务本身能通过当前网络或代理访问，避免为解决一个域名问题又引入新的连接依赖。

SOCKS 测试中，socks5h 的用法可以把目标主机名交给代理侧处理，而普通本地解析路径可能不同。若两种方式表现不同，应检查本地解析与代理侧解析的差异，但这仍不能证明客户端所有域名都按同一路径处理。路由策略、内核 DNS 和应用自己的解析逻辑会影响最终结果。不要用 HTTPS 地址直接替换成 IP 来简单验证，因为证书、SNI 和虚拟主机也依赖原域名。

检查分流依赖与解析循环

使用域名规则时，请求可能直接按域名选择出口；使用地址规则时，内核可能需要先解析域名才能继续匹配。某些策略如 IPIfNonMatch 只在域名规则未匹配时尝试解析，并不是“始终远端解析”的开关。调整策略前先理解规则顺序，确认问题域名是否在前面的规则就已被选定出口。若代理服务器自身的域名需要通过尚未建立的代理去解析，就可能形成启动依赖循环。

TUN 场景还可能涉及虚拟 DNS 地址与地址映射。虚拟地址不能当成真实服务器地址填回节点配置；应用或内核重启后，旧连接保留的映射也可能失效。修改相关设置后应重建受影响应用的连接，必要时重启客户端，而不是继续沿用原标签页中的长连接。只有 TUN 下出问题时，先回到普通系统代理模式验证，缩小到虚拟网卡、DNS 接管或路由冲突，再检查高级参数。

最后验证应覆盖代理目标与局域网资源。若网页恢复而打印机、内部域名或本地服务失效，说明分流或内部解析仍需修正。不要长期把所有未知域名强制交给单一出口当作最终方案。涉及域名规则、地址规则和内核名称的概念，可查名词解释；如果日志已显示正确解析而远端握手仍失败，应回到节点章节，避免在 DNS 设置中反复试错。

系统代理不生效：核对模式、监听与应用行为

系统代理是把代理地址告知愿意遵循该设置的应用，不是自动接管所有网络请求。v2rayN 的自动配置系统代理、清除系统代理和不改变系统代理，分别表示写入、移除或保留现有系统代理状态；它们与路由中的全局、绕过大陆、直连不是同一层设置。前者决定应用如何进入客户端，后者决定请求进入客户端之后从哪个出口离开。混淆这两层，是“选了全局却没效果”的常见原因。

确认内核监听与入口类型

先在参数设置中查看实际本地监听地址、端口与协议，再检查系统代理指向是否一致。HTTP、SOCKS 和混合入口不能只凭端口数字区分；混合入口能够接受的协议应以客户端说明为准。旧配置可能使用不同端口，不应强行套用教程中的默认值。监听在本地回环地址适合本机使用，不需要为排错改成所有网卡监听；扩大监听范围还会带来额外访问边界问题。

Windows 可以用下列命令查看 10808 是否被监听，以及对应进程。第一条是 PowerShell 查询，第二条是命令提示符或 PowerShell 都可调用的系统工具。若没有结果，先看内核日志；若显示其他进程占用，记录进程标识后在任务管理器核对程序来源。不要直接结束无法识别的系统进程，也不要认为看到端口监听就证明监听者一定是当前客户端。

Get-NetTCPConnection -LocalPort 10808 -State Listen
netstat -ano | findstr ":10808"

确认冲突后，优先正常退出占用端口的另一个代理工具，或者在 v2rayN 参数设置中选择未占用端口。修改后需要重启相关内核，并重新执行自动配置系统代理；浏览器独立代理、终端环境变量和其他手动设置也要同步更新。只改监听端口、不改应用入口，会造成客户端正常运行但请求仍送往旧端口的现象。详细定位见本地端口占用处理。

区分不同平台的系统入口

如果显式指定代理的命令可用，而普通应用不行，优先检查应用设置。浏览器扩展可能覆盖系统代理，终端可能继承旧的代理环境变量，服务进程也可能使用独立配置。Windows 的 netsh winhttp show proxy 查看的是 WinHTTP 代理，不能代表所有浏览器与桌面应用正在使用的代理状态。不要因为该命令显示直连，就不断重复写入另一套系统设置。

处理退出残留与 TUN 接管

客户端异常退出后，如果系统还指向本地代理端口，而内核已经停止，所有遵循该设置的应用都会连接失败。先重新启动客户端并执行清除系统代理，再检查系统代理页面中的手动入口或自动配置脚本是否仍然存在。若由组织策略管理，不要强行覆盖。正常退出时也应验证直连恢复，而不是仅关闭窗口。多个代理工具同时运行时，后写入者可能覆盖前者设置，应先退出其他工具再验证。

TUN 用于通过虚拟网络接口接管流量，需要相应权限、路由与防火墙配合，不是系统代理开关的另一种名称。普通代理已经可用后，再单独启用 TUN 并观察日志。如果启用后立刻断网，先关闭 TUN 回到已知可用状态，检查虚拟网卡、其他 VPN 和安全软件冲突。修复后逐个启动应用确认接管范围，保留局域网与必要直连访问，不要把“所有请求进入客户端”误认为所有请求都必须走远端代理。

客户端崩溃：区分界面退出与内核启动失败

先确认失败发生在哪一层：双击后完全没有窗口、窗口打开后立即退出、主界面正常但启动连接失败，还是使用一段时间后进程消失。图形界面与代理内核可能是独立进程，内核退出并不总会关闭主窗口。记录触发动作、错误原文与系统架构，再决定是否重装。不要连续删除配置、重建订阅和切换内核，否则既可能丢失设置，也会让原故障无法重现。

启动失败先查包型、目录与运行环境

从获取客户端页面选择与系统和处理器匹配的入口。桌面首推 v2rayN；Windows 桌面版与经典 WPF 版的界面技术和运行要求不同，应查看对应包的要求，不要把一个包缺失的组件文件直接复制进另一个包。macOS 需要区分 Apple Silicon 与 Intel，Linux 除了架构，还应选择适合发行版的软件包类型。错误架构或缺失运行环境通常不能靠修改代理规则解决。

若所选包需要解压，应先完整解压到当前用户有写入权限的目录，不要直接在压缩包预览窗口运行。路径过长、目录受保护或文件被安全软件隔离，都可能造成启动组件缺失。先查看系统提示与安全软件记录，核实被处理的是哪个文件，不要直接关闭全部防护。安装包形态则按正常安装流程操作，不应把它和便携目录中的零散文件混放。Windows 的常见选择见安装配置与包型说明。

内核退出先看配置与端口

主界面正常而内核不能启动时，先查日志中的第一条明确错误。端口绑定失败进入端口章节；字段无法识别或配置解析失败，应回想是否刚导入自定义配置、修改高级参数或切换内核。新配置可能包含当前内核不支持的字段，也可能存在 JSON 语法错误。不要只盯日志最后一句“进程退出”，它通常只是结果，真正原因在前面的解析或启动信息中。

下面是合法 JSON 的最小日志设置片段，只用于说明对象、字段和字符串写法，并不是可以直接启动的完整代理配置。实际使用时应通过客户端支持的设置入口调整日志级别，或在完整配置的正确位置修改；不要将这一小段覆盖整个配置文件。排查结束后恢复常规日志级别，避免长期积累大量访问记录。

{
  "log": {
    "loglevel": "warning"
  }
}

配置中多一个尾逗号、引号未闭合、把数字写入要求布尔值的字段，都可能导致解析失败。使用 JSON 语法检查只能确认结构是否合法，不能验证字段是否属于当前内核。若没有明确需要，优先回退刚修改的高级选项，使用图形客户端生成配置。排查内核切换时，应先恢复该内核支持的节点与参数组合，不要把 Xray 与 V2Fly 视为所有字段都可以互换的同一个程序。

通过备份与干净环境做对照

完全退出客户端后，按该客户端的存储方式备份配置目录或导出设置。备份可能包含订阅与认证信息，应放在受控的本地位置。保留原目录不动，在独立目录或新的应用配置环境中启动一个干净实例；测试时不要同时运行两个实例争用相同端口。若干净环境正常，逐步恢复订阅与必要设置，而不是一次覆盖所有旧文件。若同样失败，继续检查运行环境、文件权限和系统级错误记录。

升级后异常也应先保存现状，确认新旧包未混装、旧进程已经退出、配置迁移是否完成。不要在客户端运行中替换正在使用的文件。macOS 遇到系统安全提示，应核对提示类型与系统提供的处理入口；Linux 应查看启动输出及桌面会话相关依赖，而不是一律使用更高权限运行。恢复后检查订阅、系统代理和退出清理是否正常，再移除临时测试目录。提交问题只提供必要错误、系统架构与复现步骤，不附完整私有配置。

移动端专项：检查 VPN 权限、分应用与后台限制

Android 首推 v2rayNG，使用 Xray 内核；v2flyNG 作为 V2Fly 内核备选。两者的配置能力和设置入口并不完全相同，不应因为界面相似就逐项照抄。排查前记录当前应用、所选节点、工作模式和接入网络，再确认故障是首次连接就失败，还是锁屏后中断、切换网络后失效，或仅部分应用无法访问。先让一个客户端在单一网络下稳定工作，不要同时启动两个 VPN 连接进行比较。

首次连接检查授权与 VPN 占用

使用 VPN 模式时，系统通常会要求确认建立本地 VPN 连接。若此前拒绝，应再次启动连接并查看授权提示；按钮显示已启动不代表所有应用流量都已经进入 VPN。检查系统是否有其他 VPN、工作资料中的网络工具或始终开启的 VPN 配置占用。部分系统支持按资料分别管理网络，个人资料与工作资料中的应用也可能受到不同策略控制，不能仅凭通知栏图标判断全部应用已经接管。

仅代理模式通常只提供本地代理入口，不会自动把其他应用的请求全部转入客户端。若系统或应用没有配置相应入口，表现为节点能测试、浏览器却未经过代理，这并不矛盾。先明确需要 VPN 接管还是仅本地代理，再按目标应用支持的方式配置。系统 VPN 页面若启用了阻止未经过 VPN 的连接，客户端未建立隧道时可能导致基础网络也不可用，应理解该选项作用后再做对照，不要反复重装客户端。

部分应用失败先查分应用代理

检查分应用代理是否启用，以及当前使用的是允许列表还是绕过列表。相同的应用列表在两种模式下含义相反：一种只让列出的应用进入代理，另一种让列出的应用绕过。新安装、分身或工作资料中的应用可能对应不同身份，需要重新确认列表。浏览器可用而某个应用失败时，先检查它是否被排除、是否使用独立网络方式，再查看目标域名是否被路由规则直连。

不要为了让一个应用恢复就把全部域名改成同一个 DNS 或出口。可以暂时关闭分应用过滤，使用同一节点和同一网络测试目标应用；若恢复，再逐步补齐列表。应用内部也可能缓存连接，修改设置后应结束并重新打开该应用。系统浏览器、内嵌网页与独立应用的网络行为未必一致，因此一次网页登录成功不能替代对实际目标应用的验证。排查涉及账号会话时，不要把登录信息写进公开日志。

锁屏断连与切网失败分开处理

锁屏或切到后台后才断连，优先检查电池优化、后台运行限制与厂商系统的进程清理策略。在理解耗电影响的前提下，为正在使用的客户端允许必要后台活动，并查看通知是否仍然存在。不要一次给所有应用关闭电池管理；只对故障相关客户端做对照。若进程仍在但连接失效，应检查网络是否在休眠时切换、远端连接是否需要重建，以及系统日志中是否出现 VPN 被撤销的信息。

Wi-Fi 与移动网络切换后，原连接可能依赖已经变化的地址与网络路径。先停止并重新启动客户端连接，再打开目标应用测试，区分“重连即可恢复”与“某一种网络始终失败”。若只在公共 Wi-Fi 失败，先完成网络登录认证；若只在移动网络失败，检查该网络的基础连通、DNS 与访问路径。不要通过反复切换飞行模式替代记录原因，也不要在没有证据时随意改 APN 或系统底层网络参数。

安装兼容与最终恢复检查

安装失败时，核对处理器架构、系统要求、可用存储空间与是否存在同名应用的签名冲突。主流较新设备通常适合 arm64，不能确定时按下载页说明选择通用包；不要从其他应用目录抽取文件手动补齐。覆盖安装受阻时先备份配置，理解系统提示后再决定是否卸载，卸载可能清除订阅和设置。包型选择统一在Android 下载入口完成，不要混用两个客户端的配置目录。

如果 v2rayNG 正常而 v2flyNG 在同一节点上失败，应先核对协议及参数是否属于该内核支持范围，而不是立即判定设备异常。反馈时写明客户端名称、网络类型、工作模式、分应用策略和触发步骤，附上删除敏感字段后的错误片段。需要重新走配置主线时返回快速上手教程；只想确认某个设置含义时查阅常见问题，避免用重装替代定位。