V2Ray 故障排查手册

先建立不受缓存干扰的测试条件

保留一个普通网页和一个纯 IP 连通性测试作为对照，不要只用已经打开很久的页面判断结果。浏览器可能复用旧连接，也可能保留失败后的 DNS 结果。关闭浏览器全部窗口后重新打开，或者使用新的隐私窗口测试。暂时停止其他代理工具、网络加速工具和带有流量过滤功能的软件，确保同一时间只有一个程序修改系统代理。若电脑同时连接有线网络、无线网络和虚拟网卡，先只保留当前实际使用的网络接口，避免默认路由在多个出口之间变化。

接着观察客户端主界面：当前节点应处于选中状态，内核状态应为运行中，日志中不应连续出现配置解析失败或端口绑定失败。v2rayN 中“设置系统代理”和“启动内核”是两个不同动作；内核运行而系统代理未启用时，普通浏览器不会自动把请求送入代理。使用 TUN 模式时则应确认虚拟网卡已经创建，并且系统没有弹出等待确认的权限请求。TUN 的原理和完整开启步骤可参阅TUN 模式接管流量说明。

检查本地监听端口与应用代理

v2rayN 常见的本地入口是 SOCKS 与 HTTP 监听端口，实际数值以客户端设置页为准。不要把教程中的示例端口直接当成当前配置。Windows 可在终端检查端口是否由客户端进程监听；如果没有结果，说明内核未成功建立入口。如果出现其他进程占用同一端口，应先识别进程，再决定关闭冲突程序或修改本地端口，详细流程见本地端口占用处理。

netstat -ano | findstr LISTENING
tasklist /FI "PID eq 进程编号"

手动配置浏览器或其他应用时，代理类型必须与监听入口一致。SOCKS5 入口不能作为 HTTP 代理填写，HTTP 入口也不能填入只接受 SOCKS 的设置栏。地址通常使用 127.0.0.1，不要填写节点服务器地址。若应用提供“代理 DNS”或“通过 SOCKS 解析域名”选项，可先启用它进行对照测试；这样域名解析会与应用请求走同一入口，便于排除本地 DNS 的影响。

用直连与代理结果划分故障边界

关闭系统代理后测试普通网络。如果直连也无法访问任何网页，应先修复本机网络、网关或当前网络认证，V2Ray 配置不是第一排查对象。如果直连正常、启用代理后全部失败，而本地端口确实监听，重点查看客户端日志中请求发往哪个出站。出现连接被拒绝通常表示远端地址可达但对应端口未提供服务；连接超时更接近网络路径、地址错误或远端节点不可达；握手失败则要核对协议、传输层、安全层、主机名和路径。

如果只有部分网站打不开，先切换路由模式进行短时对照。全局模式正常而规则模式失败，问题通常位于规则命中结果，不是节点本身。检查域名规则是否被过早分配到直连或阻断出站，并留意规则从上到下匹配时的覆盖关系。如果网页能打开但图片、登录或验证码失败，要检查页面引用的其他域名是否命中了不同规则。排查完成后应恢复原有分流目标，不建议长期依赖全局模式掩盖规则错误。

最后检查系统时间。VLESS、VMess、TLS 等链路都可能受到明显时间偏差影响。开启操作系统自动校时，并确认时区正确。完成校时后重启内核，让新连接重新握手。若同一节点在另一设备可用，而当前设备仍失败，优先比较两端配置字段、系统代理状态与安全软件策略；若所有设备都在同一时间失败，则更可能是节点端或当前网络路径的问题。

区分测试类型与实际访问

TCP 测试只验证目标地址和端口能否建立基础连接，不能验证 VLESS、VMess 或其他协议参数是否正确。真实延迟测试会通过节点访问指定网址，覆盖本地入口、远端握手、出站请求和目标响应，因此更接近实际使用，但也更容易受到测试网址不可达、DNS 失败或路由规则影响。出现“TCP 可用、真实测试超时”时，重点检查协议认证、TLS、传输路径与测试网址；出现“TCP 直接超时”时，优先检查服务器地址、端口和当前网络到远端的可达性。

