V2Ray 故障排查大全

无法上网：从应用到出口逐层检查

客户端显示正在运行，只能说明界面或内核进入了某种工作状态，不代表目标网站已经可以访问。先把现象分清：所有程序都失败、只有浏览器失败，还是部分网站失败。记下首次出现时间、最近改过的设置，以及切换网络后是否相同。这样的记录比反复点击连接更有用，也能避免把网站自身故障误当成客户端配置错误。

建立可以对照的基础连接

先停止客户端接管，并确认系统代理已经恢复，再访问平时可以直接打开的站点。若此时仍失败，应先检查无线网络、网线、网关和网络登录页面；需要网页认证的公共网络，要先完成认证。基础网络正常后，再启动客户端，选定一个已有的有效配置。测试期间只保留一个代理客户端，暂停其他会改变网络出口的工具。

接着判断本地入口是否可用。在 v2rayN 中查看实际的 HTTP 或 SOCKS 监听地址与端口，不要凭其他教程里的数字填写。若浏览器使用手动代理，其协议必须与监听入口对应，地址通常指向本机。将 SOCKS 入口误填到 HTTP 栏，或者把远端服务器端口填成本地代理端口，都可能表现为页面完全打不开，而节点配置本身并未出错。

用日志分开“没有接入”和“接入后失败”

打开客户端日志后，重新访问一个明确的目标。如果完全没有对应连接记录，优先检查浏览器是否绕开系统代理、扩展是否覆盖了设置，以及目标程序是否根本不读取系统代理。若日志中出现目标域名，再看错误发生在解析、连接还是握手阶段。日志可能合并重复消息，不能仅凭没有新增一行就断定流量未进入；必要时临时提高日志详细程度后复测。

对于“某个网站失败，其他网站正常”的情况，检查路由是否把该域名送入了不合适的出口。临时使用客户端提供的全局代理路由进行对照，可以帮助缩小范围，但测试结束应恢复原方案。若全局路由能打开、原规则不能打开，继续查规则顺序、域名匹配和直连 DNS；若两种路由都失败，应转向节点连接和目标服务状态。

识别认证、证书和旧连接的干扰

看到证书错误时，先检查系统日期、时区与时间同步，再核对节点的服务器名称配置。不要通过关闭证书验证来掩盖问题。若浏览器能打开网页但某个应用不能联网，还要检查该应用是否使用独立代理、固定连接池或后台服务。修改系统代理后，已经建立的连接未必立即重建，完全退出应用再打开，往往比只刷新当前页面更能反映新配置。

如果启用 TUN 后所有流量中断，而关闭后浏览器恢复，检查权限、虚拟网卡、路由和 DNS 接管，不要立刻重装整个客户端。先保存当前设置，恢复到“单客户端、单节点、系统代理”的最小工作状态，再逐项加回规则。每次测试都使用相同页面，并记录错误文字；“打不开”需要进一步变成超时、连接被拒绝、名称解析失败或证书验证失败。

恢复后至少验证三件事：普通网页可以完成加载，需要代理的应用能建立新连接，关闭客户端后基础网络仍然可用。如果只有部分资源缺失，检查浏览器开发者工具里的失败域名，而不是继续切换整套配置。更细的操作顺序可对照已连接却无法上网的逐项排查清单；尚未完成首次配置的情况，回到教程主线更合适。

节点超时：区分端口、传输与握手失败

超时不是单一原因，而是连接链中某一步没有在规定时间内完成。客户端的测试工具可能测 TCP 建连、经过代理的 HTTP 请求，或其他探测过程，不同测试不能直接混为一谈。先确认使用的测试类型，再尝试实际访问。单个节点测试失败不等于整个订阅失效，端口可达也不等于认证与传输参数正确。

先确认是一个节点，还是整个环境

在同一网络、同一客户端设置下，分别测试两个不同来源或不同线路的有效节点。如果只有一个失败，重点检查该节点和服务端状态；如果所有节点同时失败，再检查本机时间、网络出口、防火墙与内核启动情况。随后换到另一种可用网络进行短暂对照。网络切换会同时改变解析和出口，因此只能说明故障与环境有关，不能据此直接判断某个具体设置错误。

