V2Ray 故障排查手册

无法上网：先分清故障层

“客户端已连接”通常只说明代理服务已启动，并不代表每个目标网站都能访问。一次请求要经过应用代理入口、本地监听、路由判断、域名解析、服务器连接和目标站点。任意一层失败，都可能表现为浏览器转圈。排查时先确定故障范围：所有应用都失败、只有浏览器失败，还是只有某个网站失败。范围不同，优先检查的设置也不同，不宜直接重装或反复更换节点。

建立停用与启用两组对照

在 v2rayN 中先清除系统代理，再停止代理服务；如果启用了虚拟网卡模式，也应单独关闭。安卓端停止 VPN 连接。随后访问平时能够直接打开的站点，确认当前网络是否需要登录认证。校园、酒店或公共无线网络可能要求先完成认证，此时启动代理不能代替网络登录。若停用后仍无法访问，先处理无线连接、网关或网络账户，再回到客户端。

基础网络恢复后，启动客户端并选择一个配置完整的服务器。观察日志有没有配置加载失败、监听失败或进程退出信息。v2rayN 的图形窗口存在，不等于内核进程一直在运行；安卓通知栏出现服务通知，也不能替代实际访问验证。如果日志在点击启动后立即报错，先检查本地服务，不必继续更换网站测试。只有服务稳定运行后，访问结果才具备比较意义。

确认应用是否进入代理入口

桌面端启用系统代理后，用遵循系统代理设置的浏览器访问一个固定页面，同时观察访问日志。若完全没有新请求，问题更可能在浏览器设置、代理扩展或应用自身的连接方式。若日志已有请求，却显示连接失败，则说明入口大致有效，应继续检查出站。安卓端还要确认分应用设置：被排除的应用不会进入 VPN，即使其他应用能够使用代理，该应用仍可能保持直连。

为了隔离路由影响，可以短暂切换到将待测流量送往代理出站的规则模式，再访问同一个页面。注意部分客户端的“全局”只是路由选择，不是系统接管开关；流量没有进入客户端时，切换路由不会产生效果。若测试模式可以访问而原模式失败，应回查域名规则、规则顺序与默认出口。完成测试后恢复日常规则，避免把临时诊断配置长期保留。

保留一个最小可工作的配置

如果曾经成功连接，优先回退最近一次修改，而不是同时重置全部设置。新加的路由、DNS、虚拟网卡和浏览器扩展应分别停用并测试。记录哪一步让访问恢复，再单独重建对应配置。对于刚导入的新订阅，也不要把旧分组立刻删除；旧配置可以作为对照，帮助判断是客户端公共设置变化，还是新服务器参数变化。

恢复标准应包括页面主体加载、重新打开浏览器后仍可访问，以及停止客户端后网络能够回到预期状态。仅凭一次连通测试成功不足以确认全部恢复。需要重新建立操作基线时，返回订阅导入与首次连接教程；概念层面的差异可查阅常见问题，避免把系统代理、路由模式和内核启动混为同一个开关。

节点超时：区分连接与握手

超时表示某个阶段没有在等待时间内得到结果，并不能单独证明服务器已经离线。客户端的测试功能可能测量 TCP 建连，也可能通过代理请求一个测试地址；两种结果含义不同。端口可以建立连接，后续认证或传输仍可能失败；测试地址暂时不可用，也可能让正常配置被标为超时。因此应结合真实访问与日志阶段判断，不要只根据列表中的一个测试结果删除配置。

先核对服务器条目与设备时间

打开当前服务器的编辑界面，核对地址、端口、协议、传输方式和安全设置是否来自同一份配置。复制粘贴时容易混入空格，也可能把订阅地址误填到服务器地址栏。地址栏通常不应包含网页路径或协议前缀，除非该字段明确要求完整 URL。端口、用户标识和密码应使用配置提供方给出的值，不要根据其他条目猜测。更新订阅后，确认当前选中的仍是有效条目。