不要连续高频测试全部节点。批量测试会同时创建大量连接，可能触发本地网络设备的连接数限制，也会让日志被重复错误覆盖。选择一个配置明确的节点，间隔数秒进行测试，并在每次测试后读取对应时间段的日志。节点名称只用于识别，真正决定连接的是地址、端口、用户标识、传输方式、安全层和附加字段。

逐字段比较，不要依赖节点名称

手动添加配置时，应逐项核对协议类型、远端地址、端口、用户标识、加密或流控设置、传输类型、路径、Host、服务器名称以及指纹类选项。大小写、前导斜杠和空格都可能改变结果。例如 WebSocket 路径通常应与服务端完全一致；服务器名称用于 TLS 握手，不能因为节点地址是 IP 就随意留空；REALITY 配置中的服务器名称、短标识和公钥属于同一组参数，混用不同节点的字段会在握手阶段失败。

订阅导入后如果只有某一个节点失败，可以复制该节点并逐字段对照订阅原文，但不要在原节点上反复覆盖，以免失去比较基准。如果同一订阅的全部节点都超时，先尝试另一网络，例如从公司网络切换到家庭网络或移动网络。另一网络可用说明客户端配置大概率正确，故障位于当前网络策略、DNS 结果或出口路由。所有网络都失败，则应更新订阅并确认节点信息是否已经变化。

确认地址解析与双栈路径

节点地址为域名时，客户端必须先完成 DNS 解析。可以在系统终端查询该域名，观察是否返回地址以及地址族。如果只返回 IPv6，而当前网络没有稳定的 IPv6 出口，表现可能是长时间等待后超时；如果返回多个地址，某个地址不可达也可能造成首次连接缓慢。临时切换可靠的 DNS 进行对照，或者在客户端中调整域名解析策略，但不要长期固定订阅域名对应的 IP，因为服务端地址可能变化。

若测试显示延迟数值但实际访问失败，说明测试链路与应用链路不一致。检查测试是否绕过了自定义路由，应用是否走系统代理，以及浏览器是否启用了独立代理扩展。最后用一个节点完成真实网页访问，再决定是否保留。延迟排序只能用于初筛，稳定性、握手成功率和目标访问结果更能说明节点是否适合当前网络。

先检查订阅地址本身

复制订阅地址时要包含完整协议头、路径和查询参数。聊天软件或文档可能只把前半段识别为链接，导致参数被截断；地址两端也可能混入空格、换行或中文标点。建议使用客户端的订阅管理窗口重新粘贴，并把订阅名称设置为便于识别的短文本。不要把单个 vmess://、vless:// 分享链接放入订阅地址栏，它们属于单节点导入内容；订阅栏需要能够返回节点集合的地址。

订阅服务可能要求有效的访问参数。若链接曾被重新生成，旧地址即使能打开，也可能只返回错误说明或空内容。不要根据浏览器“出现了一段文字”就判断订阅有效，因为错误页面同样可能返回正常的 HTTP 状态。客户端日志通常会记录请求状态、响应类型或解析失败位置。重点关注未授权、禁止访问、资源不存在、重定向次数过多和响应内容为空等提示。

判断订阅请求走直连还是代理

首次安装且节点列表为空时，订阅更新通常只能使用当前直连网络。已经有可用节点时，部分客户端允许通过代理更新订阅。如果直连更新失败、代理更新成功，说明订阅服务在当前直连路径上不可达；反过来则可能是当前代理节点无法访问订阅地址。排查时不要让“更新订阅时使用代理”和“自动更新订阅”同时反复执行，否则日志中会混合多次请求。先关闭自动更新，手动选择一种路径测试。