核对服务器地址和端口时，以订阅或服务方提供的完整信息为准。域名后不要重复带上协议头，端口栏不要混入路径。手工配置还要留意前后空格、全角标点和复制遗漏。对于域名地址，先确认本机能够解析出结果；对于地址发生更新的服务，应重新获取配置，而不是长期固定一次查询得到的地址。

按错误出现的阶段缩小范围

这些词只是排查入口，不是原因的最终结论。例如连接被拒绝通常说明连接收到了明确拒绝，但拒绝可能来自远端服务或路径中的设备；超时则无法仅靠一行日志区分丢包和服务无响应。记录错误前后的几行信息，尤其是连接目标和所用出站。不要把目标网站拒绝连接与代理服务器拒绝连接混在一起，两者所在层级不同。

传输配置必须成组一致

使用 TLS 的节点应核对服务器名称、传输协议与服务端要求。WebSocket 的路径和 Host、gRPC 的服务名称等参数，需要与服务配置匹配，不能只改协议名称。VLESS 配合 REALITY 时，还应核对公钥、短标识、服务器名称和流控等适用参数。字段是否必填取决于具体组合，最稳妥的办法是重新导入完整链接，而不是拼接来自不同教程的字段。

系统时间偏差会影响证书有效期判断，也可能影响部分协议的认证过程。先通过系统设置同步时间，再重启内核建立新连接。遇到证书链问题时，应检查系统信任库是否正常，以及网络是否存在需要登录的认证页面。不要把跳过验证设成常驻方案；有关服务器名称与时间的分支，可继续阅读TLS 握手与证书报错排查。

最后判断是否需要更新客户端或内核。只有日志明确提示不支持字段、无法识别协议或配置解析失败时，更新才是直接相关的动作。更新前保存配置，从客户端下载页选择对应平台；更新后仍用原节点复测，避免同时更换线路。若节点本身失效，应向服务方确认参数与维护状态，不要通过持续缩短测试间隔制造更多连接请求。

确认恢复时，除了一次测试通过，还应建立实际网页连接并观察是否持续可用。保存有效的节点参数与测试环境，撤销临时添加的防火墙例外和调试设置。超时再次出现时，就能用这份基线判断是节点变化、网络变化，还是本机设置发生了回退。

订阅失败：检查地址、获取路径与内容格式

订阅更新分为获取内容、解析内容、写入分组三个环节。更新按钮提示失败时，先看错误属于哪一环：连接超时通常发生在获取阶段；返回内容无法识别可能属于解析阶段；更新完成但节点不见了，则要检查分组筛选和内容变化。不要一开始就删除原订阅，仍能工作的旧节点可以保留，用来维持连接和对照问题。

确认地址完整，并保护订阅凭据

从服务方页面重新复制订阅地址，检查开头、结尾和查询参数是否完整。聊天软件换行、浏览器复制显示文本而非真实链接、手动删掉问号后的参数，都会让地址失效。订阅地址往往包含访问凭据，不要把完整地址贴到公共讨论区，也不要上传到不明转换服务。需要求助时，只描述错误类型，截图前遮住地址、账户信息和节点认证字段。

核对账户页面是否提示到期、停用、流量用尽或订阅地址已经重置。能登录服务页面，并不意味着原订阅地址仍有效；同样，网页能打开也不能证明订阅接口正常。若服务方明确提供了新的地址，应编辑现有分组并更新，避免重复创建多个名称相近的分组。保留原分组备注，便于确认哪些节点属于同一来源。

把订阅获取与节点连接分开

节点连接成功，不代表订阅接口一定能通过同一路径访问；节点全部失效时，依赖现有代理获取订阅又可能形成循环。查看客户端是否提供通过代理更新、直接更新或类似选项，先按当前网络条件选择，再分别对照测试。不同客户端与界面的名称不完全相同，不能假定更新订阅始终读取系统代理。