随后检查操作系统的日期、时间与时区。时间明显偏离可能影响证书验证及部分协议认证。开启系统自动校时后，重新启动一次代理服务，再复现相同请求。若日志提示证书尚未生效或已经过期，应先区分本机时间异常和服务端证书问题。不要通过跳过证书验证掩盖错误；这一设置会改变安全边界，也不能修复错误的服务器名称或连接地址。

按照日志中的失败阶段处理

出现连接拒绝，通常说明目标主动拒绝连接或目标端口没有相应服务；出现网络不可达，应检查本机网络、地址族和路由。持续等待后超时，可能涉及路径丢包、服务器无响应或本地安全软件拦截。若已经进入 TLS 握手阶段，应重点核对服务器名称、安全类型与传输参数。报错文字在不同内核中有所差异，判断时保留完整上下文，不要只截取最后一个英文单词。

VLESS 与 REALITY 配置还需要核对公钥、短标识、服务器名称，以及条目要求的其他字段。WebSocket 则需要检查路径和 Host；gRPC 需要检查服务名称。这些值并非可以互换的装饰项，同一个地址与端口也不能说明配置相同。部分订阅转换可能丢失字段，遇到这种情况应重新获取完整配置，而不是逐个尝试网上找到的参数组合。

用网络与配置做交叉测试

保持同一个服务器、同一个目标页面和同一套客户端设置，分别在两种可用网络上测试。若只有一个网络失败，关注该网络的解析、地址族、认证与访问路径；若所有网络都失败，而其他条目正常，则当前服务器或参数更值得检查。反过来，如果所有条目在同一设备都失败，但另一台设备正常，应优先检查本机代理入口、时间、内核状态和安全软件，而不是认定全部服务器同时故障。

协议支持也取决于当前内核和客户端对配置的生成方式。导入成功只表示客户端识别了链接，不保证所选内核能执行全部字段。切换内核前先确认该条目需要的协议与传输支持，保留原设置，以同一个请求验证。关于内核家族与配置兼容，可参阅Xray 内核与 V2Fly 内核区别。切换失败后应回退，不要在未知状态下继续叠加修改。

当问题需要交给配置提供方处理时，说明失败发生在建连还是握手、是否只在某个网络出现，以及其他条目能否使用。提供经过脱敏的报错文本即可，不公开完整订阅或账户参数。恢复后再测试一次真实页面和一次重新连接，确认不是偶然成功；列表测试结果只作为辅助观察，不作为唯一结论。

订阅失败：拆开获取与解析

订阅更新至少包含获取内容、解析内容和写入分组三个步骤。无法下载通常与地址或网络有关；获取成功但没有条目，可能是返回内容不符合客户端格式；更新后条目存在却不能连接，则需要转到服务器配置排查。把这三类情况分开，可以避免反复删除分组造成信息丢失。开始操作前，先记录分组名称、更新方式和错误时间，保留仍然可用的旧配置。

检查地址是否仍然是订阅入口

重新复制订阅地址时，确认没有遗漏末尾参数，也没有附带聊天软件插入的空格、换行或标点。订阅入口与账户登录页面不同，后者即使能在浏览器打开，也不能直接作为订阅内容导入。部分入口需要有效账户状态或授权参数，账户失效、地址被重置、流量额度变化都可能影响返回结果。具体状态应在原有管理入口核实，不要把地址提交到不明的在线转换页面。

错误码能够缩小范围，但不宜过度解读。未授权或禁止访问通常与权限、入口限制有关；找不到资源可能是地址变化；服务端错误可能需要稍后重试。返回成功状态也未必代表拿到的是配置，有时实际内容是登录页、认证提示或维护页面。如果客户端日志提示解析 HTML 失败，优先确认请求被引向何处，不必立即更换内核，因为内核尚未参与这一步。

确认订阅更新走哪条网络路径