系统代理与客户端内部的订阅请求不是同一概念。有些客户端更新订阅时直接由内核发起，有些由应用进程发起，因此系统代理开关不一定决定订阅请求路径。应以客户端设置项和日志为准。使用公司网络、校园网络或需要网页认证的网络时，先用普通浏览器完成网络认证；未认证状态下，请求可能被重定向到登录页面，客户端收到 HTML 后会报告格式错误。

处理“更新成功但列表没有变化”

先确认查看的是正确订阅分组。客户端可能按订阅名称建立分组，更新后的节点进入其他分组，而当前界面仍显示旧分组。检查筛选条件、搜索词和隐藏不可用节点等选项。其次观察节点数量、名称或更新时间是否有任何变化；服务端返回内容未变化时，客户端保持原列表属于正常结果。若日志显示解析到零个节点，则应检查订阅格式是否被客户端支持，以及返回内容是否实际上是错误说明。

v2rayN 用于 Windows、macOS 和 Linux 桌面环境，v2rayNG 与 v2flyNG 用于 Android。不同客户端对订阅扩展字段的支持范围可能不同。同一地址在一个客户端可导入、另一个客户端为空时，不要立即修改所有节点；先查看未识别字段是否属于客户端不支持的扩展格式，并更新到下载页提供的当前客户端版本。客户端更新后重新建立一个测试订阅分组，避免旧数据库中的残留字段影响结果。

若订阅更新后节点重复，通常是同一地址被添加了多次，或者“追加节点”与“覆盖更新”策略不同。保留一个订阅源，删除重复的订阅记录，再执行一次更新。不要仅按节点名称批量删除，因为不同服务器可能使用相同显示名。需要迁移设备时，优先在新设备重新添加订阅，不要同时导入旧数据库和同一订阅源，否则容易形成重复记录和过期配置并存。

最后检查系统日期、网络代理和证书信任。如果浏览器也无法打开订阅地址，先处理网络层；浏览器可访问而客户端失败，则收集客户端日志中的请求时间、状态和解析错误，再针对阶段处理。订阅地址属于访问凭据，不应粘贴到公开页面或截图中，排查截图应遮住完整路径与查询参数。

建立可重复的对照测试

先关闭代理，在同一网络、同一设备上测试普通网页加载和一个稳定文件的下载，记录大致表现即可，不需要追求单次峰值。然后启用代理，只选择一个节点，保持浏览器、测试目标和时间段一致。测速期间暂停系统更新、云盘同步、视频播放和其他设备的大流量任务。无线网络信号弱、路由器负载高或移动网络频繁切换基站时，任何节点都会出现波动，应先排除本地链路。

区分“网页第一次打开慢”和“持续下载慢”。第一次打开慢但后续正常，常见原因是 DNS、TLS 握手或连接建立耗时；下载开始很快随后下降，可能是网络拥塞、远端限速或丢包重传；小网页正常但大文件慢，说明基础连通性没有问题，应重点比较路径质量和持续吞吐。不要用一个目标网站下结论，目标服务自身的负载和区域调度也会改变结果。

比较节点与传输路径

选择地理距离和网络路径合理的节点进行对照。延迟较低通常有利于交互，但低延迟不保证高带宽；延迟略高但丢包少的节点，持续传输可能更稳定。每次只切换节点，其他设置保持不变。若同一订阅中所有节点都慢，而直连正常，应检查本机代理模式、DNS 和安全软件；若只有一个节点慢，则优先更换节点，不必修改整个客户端。

传输层参数必须与服务端匹配，不能为了“提速”随意切换。WebSocket、gRPC、TCP 等方式具有不同的连接特征，但实际效果取决于服务端配置与网络路径。错误的 Host、路径或服务器名称可能表现为重试和间歇性失败，而不是立即报错。日志中如果连续出现连接重建、EOF、超时或握手失败，应先修复稳定性，再讨论速度。

检查路由、并发和本机处理开销

规则模式下，一个页面的主文档、图片、脚本和接口可能命中不同出站。如果主页面走代理而静态资源直连失败，用户感受到的是页面长时间空白。打开客户端路由日志或临时切到全局模式进行对照：全局模式明显改善时，逐项检查页面相关域名的规则命中。规则应从明确、具体的条件开始，再进入较宽泛的兜底规则，避免上方的大范围直连规则提前截获请求。