若直接更新超时，但已有节点可以访问订阅服务，可尝试通过当前代理更新；若当前代理已经不可用，而订阅接口能直接访问，则改为直接获取。每次只调整获取方式，不同时修改 DNS 和分组地址。连续失败时稍后再试，避免服务端频率限制。需要网络登录的环境，先完成基础认证，否则获取到的可能是登录网页。

识别格式兼容与节点缺失

订阅内容可能采用编码后的分享链接集合，也可能是某种客户端专用格式。文件名或链接末尾的扩展名不能保证内容适配当前客户端。优先使用服务方明确标注适用于 v2rayN、v2rayNG 或 v2flyNG 的入口。若日志提示不支持某种协议字段，应先核实客户端和内核能力，再更新软件；随意删字段可能让节点保存成功，却在连接时失败。

如果更新没有报错，但只剩部分节点，检查是否启用了关键词过滤、协议过滤或分组筛选。还要查看服务方是否调整了线路清单，以及客户端是否按重复项规则合并了内容。先切回全部分组，再查找一个已知节点别名。不要用“列表数量与昨天不同”单独判断解析错误，服务端内容变动也会产生相同现象。

更新后连接参数变化是另一类问题。原节点可能被替换，当前选中项也可能指向已经移除的记录；重新选择一个更新后的节点，再启动内核。若新订阅可以导入但全部无法连接，转到节点超时章节排查，而不是继续处理获取环节。恢复后保留一份必要的分组设置备份，备份应放在受控位置，不与日志一起公开分享。

验证闭环是：更新操作明确完成，目标分组能找到新内容，选择其中一个有效节点后能建立实际连接。首次添加分组的操作见订阅导入教程；地址管理与常见使用疑问见常见问题。如果同一地址在多个设备上同时获取失败，且账户状态正常，应优先等待或联系服务方确认接口情况，避免对每台设备进行无关重装。

速度慢：分开测延迟、吞吐与应用体验

页面打开慢、视频缓冲和大文件下载慢，不一定由同一个环节造成。延迟描述一次往返的时间，吞吐描述持续传输的能力，丢包和抖动则影响连接稳定性。节点列表里某次测试结果较好，并不能保证所有应用都快。先确定真正影响使用的是首屏等待、持续速率不足，还是间歇断流，再选择对应的对照方法。

建立固定的测试条件

选择一个平时稳定的目标，在相近时间用相同网络、相同客户端和同一种操作测试。暂停系统更新、云同步和其他大流量任务，同时确认同一网络里没有设备占满上传。上传拥塞也会拖慢网页响应，不能只看下载占用。无线信号较弱时，先靠近接入点或换有线网络，避免把本地无线重传误认为远端线路问题。

然后只切换节点，观察同一目标的表现。如果多个节点访问同一个站点都慢，而其他站点正常，应考虑目标站限速、内容分发路径或账户限制。如果同一节点在移动网络正常、固定网络慢，则更像接入路径差异。不要同时运行多组测速；并发测试会互相竞争带宽，结果既不代表日常体验，也不适合横向比较。

从日志与系统占用确认瓶颈位置

传输过程中频繁出现重连、超时或连接重置，先处理稳定性，盲目增加并发通常只会放大问题。查看任务管理器或系统监视器，判断客户端、内核或目标应用是否持续占用较多处理器资源。设备处于节能模式、温度过高、后台扫描频繁时，加密与网络处理可能受到影响。先恢复正常电源与散热条件，再判断是否需要调整软件。

如果浏览器下载正常，而某个应用很慢，检查该应用是否走了不同出口、使用独立代理或选择了不同服务区域。路由规则可能让网页经代理、下载域名却直连，也可能反过来。结合目标域名的连接记录查看实际出站。不能只根据应用名称猜测路径，因为同一应用可能同时使用登录、媒体、更新等多个域名。

谨慎处理传输与 TUN 参数