订阅下载可能采用直接连接，也可能通过现有代理进行，具体取决于客户端提供的更新方式。当前网络能够直接访问订阅入口时，先尝试直接更新；入口需要经代理访问时，必须先有一个能够工作的配置。所有配置均失效，又要求通过这些配置更新订阅，会形成循环。此时可以换用能够访问入口的网络，或通过原有管理渠道取得有效配置，不要连续点击更新按钮等待状态自行改变。

如果使用代理更新，确认选中的服务器能完成普通网页访问，而且本地监听端口没有改变。某些环境还会给订阅请求返回网络认证页，所以“浏览器能访问其他网站”不能完全排除问题。固定同一个入口，分别测试直接更新与通过代理更新，只保留成功路径。两者都失败时再检查账户状态和服务端响应，避免把网络路径问题误判为订阅格式损坏。

解析成功之后检查分组与筛选

更新完成但列表看起来为空时，先清除搜索框和类型筛选，再切换到对应分组。有些客户端会记住上次选择的分组，新条目可能已经写入另一个分组而没有显示。若更新后条目数量变化，比较别名、地址和协议，不要单凭排序判断内容消失。订阅提供方调整内容时，旧条目可能被替换，客户端也可能重新排列列表；当前选中的服务器需要再次确认。

格式兼容问题应从原始来源解决。某种链接能被复制出来，不代表其中所有协议和传输字段都被当前客户端识别。导入时有明确的不支持提示，应查看对应客户端的支持范围，或请求适配的订阅格式。不要为了消除报错而任意删除安全字段；条目能够出现在列表中，也可能因缺少参数而无法连接。安卓端的具体导入流程可回看订阅导入教程。

恢复后检查分组的自动更新设置，避免多个重复分组在不同时间覆盖内容。先手动完成一次更新，再选择一个条目连接并访问固定页面，最后确认旧分组是否仍有保留价值。不要用高频刷新代替排查；频繁请求可能触发入口限制，并让错误时间线更难辨认。如果订阅已经正常获取，但连接仍然超时，继续阅读节点超时章节，此时无需继续调整订阅更新方式。

速度慢：按阶段测量瓶颈

访问缓慢可能发生在域名解析、首次连接、页面资源加载或持续传输阶段。打开网站前长时间空白，与下载开始后速率偏低，不是同一种故障。列表里的延迟测试主要反映特定请求的响应时间，不能直接代表带宽、稳定性或所有站点表现。排查应固定一个实际任务，例如打开同一页面或下载同一公开文件，再观察是哪一个阶段明显变慢。

先排除本地网络和后台竞争

保持设备位置不变，先暂停系统更新、云盘同步和其他大流量任务，观察无线网络信号及是否频繁重新连接。共享网络中的其他设备也可能占用出口。若直接访问本来就慢，代理无法修复无线干扰或本地出口拥塞。具备有线条件的桌面设备可以做一次有线对照；安卓设备则可在无线网络与移动网络间比较，但测试时应留意流量消耗，不必持续运行大文件下载。

每轮测试只更换一个条件。固定服务器比较不同时间，可以观察负载变化；固定时间比较两个服务器，可以观察路径差异；固定服务器比较两个网站，可以判断是否为目标站点问题。不要一次切换服务器、内核、路由和 DNS，再把速度变化归因于某一个开关。多次结果应记录相同任务的表现与网络条件，避免被浏览器缓存、后台更新和偶发重试误导。

从日志与资源占用判断成本

如果页面开始加载很快，但图片或视频持续卡顿，重点关注丢包、服务器负载及目标站点的资源分发路径。如果首次打开缓慢，后续刷新明显正常，应检查解析、握手和连接复用。若只有某个网站缓慢，而同一服务器访问其他站点正常，问题可能出在该网站到服务器出口之间。此时切换本机协议参数未必有效，先做站点和服务器的交叉对照更容易得出结论。

桌面端可以通过系统任务管理界面查看 CPU、内存和网络占用。设备资源紧张、多个代理进程并存、虚拟网卡重复接管，都可能增加处理成本。调试日志也会带来额外写入，定位完成后应恢复常规日志级别。安卓端还要关注发热和省电策略：持续高负载可能触发系统调度变化，熄屏后出现的问题则更适合放到移动端后台章节处理。