TUN 模式会处理更多进程流量。开启后速度下降时，检查是否把系统更新、局域网访问和大文件同步也纳入代理。合理配置局域网与必要直连规则，可减少无关流量经过远端链路。与此同时，避免同时启用系统代理、浏览器代理扩展和另一套虚拟网卡接管；重复转发可能形成环路，表现为 CPU 占用升高、网页反复重试和速度骤降。

客户端日志级别长期设置过高也可能增加磁盘写入，尤其在大量短连接场景。诊断时可提高日志详细度，确认问题后应恢复普通级别并清理过大的历史日志。安全软件若对每个新连接执行深度检查，也会增加首开时间，可在不改变整体防护策略的前提下，确认客户端程序和本地监听连接是否被重复扫描。

DNS 解析缓慢时，页面会在建立连接前等待。可结合本页 DNS 章节检查解析耗时，并参阅DNS 请求与代理链路配置。若 TUN 环境使用 FakeDNS，还应理解假地址映射和域名还原的边界，相关原理见FakeDNS 工作流程。性能调整完成后，重新测试至少两个目标和两个时间段，避免把临时网络波动误认为固定配置问题。

判断问题是否只发生在域名

如果日志显示目标域名解析失败，而直接访问已知可达的 IP 有响应，故障集中在 DNS；如果域名能够解析出地址但连接仍超时，则还要检查远端路径。Windows 可使用 nslookup，macOS 与 Linux 可使用 dig 或 nslookup 查看系统解析结果。查询时分别记录返回的 IPv4 与 IPv6 地址，不要只看命令是否执行成功。

nslookup example.com

dig example.com A
dig example.com AAAA

系统查询正常不代表客户端内部 DNS 一定正常。v2rayN、v2rayNG 和 v2flyNG 可以由内核执行独立解析，并根据路由选择不同服务器。出现浏览器直连正常、代理后域名失败时，应查看客户端日志中的 DNS 服务器、查询类型和出站标记。如果请求被发送到一个只能经代理访问的 DNS，而当前代理尚未建立，就可能形成启动依赖；反过来，把需要代理访问的解析请求强制直连，也会持续超时。

梳理 DNS 与路由的执行顺序

路由规则可以按域名、IP、端口或进程匹配。域名规则需要内核保留目标域名信息；IP 规则则可能要求先解析。配置中启用按需解析时，只有在规则需要 IP 条件时才查询地址，可减少不必要的解析。若所有域名都在路由前强制解析，再按返回 IP 分流，目标服务使用动态地址时可能落入错误规则。排查阶段应先使用较简单的 DNS 设置，确认基本访问恢复，再逐步加入分流服务器、域名列表和地址策略。

下面是用于理解结构的内核 DNS 示例。实际地址与标签应按当前网络和配置调整，不能直接覆盖客户端自动生成的完整配置。关键点是 DNS 服务器可以指定出站，查询策略也应与网络支持的地址族一致。

{
  "dns": {
    "queryStrategy": "UseIP",
    "servers": [
      {
        "address": "1.1.1.1",
        "port": 53,
        "skipFallback": false
      },
      "localhost"
    ]
  }
}

处理缓存、IPv6 与 FakeDNS 边界

修改 DNS 后应清除系统缓存并重新建立浏览器连接。Windows 可在管理员终端执行 ipconfig /flushdns；采用内核独立 DNS 时，还应重启客户端内核，因为系统缓存清理不会清除内核内部状态。浏览器可能维护自己的主机缓存，完全退出后再打开比普通刷新更可靠。若网络只稳定支持 IPv4，而解析优先返回 IPv6，可临时调整查询策略验证；确认后再决定是修复本机 IPv6 路由，还是让客户端优先使用当前可达的地址族。