多路复用并非所有协议与网络环境下都更快。若问题只在启用某项高级传输选项后出现，可恢复该项默认值后对照；不要从不同来源拼凑所谓通用加速参数。协议与内核的组合也有能力边界，服务端没有开启的功能，客户端单方面修改不会增加性能。保持服务方给出的参数完整，比随意更改传输类型更重要。

TUN 模式下出现“小页面正常，大文件卡住”的现象，可以把 MTU、路径发现和 UDP 处理列入候选，但这些不是唯一原因。先关闭 TUN，用系统代理完成相同下载进行对照；若只有 TUN 异常，再检查虚拟网卡与内核日志。确需调整 MTU 时，记录原值并小范围试验，结果不变就恢复，不要长期保留无法解释的网络参数。

DNS 也会影响“看起来很慢”的体验。域名解析重试可能让首次打开等待很久，但文件开始传输后速度正常；这种情况应转到DNS 章节，不要只换高带宽节点。另一个常见误区是浏览器缓存：第二次访问快，可能只是资源已经保存在本机。需要对照首次加载时，应使用新的会话或保持一致的缓存条件。

最终保留的是可重复的改善，而不是某次偶然峰值。用实际业务连续验证，确认没有以频繁断流换取短暂高速度。服务方标注的流量倍率属于计费规则，不是速度保证，选择前应分开理解。关于地区、协议和倍率的选型，可参阅节点选择对照指南。如果基础网络本身已拥塞，客户端设置不能补足接入带宽，应先处理本地和上游网络条件。

DNS 问题：确认由谁解析、结果用于哪里

DNS 把域名转换成地址，但在代理场景中，解析可能发生在系统、浏览器、客户端内核或远端。某个位置查询成功，不等于实际访问使用了同一结果。排查的重点不是一开始就换解析服务器，而是确认失败请求由谁发起、解析走哪条路径，以及得到的地址是否影响了路由选择。名称解析和连接出口需要一起看。

先区分解析失败与连接失败

日志明确出现域名解析失败时，记录具体域名，并与同一时间其他域名的结果比较。如果所有域名都失败，检查解析服务本身及其访问路径；若只有一个域名异常，考虑权威记录、缓存或目标域名状态。直接用地址访问网站不是可靠的替代测试，很多站点依赖服务器名称、证书和虚拟主机，地址能通也不代表域名访问链正常。

可以使用系统自带工具观察系统侧解析。Windows 中可运行 nslookup example.com；它用于确认系统查询是否收到响应，不代表浏览器的加密 DNS 或客户端内置解析一定相同。对照时记录查询时间和所用网络，不要只保留一个地址结果。若系统能解析而客户端报错，应继续检查内核 DNS 设置，避免反复清理系统缓存却没有改变真正的故障环节。

理解域名策略与规则顺序

路由规则可以按域名匹配，也可以按地址匹配。当域名规则没有命中时，一些策略会进行解析，以便继续检查地址规则。下面是 V2Ray/Xray 路由对象的局部示例，用于理解字段位置，不是可以独立运行的完整配置。它也不等同于 DNS 服务地址设置，不能通过只改这一行解决所有名称解析问题。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch"
  }
}

IPIfNonMatch 表示在域名未匹配已有规则时尝试解析，再进行相关地址匹配。实际结果还取决于规则顺序、解析结果与默认出站。把策略改为另一项会改变判断时机，并不保证路由更准确。先确认目标域名应当走哪个出口，再看为什么没有命中相应规则。更多概念见路由与分流术语。

避免解析请求与代理形成依赖循环

如果代理服务器地址是域名，而解析这个域名所需的 DNS 请求又只能通过尚未建立的代理发送，就可能形成启动循环。使用加密 DNS 时，其服务地址本身也可能需要先解析。处理时应在客户端支持的范围内，为服务器域名保留可用的引导解析路径，并确认这条路径在代理尚未工作时能够访问；不要未经核实就添加复杂的远程解析链。