避免用复杂设置替代测量

多路复用、并发和传输设置不是通用加速按钮。它们是否有效，取决于协议、服务端支持、链路质量和请求形态；配置不匹配还会导致连接失败。先保持订阅给出的原始参数，只在能够解释测试目标时调整一项，并保留回退记录。尤其不要照抄与当前内核不一致的配置片段，字段被忽略和字段导致启动失败都可能发生。

路由也会影响性能。相同网站的页面与资源可能使用不同域名，如果规则把它们分配到不同出口，页面表现会不稳定。可以临时让待测域名使用一致出口验证，再细化规则，而不是长期把所有流量都改成同一种处理方式。关于系统代理与路由的分工，参阅系统代理模式详解，先明确流量进入位置，再比较路径成本。

恢复判断应基于原来的任务，而非追求一个孤立的测试数字。如果常用页面已能稳定打开、连续传输不再中断，就不必继续叠加参数。若只有特定时间或特定服务器持续缓慢，记录可复现的条件，转交配置提供方检查出口和负载。客户端本地设置不能保证改变远端链路的容量，合理的排查结果也可能是确认瓶颈不在设备上。

DNS 问题：定位解析发生处

DNS 把域名转换为地址，但代理场景下解析不一定只发生在操作系统。浏览器可能启用安全 DNS，客户端可能有内置解析设置，远端也可能接收域名并自行解析。更改系统 DNS 后没有变化，并不代表修改没有保存，也可能是该请求根本没有使用系统解析。排查前先确认故障域名、发生时间和访问应用，再判断解析由哪一层负责。

识别解析失败与连接失败

浏览器显示找不到服务器、日志出现解析错误时，DNS 是优先检查方向；若日志已经得到地址，却在连接该地址时超时，应继续检查连接路径。不要把所有域名访问失败都归为 DNS。直接把网站域名替换成 IP 也不是可靠验证方法，因为许多网站依赖 HTTPS 服务器名称和虚拟主机，使用地址访问可能得到证书错误或其他站点，这些现象不能证明原域名解析有问题。

先用同一个域名对照两个应用，确认是否只有浏览器失败。浏览器的安全 DNS、代理扩展及独立网络设置可能绕过系统路径；可以暂时恢复到遵循系统的设置后复测。随后比较直接访问与经代理访问的结果。若只有代理路径失败，需要检查客户端的 DNS 服务器可达性及其出站选择；若两条路径都失败，还应确认域名本身是否有效以及当前网络是否完成认证。

检查循环依赖与地址族

一种常见循环是：连接代理服务器需要先解析它的域名，而 DNS 请求又被要求经过尚未建立的代理。另一种情况是加密 DNS 服务器使用域名地址，但解析该地址的引导路径没有准备好。出现启动后连续解析失败时，应检查是否存在这样的先后依赖。恢复方式是为初始解析提供可达路径，而不是无限增加解析服务器；具体字段与引导机制应按当前内核支持来设置。

IPv4 与 IPv6 也需要分开观察。网络能够返回 IPv6 地址，并不代表设备到目标的 IPv6 路径稳定。若仅某个网络出现等待后回退的现象，可以在客户端支持的范围内临时调整地址族偏好，再对同一域名复测。只有结果明确指向地址族时才保留修改，不建议因为一次失败就在整个系统永久关闭某个地址族，否则可能影响其他应用与本地网络服务。

把解析策略与路由策略对应起来

基于域名的规则与基于 IP 的规则，命中条件不同。下面是路由对象片段，用于说明先按域名和私有地址匹配直连的结构；它不是完整客户端配置，不能替换现有配置。示例要求当前配置存在名为 direct 的出站，并且内核能够读取对应规则数据。客户端自动生成配置时，应优先在图形界面编辑等价规则，避免生成文件在下次启动时被覆盖。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