FakeDNS 常与 TUN 模式配合：应用获得一个保留地址，内核根据映射恢复原域名并执行路由。它能保留域名信息，但并非所有局域网应用和特殊协议都适合假地址。出现局域网设备发现失败、部分应用连接固定 IP 异常时，应把局域网域名、私有地址段和必要系统服务排除在 FakeDNS 之外。不要把 FakeDNS 地址当作远端真实地址写入规则或手动连接。

若表现为“能访问但解析路径与预期不一致”，应把应用发起的 DNS、客户端使用的 DNS 与节点连接所需的 DNS 分开观察。节点服务器域名解析必须在代理链路建立前完成，通常需要可直接访问的解析路径；目标网站解析则可以按路由经不同出站。把这两类查询混在同一组复杂规则里，容易造成循环依赖。完成修复后，应同时验证域名解析结果、客户端日志中的出站标记以及真实网页请求，具体检测思路可继续阅读DNS 泄漏检测与修复实操。

确认系统代理值与本地监听一致

系统代理中的地址应指向本机入口，通常是 127.0.0.1 加客户端当前 HTTP 端口。若客户端修改了本地端口，但操作系统仍保留旧端口，表现会是开启代理后立即断网。v2rayN 退出异常时也可能留下旧设置，因此重新打开客户端后应先清除系统代理，再按当前配置重新设置。不要同时让多个客户端争用同一个端口或反复写入系统代理。

Windows 可在系统网络设置中查看手动代理，也可以用命令读取 WinHTTP 层配置。需要注意，WinHTTP 与普通桌面应用使用的代理设置并不完全相同，某个命令显示“直连”不能单独证明浏览器没有使用代理。macOS 可按当前网络服务分别配置网页代理和安全网页代理；切换无线网络服务后，旧网络服务上的设置不一定作用于当前连接。Linux 桌面环境可能使用图形设置、环境变量或应用自身配置，三者应分别核对。

netsh winhttp show proxy

scutil --proxy

env | grep -i proxy

识别忽略系统代理的应用

命令行工具通常读取 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY 环境变量，但也可能要求在自身配置中指定。环境变量中的代理类型要与本地入口匹配，作用域也要明确：只在当前终端设置时，新开的另一个终端不会继承；写入全局环境后，客户端关闭时又可能留下失效地址。排查阶段建议只在当前会话临时设置，并在测试后移除。

某些应用采用 UDP、直连套接字或自己的 DNS，不会遵循 HTTP 系统代理。此时可考虑 TUN 模式，让虚拟网卡在网络层接管流量。开启前应确认管理员权限、虚拟网卡驱动和路由设置正常，并排除局域网地址，避免打印机、路由器管理页和文件共享被送入远端。TUN 不是修复错误节点的替代方式：节点握手本身失败时，扩大接管范围只会让更多应用同时失败。

处理代理残留、环路与局域网绕过

代理环路常见于浏览器扩展指向系统代理、系统代理又被另一个工具转发，或客户端自身更新请求被错误送回自己的监听端口。表现包括 CPU 占用升高、日志中同一目标快速重复、网页持续加载但没有结果。关闭浏览器代理扩展和其他网络工具，只保留客户端写入的系统代理；确认恢复后，再决定是否需要应用级规则。

系统代理的绕过列表应包含本机和必要的局域网地址。访问 localhost、127.0.0.1 或私有网络设备时，通常不应绕远端。若绕过范围写得过宽，例如用模糊通配符覆盖大量域名，又会导致原本需要代理的请求直连。每条绕过规则都应说明对象，修改后用一个局域网地址和一个外部目标分别验证。

客户端正常退出时通常会恢复系统代理，但系统强制关机、进程崩溃或权限不足时可能无法完成。出现客户端未运行却全局无法上网时，先在操作系统中关闭手动代理，再重启浏览器。若频繁发生，应检查客户端是否有足够权限写入设置、是否被安全软件阻止，以及是否存在另一个程序定期改写代理。端口变更后同步更新系统代理的完整操作可参考本地监听端口冲突处理。