TUN 接管下还要确认系统 DNS 请求是否被接收、转发和正确路由。若同时启用浏览器加密 DNS、系统加密 DNS 与内核 DNS，不同程序可能出现不同结果。先选一个清晰的测试路径，临时停用其他层的自定义设置，再逐项恢复。若使用 FakeDNS 一类映射机制，关闭接管后应让相关应用重建连接，避免继续使用只在该机制中有意义的映射地址。

双栈网络也需要纳入检查。域名可能同时返回两类地址，而某一类网络路径不可用，表现为间歇等待或部分应用失败。先观察实际连接使用哪类地址，再通过客户端提供的地址选择设置做短暂对照。不建议把全系统关闭某类地址当作第一步，因为这样可能掩盖路由、网关或上游网络的真实问题，并影响其他应用。

恢复验证时，分别检查系统查询、客户端日志和实际网页访问，确认三者没有互相矛盾。然后切换一次网络，检查新的网络是否改变了 DNS 下发或引导条件。若仅修改解析地址后短暂恢复，过一段时间又失败，还需观察缓存到期后的表现。记录“解析结果正常但连接失败”这一分界，后续就应转查出站和目标服务，而不是继续无限替换 DNS。

系统代理不生效：核对入口、权限与 TUN

系统代理是一组交给应用参考的代理设置，不是强制接管所有程序的开关。部分应用会读取它，部分应用使用自己的代理设置，还有一些程序直接建立连接。因此，浏览器能访问而另一个程序不能访问，不一定是 v2rayN 没有启动。先明确目标应用支持哪种接入方式，再决定使用系统代理、应用内代理还是 TUN。

确认系统设置确实写入

在 v2rayN 选择自动配置系统代理后，打开操作系统的网络代理设置，查看地址与端口是否指向当前监听入口。若仍是旧端口或其他程序的地址，检查是否有另一个客户端、管理工具或自动脚本在覆盖设置。关闭其他接管工具后重新写入一次。受组织管理的设备可能存在策略限制，不应绕过管理要求，应先确认允许的网络配置方式。

应用内配置手动代理时，先核对协议、主机与端口，再排除认证框被误填的问题。普通本机监听入口不一定启用认证，不能把节点的用户标识或密码填到浏览器代理认证框。监听地址也不宜为了排错随意改成所有网卡；若只供本机使用，保持本机范围更容易控制访问边界。需要局域网共享时，应另行规划访问权限。

识别自动配置、独立代理与环境变量

系统可能同时存在手动代理、自动配置脚本和应用内代理，具体优先级由应用决定。浏览器扩展也能单独改变浏览器的出站方式。先停用相关扩展并检查浏览器代理设置，再重建会话。命令行工具和后台服务可能读取环境变量或独立配置，不要因为浏览器成功就推断它们一定走同一路径；本手册优先通过图形界面确认实际入口。

将 TUN 故障拆成启动与转发两部分

TUN 通过虚拟网卡处理被路由到它的流量，但具体覆盖范围仍由系统路由和客户端设置决定。启动失败时先看权限、虚拟网卡创建和驱动相关日志；启动成功却无法上网时，再看路由、DNS、出口选择和服务器地址是否被正确排除。不要看到开关亮起就认定流量已经完整接管，也不要默认所有客户端都提供完全相同的选项。

桌面端需要提升权限的操作，应使用系统认可的授权流程。若授权后仍失败，检查是否残留旧虚拟网卡、其他网络工具是否占用路由，以及安全软件是否给出明确拦截记录。不要直接关闭整套防护。先根据记录允许必要组件，再测试；找不到明确证据时保持原防护状态，以免排错引入新的风险。

出现访问循环或启用后立即断网时，恢复到关闭 TUN 的状态，确认系统代理基线仍正常。随后逐项开启接管与 DNS 设置，观察哪一步触发问题。路由规则决定接管后的流量如何出站，TUN 并不天然等于所有目标使用同一个节点。开启流程与适用场景可看TUN 配置教程及虚拟网卡原理说明。