AsIs 表示路由阶段按现有目标信息匹配，不会为了所有 IP 规则主动把域名解析成地址；它不表示连接过程中永远不需要 DNS。若规则使用 IP 条件，而入站提供的是域名，是否触发解析取决于路由策略。调整之前先明确目标：是修复域名解析，还是让某条 IP 规则命中。两种需求不能简单用同一个“远程 DNS”开关概括。

修改完成后，重启代理服务并重新打开测试应用，必要时通过系统提供的方式刷新解析缓存。浏览器、系统与客户端可能各自缓存结果，单次刷新不一定清除全部旧连接。用同一域名重复测试，并观察错误是否从解析阶段转移到连接阶段。若解析已经恢复而目标仍不可达，应进入下一层排查，不要继续更换 DNS。术语含义可查名词解释，先分清解析服务器、查询路径与路由出口。

系统代理不生效：检查接管边界

系统代理是把代理地址写入操作系统供应用读取，并不保证所有程序都会使用它。路由规则则只处理已经进入客户端的流量。虚拟网卡模式又是另一种接管路径，需要单独的权限、路由与 DNS 配置。排查时先选定一种入口，不要同时启用多种机制，再根据应用是否遵循该入口决定下一步。客户端显示某种路由模式，不代表系统代理已经正确设置。

从监听地址和端口开始核对

先在 v2rayN 中查看实际启用的本地入站类型、监听地址和端口，再到操作系统代理设置中核对。HTTP 代理、SOCKS 代理以及混合入站不能仅凭端口外观互相替代，应用要求哪一种协议，就要使用相应入口。监听地址使用本机回环地址时，仅供当前设备访问；不要为了修复本机浏览器问题就直接改为监听所有网卡，这会扩大可连接范围。

如果日志提示端口被占用，关闭旧的客户端实例或其他代理程序后再启动。也可以在图形界面更换本地端口，但更换后必须同步更新所有手动配置的应用。系统代理可能由客户端自动更新，浏览器扩展、下载工具或开发软件里的独立代理设置却不会自动跟随。只改客户端端口而没有改应用，是“部分程序能用、部分程序失效”的常见原因。

识别系统、浏览器与应用的覆盖关系

浏览器可能选择遵循系统，也可能使用扩展指定的代理或自动配置脚本。先暂时停用代理类扩展，确认浏览器的网络设置没有独立覆盖，再测试。某些程序不读取系统代理，必须在程序自身设置 HTTP 或 SOCKS 入口；另一些程序则通过独立网络服务连接。不能因为浏览器能够访问，就推断所有应用都会经代理，也不能因为某个应用直连，就断定系统设置完全失效。

Windows 中不同网络组件可能读取不同的代理配置；macOS 的代理设置与当前网络服务相关，切换有线和无线网络后应重新核对；Linux 桌面环境的代理设置也不等于所有程序都会自动采用。若问题只在开机登录后发生，检查客户端是否已经启动内核、系统代理是否指向仍在监听的端口。自启动流程可结合Linux 安装与桌面登录自启动说明核对。

将代理入口与路由结果分别验证

用固定网站发起请求，观察访问日志是否出现对应目标。没有记录时，优先排查入口；已有记录且被分配到直连时，检查路由；已有记录且代理出站报错时，检查服务器。日志未启用或应用复用了旧连接，也可能暂时看不到新增记录，因此复测前可以关闭测试页面并重新打开应用。判断依据应组合使用，不能仅凭某一行日志缺失就断言流量没有进入。

如果同时使用虚拟网卡接管，先关闭它，仅保留系统代理做对照；反过来测试虚拟网卡时，也应明确是否需要保留系统代理。双重接管可能导致重复转发、例外规则不一致或 DNS 路径变化。虚拟网卡启动失败还涉及系统权限和驱动状态，不能通过反复切换路由模式修复。权限应按客户端实际需求授予，不要长期让所有关联程序都以高权限运行。