最终验证应覆盖三类应用：一个读取系统代理的浏览器、一个通过自身代理设置连接的工具，以及一个需要 TUN 才能接管的应用。三类结果可以明确系统代理和 TUN 的边界。不要为了让单个应用工作而同时开启所有接管方式；选择能够覆盖目标流量的最小方案，后续路由与故障定位会更清晰。

从启动日志确定退出阶段

如果客户端窗口能打开，先查看日志目录和主界面最后几行信息。配置解析错误通常在内核启动后立即出现，并指出字段、JSON 位置或不支持的配置项；端口占用会显示绑定失败；运行数秒后退出，则可能与 TUN 权限、虚拟网卡、网络环境或某条实际请求有关。不要在日志尚未保存时反复重启，先复制发生时间附近的错误文本，并遮住节点地址、用户标识和订阅参数。

如果界面完全打不开，检查系统任务管理器或活动监视器中是否存在残留进程。残留进程可能持有数据库和端口，使第二次启动失败。正常结束残留进程后再启动一次，不要同时连续点击多个启动入口。桌面端首推 v2rayN，应从客户端下载页选择对应系统与处理器架构的安装包。macOS 首次启动涉及系统安全放行和网络权限时，可参阅macOS 安装与权限处理。

隔离用户配置与程序文件

升级后闪退不一定是程序本身损坏，也可能是旧数据库、主题设置或自定义配置与新结构不兼容。先备份订阅地址和必要设置，再关闭客户端。不要直接删除原数据目录；将其改名，让客户端在空白配置下启动。如果空白配置能够正常运行，说明问题位于用户数据。此时应逐步恢复订阅和设置，而不是把整个旧目录一次性覆盖回去。

自定义 JSON 配置最容易造成内核启动失败。可以先切换到由客户端生成的普通节点配置，确认内核能够运行，再检查自定义文件。JSON 不允许尾随逗号，字符串中的反斜杠和双引号需要正确处理，字段类型也必须符合内核要求。下面的命令可用于检查 JSON 基本语法；文件名按实际路径替换。

python -m json.tool config.json

语法正确仍不代表配置语义正确。不存在的出站标签、路由规则引用错误、重复监听端口和不受当前内核支持的字段，都可能在加载阶段失败。应从日志指出的第一条错误开始修复，后续错误有时只是第一处失败引发的连锁结果。

检查权限、安全策略与系统资源

TUN 模式需要创建虚拟网卡和修改路由，普通权限不足时可能在开启瞬间退出。先关闭 TUN，验证普通系统代理模式能否运行；普通模式正常而 TUN 崩溃，再检查管理员权限、虚拟网卡状态和系统中其他 VPN 类网络驱动。多个虚拟网卡同时修改默认路由时，也可能导致内核启动后失去网络并反复重启。

安全软件可能隔离内核子进程、阻止其监听本地端口或限制它读取配置目录。应查看系统安全记录中与客户端启动时间对应的事件，并根据明确记录处理，而不是盲目关闭全部防护。程序目录没有写入权限时，日志和数据库也可能创建失败；将客户端安装在当前用户可读写的位置，并避免直接从压缩包预览窗口运行。

持续运行一段时间后崩溃，还要观察内存、磁盘空间和日志体积。过度详细的日志在高连接量环境下会快速增长，磁盘空间不足会影响配置写入与更新。清理旧日志后将级别恢复为普通，再复现一次。若崩溃只由某个节点触发，复制该节点进行字段对照；若空白配置也持续崩溃，则记录操作系统、客户端名称、崩溃时间和系统事件信息，重新安装当前适配架构的客户端。排查期间不要同时导入大量订阅，以免把配置问题和运行环境问题混在一起。

连接按钮无效或 VPN 授权失败