退出客户端后如果网络中断，先检查系统是否仍指向已经关闭的本地代理，再查看虚拟网卡与路由是否按正常流程释放。优先重新打开客户端并使用停止接管、清除系统代理等正常操作恢复，而不是直接结束所有进程。验证完成后，记住当前可用的接管方案；日常只保留必要的一层，减少重复代理和设置互相覆盖。

客户端崩溃：分开检查界面、内核与配置

窗口突然关闭、点击启动没有反应和界面正常但内核退出，是三种不同问题。先观察托盘是否还在、日志是否继续更新，以及任务管理工具中是否仍有相关进程。记录触发动作，例如启动即退出、导入某个节点后退出，或只有启用 TUN 才退出。能稳定复现的触发条件，通常比一次孤立的崩溃提示更容易定位。

先保护配置，再处理运行环境

在删除目录、重置设置或重新安装之前，先用客户端支持的导出方式保存必要配置。订阅地址和节点认证信息具有敏感性，备份应留在自己控制的位置。若界面无法打开，可先复制现有数据目录用于恢复，但不要把整份目录直接公开。随后确认配置位置是否属于当前安装，避免把另一套便携目录误当成当前实例的数据。

从客户端下载页核对平台与处理器架构。桌面系统能运行某类应用，不代表另一个架构的包一定适合当前环境；尤其在不同处理器设备之间迁移时，应重新选择对应包。Windows 的桌面版与经典 WPF 版采用不同界面技术，排错时按所选包的要求检查运行环境，不要把一种界面的依赖说明直接套给另一种。

界面打不开与内核起不来分别处理

界面启动即退出时，检查系统事件记录、应用日志和磁盘剩余空间。安装目录不可写、用户数据目录权限异常、同步软件锁定文件，都可能影响启动。先把程序放在正常可访问的位置，并确认当前用户具备必要权限；不要长期通过最高权限运行来掩盖普通文件访问问题。需要提升权限的 TUN 操作，应与日常界面启动分开判断。

界面存在而内核立即停止时，重点看配置生成和监听端口错误。日志提示地址已被占用，可能是另一实例仍在运行，也可能是其他程序占用了同一端口。先关闭重复实例，确认端口用途，再修改本地监听设置；修改后同步更新系统和应用代理。若只改客户端端口，浏览器仍指向旧值，就会产生新的“启动成功但无法访问”。

提示配置解析错误、不支持字段或规则文件读取失败时，找出最近一次改动。手工编辑的 JSON 要检查引号、逗号和字段类型，但不要直接修改客户端每次启动都会重新生成的文件。优先通过设置界面撤销该项，或恢复之前保存的配置。导入参数与当前内核不兼容时，应核对协议能力，而不是随机删除错误行。

更新之后异常，保留前后对照

若问题紧接更新出现，记录更新前后所用的包类型、系统环境和触发动作，不要编造或凭记忆填写版本信息。检查旧进程是否退出，以及新程序是否仍读取了原数据位置。不同实例共用同一数据目录可能导致状态混乱。重新安装前先确认运行的是哪个可执行文件，桌面快捷方式也可能仍指向旧目录。

安全软件隔离或阻止组件时，应先查看明确的事件记录和文件来源，再决定恢复或设置例外，不要一次性关闭全部保护。磁盘空间不足、异常断电或数据写入中断，也可能留下不完整配置。能够打开界面时，可先导出仍可读取的部分，再建立新的工作数据；恢复时逐个导入分组和规则，方便识别触发异常的具体内容。

求助材料应包括系统类型、架构、客户端界面类型、复现步骤和脱敏后的错误上下文。隐藏订阅凭据、服务器认证字段及不必要的个人路径。确认恢复后，先验证普通连接，再加回复杂路由和 TUN；观察一段实际使用过程，确保不是只恢复了窗口。关于内核与图形客户端的关系，可参阅Project V 生态说明，避免把界面故障与内核故障混为一谈。

移动端异常：VPN 授权、后台运行与分应用规则