修复后分别验证启用、停用和重新登录三种状态。启用时测试应用能够进入代理，停用后应用能够恢复预期的直接访问，重新登录后端口与启动状态一致。需要让局域网设备使用本机代理时，应另行设计监听范围、访问权限和防火墙规则，不把这一需求混入本机故障排查。系统代理与全局、绕过大陆规则的区别，可继续查阅系统代理模式详解。

启动失败与崩溃：保留错误现场

图形窗口打不开、窗口正常但内核退出、使用一段时间后整个程序关闭，是三类不同问题。启动失败通常关注安装包、运行环境和权限；内核退出优先检查配置与端口；运行后崩溃还需要观察资源占用和触发操作。先记录最后一次正常使用与首次出错之间发生了什么，包括更新、移动目录、修改设置和系统安全提示，不要直接删除全部数据让线索消失。

核对平台、架构与安装位置

桌面端首选 v2rayN，并在客户端下载页按操作系统与处理器架构选择安装包。macOS 要区分 Apple Silicon 与 Intel，Linux 要区分发行版包格式和处理器架构。Windows 的桌面版与经典 WPF 版是不同界面分支，相关运行环境以各自说明为准。包格式相同也不代表架构相同，安装器能否启动与代理配置内容没有直接关系，应先把程序运行起来。

按照安装包类型完成安装或完整解压，不要从压缩包预览界面直接启动，也不要只复制一个程序文件而遗漏关联资源。将数据放在能够正常写入的位置，检查磁盘空间和目录权限。若程序被安全软件处理，先查看系统记录，确认涉及哪个文件以及触发原因，再按组织或设备的安全策略处理。不要为了启动代理客户端而关闭整套系统防护，也不要从不明来源补齐缺失文件。

区分界面异常与内核配置异常

如果界面能够打开，点击连接后立即停止，先查看内核日志。常见原因包括 JSON 语法错误、字段不受支持、出站标签不存在、规则资源无法读取以及监听端口冲突。错误通常会指出配置位置或相关字段，优先回退最近新增的设置。订阅更新后才出现问题时，可用先前可用的条目对照，确认是某个条目生成失败，还是所有配置都会失败。

下面是日志对象片段，用于说明 Xray 与 V2Fly 配置中常见的日志级别写法，不是完整启动配置。客户端提供图形化日志级别选项时，应通过界面调整。需要更详细的信息时可临时启用调试级别，复现一次后保存相关片段，再恢复常规级别。长期开启详细日志会增加磁盘写入，也可能记录较多访问目标，不适合作为默认排错遗留设置。

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

手工编辑配置还要检查引号、逗号和括号。标准 JSON 不接受注释和末尾多余逗号，某些文档中的说明性片段也不能直接拼接成完整配置。对客户端生成的文件做临时修改，可能在下一次启动时被重新生成覆盖，因此应优先找到对应的图形设置入口。遇到不认识的字段，不要直接删到程序能启动为止，否则可能改变认证、安全或路由行为。

用可回退方式隔离损坏设置

如果怀疑用户配置损坏，先完整退出客户端并确认后台进程结束，再备份配置目录。配置目录的位置因平台、安装方式和数据模式而异，应从客户端说明或界面入口确认，不要凭网上某个固定路径批量删除文件。在备份后使用独立的干净数据环境测试；若能够启动，再逐步恢复订阅、路由和界面偏好，确认是哪一类设置触发故障。

升级后异常不一定需要立即降级。先确认包是否完整部署、旧进程是否仍在运行，以及新界面是否支持原先的配置项目。需要回退时，先保留升级前后的数据备份，不让不同分支反复写入唯一一份配置。重装也未必清除用户数据，因此重复安装相同程序却不检查设置，可能只会重复出现相同错误。客户端选型与分支差异可参阅横向评测。

恢复后按原来的触发操作复测，例如更新订阅、切换服务器、打开路由设置或重新登录系统。报告问题时提供系统类型、架构、安装方式和脱敏日志，不公开用户数据目录。若错误由特定配置稳定触发，应描述该配置使用的协议与传输类型；若在空白配置下也崩溃，则更应关注运行环境和程序本身，避免把两个问题混在一起。