首次启动连接时，系统会显示 VPN 连接确认。未确认、系统中已有其他 VPN 服务或工作资料策略限制时，客户端无法建立接口。先断开其他 VPN 类应用，返回客户端重新启动连接，并完成系统确认。状态栏出现 VPN 标记只说明接口已经创建，仍需查看客户端日志确认节点握手是否成功。若连接后立即停止，检查节点配置、当前网络和应用后台权限，不要只重复点击启动按钮。

从一个客户端切换到另一个客户端时，应先在原客户端停止服务，再打开新客户端。v2rayNG 使用 Xray 内核，v2flyNG 使用 v2fly 内核，二者可作为 Android 上的不同选择，但不应同时建立系统 VPN。订阅可分别导入测试，节点参数需要保持一致，避免把客户端差异与节点差异混为一谈。需要重新安装时，从Android 客户端入口选择 v2rayNG 或 v2flyNG，并优先按设备架构选择安装包。

处理后台断开与网络切换

系统的电池优化可能在息屏后限制客户端后台运行。把当前使用的客户端加入允许后台运行的应用列表，并允许自启动或后台活动；不同设备的设置名称可能是电池优化、后台使用、电量管理或休眠应用。只调整实际使用的客户端，不需要给所有网络应用放宽限制。完成设置后锁屏数分钟，再解锁测试网页和日志，确认服务是否仍在运行。

从无线网络切换到移动网络时，本地 IP、DNS 与默认路由都会变化。多数情况下客户端会自动重建连接，但旧连接可能在短时间内保留。切换网络后若无法访问，先停止再启动一次服务，让 VPN 接口重新绑定当前网络。频繁在两个网络之间切换会造成测试结果混乱，排查时固定一种网络完成验证，再测试另一种网络。若只有某个网络失败，应回到节点超时和 DNS 章节判断该网络的可达性。

检查应用分流与私人 DNS

Android 的应用分流可以选择哪些应用进入 VPN。采用白名单时，新安装的应用可能默认不经过客户端；采用排除模式时，被排除的浏览器也不会走代理。排查“只有一个应用不可用”时，先查看该应用是否被选中，再暂时关闭应用分流进行对照。全部应用正常后，再恢复分流并逐个加入规则。系统组件、下载管理器和浏览器调用的外部服务可能属于不同进程，因此单选主应用不一定覆盖完整请求链路。

系统私人 DNS 会在 VPN 之外或之内形成另一条解析路径，具体行为取决于系统和客户端设置。出现域名失败但 IP 可达时，先把私人 DNS 恢复到自动状态进行对照，再检查客户端 DNS。浏览器自身的安全 DNS 也可能绕开内核规则，排查期间应保持默认设置。确认客户端 DNS 正常后，再决定是否恢复系统级自定义解析。

局域网访问失败时，检查是否启用了绕过局域网，以及应用是否尝试访问私有地址。某些设备在 VPN 开启后会默认阻止不经 VPN 的连接，导致打印机、路由器管理页或局域网服务不可达。应在客户端中为私有地址设置明确直连，并确保系统没有启用会阻断所有非 VPN 流量的严格选项。修改后分别测试局域网地址和外部网页，防止直连范围扩展过度。

二维码导入后连接失败时，逐项比较协议、地址、端口、用户标识、安全层、服务器名称和传输路径。相机识别可能截断过长内容，剪贴板也可能保留换行。订阅导入通常比手动扫描多个节点更便于更新，但订阅更新失败时仍需按本页订阅章节检查。最后保留一个可稳定复现的节点，分别在无线网络和移动网络测试；仅某种网络失败属于路径问题，两个网络都失败且桌面端同配置可用，则重点比较 Android 客户端中的 DNS、应用分流和传输字段。

如果应用在后台稳定运行但消息或同步延迟，不要直接把所有应用加入代理。先确认目标应用是否被系统省电策略限制、是否依赖被排除的系统组件，以及其域名是否命中预期路由。Android 专项排查的核心是把系统 VPN、客户端内核和应用权限分开验证：VPN 接口存在、内核连接成功、目标应用进入接口，三项同时成立才构成完整链路。