安卓排查以 v2rayNG 为主要操作对象，v2flyNG 作为使用 V2Fly 内核的备选。两者的配置能力与界面细节可能不同，不能假定同一项高级参数在两边都适用。先确认当前实际运行的是哪个客户端，再按照“基础网络、VPN 授权、节点连接、应用规则”的顺序检查。桌面上的系统代理经验不能直接代替安卓的 VPN 接管判断。

启动后没有网络，先查授权与冲突

首次启动连接时，需要通过系统的 VPN 连接授权。若没有完成授权，节点已导入也不会自动接管应用流量。查看系统 VPN 设置和客户端通知，确认当前连接属于预期客户端。安卓通常同一用户空间只能有一个活动 VPN 服务，其他依赖 VPN 机制的网络工具可能争用它；先停止冲突服务，再单独启动需要测试的客户端。

如果系统配置了始终开启 VPN 或阻止未使用 VPN 的连接，客户端断开时可能连基础网络也无法使用。这是系统策略的表现，不一定是网络已经损坏。排错前先了解这些选项的作用，必要时在允许的设备管理范围内调整测试条件，完成后恢复。受工作资料或设备策略管理的环境，应遵循管理员提供的网络方案。

熄屏断连与后台限制分开验证

前台正常、锁屏后断连，优先检查电池优化、后台活动限制与数据节省模式。不同设备厂商的设置入口不同，可在应用信息中查找电池、后台数据和自启动等选项。只为正在使用的客户端调整必要权限，不必改变所有应用的电源策略。通知权限和后台服务限制也应检查，但看到通知存在并不能单独证明节点连接一直有效。

测试时固定一个节点，先在前台完成访问，再锁屏等待，解锁后立即检查日志中的重连和网络变化记录。若只有从无线网络切到移动网络时断开，可能是原有连接失效后没有及时恢复；先停止并重新建立连接，确认新网络是否可用。不要在连接尚未重建时反复切换协议参数，否则会把网络切换问题与配置问题叠在一起。

部分应用失败，检查分应用与 DNS

分应用代理通常有仅代理所选应用或绕过所选应用等模式，方向选反会造成“勾选了反而不走代理”。先确认模式，再检查目标应用及其依赖服务是否在正确列表中。修改后重新建立 VPN，并完全退出目标应用再打开。浏览器和某个应用表现不同，也可能是它们使用不同 DNS 或连接协议，不能只靠一次网页测试判断接管范围。

系统私人 DNS、客户端 DNS 与应用内加密 DNS 可能同时存在。若日志出现名称解析失败，先回到DNS 排查流程确认谁在解析；不要把所有解析入口同时改成不同服务。移动网络与无线网络下结果不同，还要检查新网络是否需要认证、是否限制某种连接，以及客户端是否恢复了原有出站。需要时用另一有效节点做单变量对照。

安装、迁移与最终验证

安装包架构不匹配可能导致无法安装或无法运行，选择时以设备处理器与系统能力为准。主流设备通常选择 arm64；无法确定时可查看设备信息，并参考下载页的通用包说明。已有应用无法被覆盖安装时，应阅读系统给出的原因，检查是否存在不同签名或其他用户空间中的安装记录。不要为了覆盖安装直接清除数据，先备份再处理。

迁移配置时，优先重新添加自己的订阅并更新，而不是盲目复制所有系统相关选项。分应用列表、后台权限和 VPN 授权属于设备环境的一部分，新设备仍需重新确认。若单个手工节点无法连接，核对其完整分享参数与内核支持情况；若所有节点在两种网络都失败，再查账户和服务状态，避免只在手机设置里反复寻找答案。

最后按实际使用验证：前台访问、锁屏恢复、网络切换、目标应用连接和正常断开后的基础网络都应符合预期。保存有效设置，撤销临时调试与无关权限调整。需要重新选择安装包时前往Android 客户端下载；只想了解常见操作差异，可查常见问题。完成一轮验证后再恢复日常复杂规则，让下一次异常仍然有清晰的对照基线。