安卓专项：权限、后台与网络切换

安卓端首选 v2rayNG，采用 Xray 内核；v2flyNG 是采用 V2Fly 内核的备选。移动端排查除了服务器和订阅，还要检查 VPN 授权、分应用规则、后台策略及无线与移动网络切换。系统显示 VPN 标识，只表示存在相应连接，不证明代理服务器能够访问目标。先确认当前实际运行的是哪一个客户端，再按本章顺序建立对照，避免多个应用的状态相互干扰。

处理 VPN 授权与连接冲突

首次启动连接时，需要确认系统弹出的 VPN 授权。未完成授权、误点取消或被设备管理策略限制，都可能导致服务无法建立。安卓的普通应用 VPN 通道通常不能由多个同类应用同时接管，因此应先停止其他 VPN 类工具，包括使用本地 VPN 实现过滤的应用，再启动当前客户端。工作资料与受管理设备可能还有独立限制，不能通过更换节点绕过系统的管理要求。

如果启用了始终开启 VPN 或阻止未通过 VPN 的连接，需要理解其断开行为：代理服务停止后，系统可能按设置阻止其他网络访问。这时“停止后也无法上网”不一定是网络损坏。排查时先记录原来的策略，再临时调整并比较，完成后恢复符合使用需求的设置。不要只看客户端按钮状态，还应到系统 VPN 设置中确认当前连接归属和限制选项。

定位熄屏后断开与后台受限

屏幕亮着可以访问，熄屏一段时间后失效，首先检查系统电池优化和后台运行限制。不同设备对“允许后台活动”“自启动”“电池优化”的命名不同，按当前系统界面查找即可。应只给需要持续运行的客户端适当权限，而不是关闭所有应用的节能机制。设置后分别测试亮屏、熄屏和重新打开应用三种情况，并观察服务通知是否消失或被系统重新创建。

数据节省模式和后台移动数据限制也可能让服务保持运行却无法继续传输。确认当前客户端在所用网络下被允许联网，尤其关注从无线网络切换到移动网络后的状态。若每次切换后需要重新连接，先比较是否存在旧连接未重建或 DNS 路径变化，不要立刻删除订阅。开启飞行模式再恢复只能作为重新建立网络的对照操作，不是长期修复方案。

核对分应用与本地网络行为

分应用代理可能采用仅包含列表或排除列表，含义相反。修改名单后应重新建立 VPN，让新的选择生效，再用名单内外各一个应用测试。如果浏览器能访问而其他应用失败，先确认失败应用是否进入 VPN，以及应用内部是否还有独立代理或网络设置。单个应用的缓存、账户连接和目标服务异常，也不能靠切换全部流量的路由来准确判断。

局域网设备访问异常时，检查本地地址是否被送入代理，以及客户端是否提供绕过局域网的设置。打印机、家庭存储和路由器管理页面依赖当前局域网路径，远端代理通常不能代替这条路径。私有地址规则、系统 VPN 路由与应用自身发现机制可能同时参与，因此应先停止 VPN 做一次对照，再逐项恢复。不要把放宽局域网监听权限当成修复手机访问局域网的通用方法。

安装与恢复后的验证顺序

安装包应从Android 下载入口按设备架构选择。安装失败时，先检查存储空间、系统安装提示、处理器兼容性及现有安装来源；不要立即卸载，因为卸载可能删除订阅和自定义规则。需要重新安装前，先通过客户端支持的方式保存必要设置，并妥善保管其中的账户信息。通用包与架构专用包的选择，应以设备实际能力为准。

恢复后依次验证普通网页访问、分应用行为、熄屏保活和网络切换，每一步都使用同一个有效服务器。若仅在移动网络失败，返回 DNS 与超时章节做路径对照；若仅在后台失败，继续检查系统限制。客户端之间的选型差异可参阅三款客户端差异对照。确认日常场景稳定后，再恢复自动更新和其他自定义设置，保留一份可工作的配置作为下次排查基线。