Clash 故障排查大全

无法上网：分离故障层级

先判断直连网络是否正常

先关闭客户端的系统代理与 TUN，再退出客户端，使用浏览器访问平时能够直连的网站。公共无线网络可能要求登录认证页；网线已连接、无线图标正常，并不能证明已经取得可用的互联网出口。如果此时仍然失败，应先检查路由器、认证状态和其他设备的联网情况。不要在基础网络尚未恢复时连续更换节点，否则每次失败都会混入同一个底层原因。

退出后仍无法直连，要检查系统是否残留本地代理地址，以及其他 VPN 是否仍在接管路由。正常退出客户端不一定能恢复被其他程序修改的设置。先记录原值，再取消不再使用的手动代理；受组织管理的设备应遵循管理员策略。不要直接重置所有网络适配器，重置可能同时删除工作网络的静态地址和专用路由。

确认本地入口与代理出口

重新启动客户端，只加载一份配置，先保持 TUN 关闭。查看内核是否成功运行，以及混合端口的实际值。下面的命令假设监听在本机的 7890 端口；若界面显示其他端口，应同步修改。Windows 可在终端中使用 curl.exe，避免部分终端环境将命令解释为其他工具。测试地址仅用于取得一致的对照结果，不能代表所有站点的可达性。

curl --noproxy "*" -I --connect-timeout 10 https://example.com
curl --noproxy "" -x http://127.0.0.1:7890 -I --connect-timeout 10 https://example.com

如果显式指定代理后立即出现连接被拒绝，先检查本地监听，不要归因于远端节点。常见原因是内核没有启动、端口填错，或端口被另一份客户端占用。如果能够连接本地端口，但随后等待远端响应超时，说明请求已经进入下一阶段，应继续查看连接日志中的目标地址、出站策略与握手错误。两种结果对应不同层级，处理方法不能互换。

用单一变量定位模式与规则

确认本地入口可用后，在规则模式中查看测试请求实际命中了哪一条规则。全局模式可以作为短时对照：选择同一个已知可用的出站，保持测试地址不变。如果全局模式成功、规则模式失败，应检查规则顺序、策略组选择及直连出口，而不是继续修改订阅。全局模式也不能修复坏节点，测试结束后应恢复原先模式。

策略组内显示了名称，不代表已经选中了有效成员。检查组是否引用了存在的节点或提供器，特别注意订阅更新后名称变化造成的失效引用。规则从上向下匹配，位于前面的宽泛直连规则可能截走目标；最后的兜底也必须指向真实策略。不要一次替换整套规则，先用连接记录确认命中，再调整最小范围。

恢复后分别测试浏览器、新开的终端和原来失败的应用。浏览器成功而其他应用失败，通常还涉及代理接入方式；只有域名请求失败则转到 DNS 章节。如果还不能复现稳定结果，补记是否从睡眠中恢复、是否刚切换网络，以及是否存在第二个网络工具。保留这些条件，比重复描述“已开启但不能用”更有诊断价值。

节点超时：检查传输与握手

区分测速失败与业务连接失败

客户端的延迟测试通常访问一个指定地址，结果反映的是这条测试路径，不等同于全部业务流量的状态。测试地址被限制、重定向或临时不可用时，节点可能显示超时，但普通网站仍然能访问。反过来，测试成功也只证明一个轻量请求完成，不能证明视频传输、上传或长连接稳定。先用真实失败的应用复测，再决定是否判定节点不可用。

先在同一网络中比较不同节点，再让同一节点切换到另一条可信网络测试。只有一个节点失败，优先检查该节点的服务状态和参数；所有节点在当前网络失败、切换网络后成功，则更像是接入网络限制或路由问题。测试时保持客户端模式和配置不变，否则无法判断差异究竟来自网络还是配置。

按连接阶段读取日志

开启客户端提供的日志页，短时提高日志等级，发起一次请求后立即记录相关行。解析错误发生在取得服务器地址之前；连接超时通常发生在传输建立期间；握手失败说明连接已经推进到协议协商。日志中的远端关闭、认证失败和证书错误也不能统一解释为网络慢。先确认最早出现的错误，后续连续报错可能只是前一个失败的连锁结果。

对于使用 TLS 的连接，先确认系统日期、时区和自动校时是否正常。再核对服务器名称、传输类型、路径等字段是否与服务端一致。服务器地址与用于证书验证的名称可能不是同一个字符串，不能凭猜测互相替换。遇到证书错误时，不应把跳过证书验证当成通用修复；这会掩盖配置错误，也削弱连接身份验证。

检查协议能力与探测条件

某些传输依赖 UDP，当前网络可能允许普通网页连接，却限制 UDP。此时应在服务方提供的可用选项中选择不同传输作为对照，而不是只修改本地端口。不要据此认定所有 UDP 应用都不可用：节点协议的底层传输与被代理应用使用的传输是两个层面，需要分别检查支持能力和规则。

旧内核可能无法识别订阅中的新协议字段。若日志明确显示类型不支持，应先核对客户端实际使用的内核，再选择兼容客户端或兼容订阅格式。可从下载页优先查看 Clash Plus，或按系统选择其他维护中的客户端。内核关系与字段差异见原版、Meta 与 mihomo 内核对照，不要仅凭配置文件扩展名判断兼容。

短时间内连续启动大量并行探测会给本地网络和远端服务增加负担，反而制造更多超时。暂停自动测试，固定一个节点，等待旧连接结束后再发起少量请求。若需要向服务方反馈，提供脱敏后的错误阶段、接入网络类型和复现时间，不公开认证信息。修复后同时检查轻量请求和持续连接，确认不是只恢复了检测入口。

订阅失败：分清下载与解析

检查请求是否真正取回配置

订阅更新失败有两个主要阶段：地址没有取回内容，或取回的内容无法被当前客户端读取。先查看更新提示与日志，确认是域名解析、连接超时、访问拒绝，还是配置解析错误。订阅列表仍显示旧节点时，也不能认定更新已经成功；不少客户端会保留上一份可用缓存，界面继续可用与远端刷新成功是两件事。

从服务方管理页面重新复制完整订阅地址，检查是否带入空格、换行或聊天工具添加的标点。地址中的查询参数可能用于授权，随意删减会使请求失效。使用系统剪贴板时注意其他应用可能读取内容；不要为了验证链接，将它提交给不明转换站。若链接曾公开，应在服务方提供的管理功能中更换订阅授权。

访问拒绝不一定是客户端故障，也可能是订阅过期、流量条件、访问频率或服务端策略。打开地址后得到登录页面、错误说明或网页验证内容，虽然属于成功取回网页，却不是成功取得配置。排查时只需确认响应类型与错误信息，不必将整份响应分享出去。遇到临时限流，应停止反复点击更新，按服务方说明等待或处理账户状态。

核对配置类型与更新路径

完整配置、节点列表和规则集不是同一种内容。完整配置可以包含端口、策略组与规则；代理提供器通常只接收节点数据；规则提供器接收指定行为类型的规则。把节点列表当作完整配置导入，可能导致规则与策略组缺失；把完整配置填进规则集地址，则会出现结构错误。应先确认服务方提供的是哪一种入口，再选择客户端对应功能。

订阅下载本身也需要可用网络。有些配置让更新请求经过代理，而唯一的可用节点又依赖本次更新，形成启动依赖。可以临时使用客户端支持的直连更新方式，或先切换到另一条已验证的出站；前提是该订阅地址确实允许这样访问。不要为了打破依赖，把包含授权的地址转交给第三方代抓。

解析错误与本地覆盖

出现 YAML 错误时，优先查看报错附近的缩进、冒号和列表符号。使用空格缩进，避免制表符；带有特殊字符的字符串应按语法正确引用。错误行号可能指向后一个无法继续解析的位置，所以也要检查上一行。不要直接删除报错字段来追求加载通过，字段可能承载认证、传输或策略关系，删除后只会把解析失败变成运行失败。

mode: rule
log-level: info
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,DIRECT

这段只用于观察列表层级与规则写法，并不包含代理出站，不能替代完整订阅。若原配置存在名为其他名称的策略组，规则必须使用完全一致的名称，包括空格和大小写。解析通过后仍提示策略不存在，应沿着规则、策略组、节点或提供器逐级检查引用，尤其注意远端更新删除旧名称的情况。

修复时先备份当前配置，再在独立副本中导入新订阅。确认节点、策略组和规则完整后再切换，不要同时删除旧缓存和旧配置。若只有自动更新失败，手动更新成功，应检查计划任务是否受休眠、后台限制或启动时网络尚未就绪影响。基本概念可查常见问题；操作顺序回到配置教程，本章重点保留故障分支与恢复依据。

速度慢：拆分解析与传输

先描述慢在哪一个阶段

页面长时间空白、开始传输后速度低、播放过程中周期性停顿，分别可能对应解析、建连、吞吐或连接稳定性问题。先记录从点击到首个响应的等待，以及开始传输后是否持续变慢，不要只凭一个延迟标签判断。轻量探测传输的数据很少，结果较短并不意味着大文件下载更快；反过来，较长的往返时间也不必然限制持续传输吞吐。

选择同一目标，在相近时间使用同一设备测试，先关闭其他下载、云盘同步与系统更新。无线信号弱、设备漫游或路由器负载高，会让直连与代理同时变慢。可以用有线网络或靠近接入点作为对照，但不要在一次比较中同时更换设备、网络、目标站与节点。变量过多时，即使速度改善，也难以形成能够重复的结论。

确认实际出站及连接复用

在连接页查看目标域名、命中规则和实际出站。策略组被命名为自动选择，不代表当前连接一定使用预期成员；检测地址与业务目标的路径也可能不同。切换策略后，原有长连接可能继续使用旧出站，浏览器连接池和应用会话不会必然立即重建。应关闭测试会话或等待其自然结束，再开始新的对照，不要用旧连接判断切换是否生效。

自动选择与故障转移解决的问题不同。前者通常依据测试结果选取成员，后者更关注可用性；两者都不保证每个目标的吞吐最佳。检测间隔过短还可能引起频繁探测。若当前问题是播放中断，先固定一个稳定出站观察，再考虑是否恢复自动策略。持续切换会给需要保持会话的业务带来额外变量。

检查目标差异与协议限制

如果只有某个网站慢，应比较同节点下的其他站点，并查看目标是否经过内容分发网络。不同出口可能被分配到不同缓存位置，单个资源源站也可能限速。此时更换全局 DNS 不一定有效，因为解析可能发生在代理端，或连接已经复用旧地址。先确定域名由哪一侧解析，以及慢的是全部请求还是某个大资源，再决定处理位置。

部分应用会尝试使用基于 UDP 的传输，如果路径不稳定，可能经历失败后回退。客户端、节点与接入网络都可能影响这条路径。可在应用提供的正式设置中做有限对照，但不要把禁用某种协议扩展成全设备默认做法。业务能够恢复后，应记录原设置和变化，确认是否存在长期兼容性影响。

TUN 环境中，如果小请求成功、大响应停滞，才需要进一步怀疑路径 MTU 或分片相关问题。先排除无线丢包和远端限速，再使用客户端支持的参数做单项测试。随意将 MTU 调到极低值会增加封装与处理开销，也可能掩盖真正的路由问题。记录默认值，每次调整后重建连接；没有可重复改善就恢复，而不是保留一组来源不明的参数。

观察本机资源与测试边界

传输期间观察处理器、内存和磁盘占用。如果内核处理器占用持续很高，而其他网络程序也在竞争资源，应减少并行连接、关闭不必要的调试日志，再比较结果。规则数量大并不能单独解释速度问题，应结合具体内核、规则行为与设备资源判断。安全软件的网络检查也可能增加开销，但不建议为测速长期关闭设备保护。

确认原因后只保留有效修改。如果问题来自特定节点容量或远端站点，本地配置无法保证解决，应更换服务方提供的可用出口或等待远端恢复。如果每次睡眠唤醒后才变慢，则优先检查网络接口与路由恢复，而不是继续叠加性能参数。与虚拟网卡接管相关的原理可参阅TUN 模式设置说明。

DNS 问题：追踪解析路径

识别谁在执行解析

DNS 问题常表现为域名打不开，但并非所有域名错误都来自同一个解析器。浏览器可能启用独立的加密 DNS，系统有自己的缓存，客户端内核还可能维护代理侧解析。先判断失败应用使用哪条路径，再检查对应日志。系统查询命令返回正常，只能说明该命令使用的解析路径可用，不能证明浏览器或代理端取得了同一个地址。

不要用任意网站的裸地址访问作为唯一依据。HTTPS 通常依赖域名进行证书验证与服务选择，直接访问地址可能被拒绝，即使 DNS 本身完全正常。应结合客户端日志、系统查询结果与同一域名的请求表现交叉判断。若日志已经显示本地监听失败或远端认证错误，继续清理 DNS 缓存通常不会产生帮助。

理解 Fake-IP 与真实地址模式

Fake-IP 会向应用返回虚拟地址，内核再通过映射找回域名并完成路由。在这种模式下，系统查询得到虚拟地址是预期行为，不表示域名被错误解析。关键是后续连接必须继续进入同一个内核；如果查询经过客户端，连接却绕过客户端，应用就可能尝试直连虚拟地址。应先检查流量接管是否完整，而不是立即把虚拟地址替换成公网地址。

有些局域网服务、设备发现或特殊应用不适合使用虚拟地址。可以针对实际失败的域名设置过滤，但不应把所有域名都加入过滤列表，否则会改变模式的主要行为。不同内核的过滤语法与附加模式可能存在差异，先核对兼容性。相关原理与适用边界见Fake-IP 与 redir-host 对照。

检查上游与引导依赖

下面是面向兼容 mihomo 配置的 DNS 片段，不是完整代理配置。它使用公共解析器展示引导、加密查询与指定域名策略的层级；解析器应按当前网络可达性和实际需求选择。片段不声明监听地址，也不会自动修改操作系统 DNS。只有客户端完成接管，应用请求才会进入这段设置。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost"
  default-nameserver:
    - 1.1.1.1
  nameserver:
    - https://cloudflare-dns.com/dns-query
  nameserver-policy:
    "example.com":
      - https://dns.google/dns-query

使用域名形式的加密解析器时，内核首先需要得到该解析器自身的地址，这就是引导依赖的一部分。如果引导解析不可达，后面的加密查询也无法启动。节点服务器本身若使用域名，同样需要可靠的解析路径；不要让取得节点地址的唯一办法依赖一个尚未建立的代理连接。遇到循环依赖，应检查客户端对节点域名解析与代理侧解析的独立设置。

nameserver-policy 用来对指定域名选择上游，不等于连接分流规则，也不能代替出站策略。fallback 及其筛选条件的行为应按内核文档理解，不能简单当成主解析器失败后才启动的备用列表。增加更多解析器可能扩大查询范围，并不自动提高准确性或隐私性。先用最小上游组合建立稳定结果，再添加确有用途的例外。

按顺序清理缓存与验证

配置修改后，先重新加载内核，再关闭测试应用中的旧会话；必要时清理系统 DNS 缓存。不要在仍有旧虚拟地址连接时只清空内核映射，否则可能暂时出现地址与域名脱节。企业内部域名需要内部解析器，替换成公共解析器往往无法解决，反而会让原本可达的工作服务失效。

验证时分别检查公网域名、局域网名称和原来失败的应用。隐私检测页面显示某个解析服务商，只是观察到的一条线索，不能单独证明所有查询的走向；应与浏览器设置、系统接口及内核日志一起确认。进一步的检测步骤见DNS 泄漏检测与防泄漏配置，不要以单个检测结果替代完整路径分析。

代理失效：核对接管范围

区分系统代理与 TUN

系统代理是向遵循系统设置的应用提供代理入口，并不自动接管所有程序。部分终端工具、游戏和后台服务使用自己的网络配置，忽略系统代理属于可能的正常行为。TUN 则通过虚拟网卡与路由接收流量，但仍受到接口、权限和排除规则影响。看到开关已开启，只能说明客户端尝试应用设置，不能证明目标请求已经经过内核。

先在 TUN 关闭时测试系统代理。打开一个新浏览器会话并查看连接页，确认访问目标产生了对应记录。随后用显式代理命令对照，如果命令成功而浏览器失败，应检查浏览器代理扩展、应用独立代理及绕过列表。若命令也无法连接本地入口，则返回监听排查，不要继续修改应用设置。

检查端口、环境变量与平台设置

mixed-port 提供 HTTP 与 SOCKS 共用入口，应用必须使用它支持的代理协议。配置中的控制接口不是代理端口，把控制端口填进浏览器不会转发网页请求。监听地址若只允许本机，也不能直接供手机或其他设备连接；将监听扩展到局域网属于另一项安全决策，应同时考虑认证与防火墙，而不是为了测试默认向所有接口开放。

终端工具常读取代理环境变量，而已经启动的进程不会自动取得新值。下面的命令用于检查当前环境，不负责更改系统设置。检查时注意同时存在的大写、小写变量与绕过列表，部分工具采用的优先级不同。清理旧变量后应新开终端复测，不能仅在另一个窗口修改设置，就假定原进程已经同步。

# macOS / Linux：查看当前进程继承的代理变量
env | grep -i proxy

# Windows PowerShell：查看代理相关环境变量
Get-ChildItem Env: | Where-Object Name -Match 'proxy'

让 TUN 成为独立的测试步骤

系统代理路径稳定后再开启 TUN，检查客户端是否完成必要的服务安装和权限授权。不要为了授权让整个桌面应用长期以过高权限运行，优先使用客户端提供的服务机制。虚拟网卡出现也不等于路由已生效，需要观察目标连接是否进入内核，以及当前默认网络接口是否被正确识别。

同时运行多个 VPN、虚拟机网络或其他 TUN 工具，可能产生重叠路由。先停用非必要接管工具，再测试单一客户端。睡眠唤醒或切换网络后，旧接口与旧路由可能失效，此时可以重新启用 TUN，让客户端重新探测网络；不要直接删除不认识的系统路由，工作 VPN 和虚拟机也可能依赖它们。

局域网设备访问失败时，应检查私有地址的路由与绕过规则，而不是把全部流量改为直连。打印机、网络存储和内部服务各自可能需要不同的发现方式。若远程控制当前设备，调整路由之前先保留现场恢复方式，避免修改后失去连接。配置含义可继续参阅虚拟网卡接管说明。

最终验证应覆盖原先失败的程序，不只看浏览器。记录它使用系统代理、应用代理还是 TUN，确认退出客户端后系统仍可按预期联网。对不遵循系统代理的应用，使用其正式支持的接入方式；不要把开关无效等同于客户端崩溃。只有接管范围明确，后面的规则命中和 DNS 判断才有可靠前提。

客户端崩溃：保留恢复路径

先区分界面退出与内核退出

窗口消失、托盘图标仍在、代理突然停止，可能来自不同进程。部分客户端的界面和内核独立运行，界面重启不一定会结束旧内核；内核崩溃也可能只在界面上显示未运行。先通过客户端状态页与系统进程工具确认实际情况，再保存最近日志。不要连续打开多份客户端，否则残留进程会占用端口，使后续启动错误覆盖最初的崩溃线索。

如果退出后系统仍指向本地代理，但本地入口已不存在，会表现为所有网页打不开。先按系统代理章节恢复网络，再处理程序本身。不要在尚未保存配置时清理整个数据目录；其中可能包含本地覆写、策略选择和订阅记录。备份应存放在受控位置，不同步到公开仓库，也不直接作为问题附件上传。

检查架构、权限与启动错误

安装包需要与操作系统及处理器架构匹配。文件能够下载完成，不表示当前系统能够运行；安装器拒绝、可执行格式错误与运行后崩溃也要分开处理。重新选择客户端时可从客户端列表优先查看 Clash Plus，并核对系统要求。Clash for Windows 与 ClashX Meta 属于已停止维护的选项，不应作为解决新系统兼容问题的默认方案。

日志提示地址占用时，先确认是否存在另一份内核，或其他服务使用同一端口。关闭明确属于旧客户端的进程，或调整本地监听端口并同步应用设置。不要终止用途不明的系统进程。出现权限不足时，检查数据目录是否可写、文件是否被其他账户创建，以及安全软件是否隔离了必要组件；不要直接关闭全部保护功能来绕过原因。

以配置副本隔离问题

先备份，再使用客户端支持的新配置或独立资料目录启动最小配置。如果空白环境稳定，而原配置立即导致内核退出，重点检查新增的提供器、规则集、脚本支持和字段兼容。配置能通过语法解析，并不代表每个外部资源都可获取，也不代表当前内核支持所有行为。逐段恢复比一次粘贴全部内容更容易确定触发项。

若故障发生在更新之后，分别记录界面与内核是否都发生变化。不要把不同来源的内核文件直接覆盖到安装目录，客户端可能对启动参数和接口有约定。优先使用其正式提供的内核管理与恢复方式。恢复旧环境只作为验证与临时回退，不能据此永久忽略已经确认的兼容或安全更新。

只有界面白屏、内核仍能转发时，才进一步检查图形渲染与界面缓存。先确认程序是否提供正式的图形加速设置，再进行单项对照。清除界面缓存前区分缓存与用户资料，不要按网上一条宽泛路径直接删除全部目录。对于无法启动的情况，应先使用系统日志或客户端日志目录获取信息，而不是要求用户在打不开的设置页里操作。

观察资源与建立可复现报告

内存持续增长、订阅刷新时退出或长时间运行后崩溃，需要记录触发条件。先暂停不必要的自动刷新与密集探测，缩小外部资源范围，再观察是否仍然复现。设备磁盘空间不足也可能造成数据库写入和日志创建失败。应恢复基本存储余量，但不要只看总体空闲空间，还要检查客户端实际数据分区和账户配额。

修复后重新加载备份配置，确认策略选择、覆写和更新任务仍然存在，再测试正常退出与再次启动。若故障仅在某一配置下出现，可逐步还原到能够触发问题的最小片段；若最小环境也会退出，应沿系统兼容、运行依赖与程序缺陷继续调查。重装是恢复手段之一，不是能够解释所有崩溃的诊断结论。

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

Android：检查 VPN 授权与后台限制

Android 客户端通常通过系统 VPN 接口接收流量。首次连接需要明确授权，只有界面按钮变为开启并不足以证明隧道建立，应同时查看系统 VPN 状态与客户端连接记录。工作资料、企业管理策略或其他 VPN 应用可能占用相关能力。先确认当前生效的是哪个服务，不要让两个工具反复争抢接管状态。

可从Android 下载入口优先查看 Clash Plus，也可按兼容需求选择 Clash Meta for Android、FlClash 或 Surfboard。不同客户端支持的配置格式和功能范围并不完全一致，不能把一份完整 Clash 配置直接视为所有客户端的通用文件。更换应用前先导出必要配置，并确认订阅服务方是否提供对应格式。

锁屏后断连、亮屏后恢复，常与电池优化和后台执行限制有关。检查系统对当前应用的电池策略、后台数据权限及厂商提供的自启动设置。只对确需持续工作的客户端调整，避免把所有应用都设为不受限制。若启用了系统的始终开启 VPN 或阻止不经 VPN 的连接，隧道退出时网络被阻断可能是系统策略的预期结果，而不是无线网络损坏。

iOS：核对系统隧道与按需连接

iOS 可通过下载页的 Clash Plus 商店入口安装，官网为 clashplus.io。首次添加 VPN 配置时按系统提示授权。连接图标只是系统状态线索，仍需通过实际请求与客户端记录确认流量路径。若已有其他 VPN 配置，先检查是否正在使用不同的隧道，避免误把旧配置的状态当成当前客户端结果。

应用退到后台后，设置界面不再活跃并不等于系统隧道停止。应通过目标应用能否联网、系统 VPN 状态和重新打开客户端后的日志共同判断。若使用按需连接规则，检查触发条件是否包含当前无线网络或蜂窝网络；网络名称变化和规则匹配差异可能导致连接行为不同，不宜反复删除系统配置来碰运气。

无线与蜂窝网络分别验证

先在稳定无线网络下完成一次连接，再关闭无线改用蜂窝网络，保持节点和模式不变。若只有蜂窝失败，检查客户端蜂窝数据权限、运营网络限制及节点传输的可达性。若只在某个无线网络失败，先处理认证页和路由限制。公共网络需要网页登录时，VPN 接管可能妨碍认证流程，应在理解当前系统阻断策略的前提下暂时断开并完成登录。

切换网络后，旧连接可能保留原来的地址与路由，短暂失败不一定需要重导订阅。先结束目标应用的旧会话，观察客户端是否已经重新建连；必要时关闭再开启当前隧道。频繁切换飞行模式会同时改变网络、地址与会话状态，只能作为有限的恢复动作，不能据此确定根因。记录问题发生在切换瞬间还是持续存在，能够明显缩小排查范围。

检查分应用规则与局域网访问

Android 的分应用接管列表尤其容易产生遗漏：应用被排除后，客户端规则再完整也不会接收到它的请求。先核对列表采用包含还是排除模式，再检查新安装的应用是否进入范围。应用自身还可能调用系统服务完成下载，表现与主进程不同，需要结合连接日志判断。不要只因某个浏览器可用，就认为其他应用一定走相同路径。

手机访问局域网存储、投屏或打印设备失败时，检查本地网络权限、地址段绕过和设备发现路径。发现协议与普通网页访问不同，即使能打开设备地址，也不保证自动发现正常。不要将所有私有地址永久强制代理，也不要为了恢复投屏将整份规则清空。先断开隧道验证局域网基线，再逐项恢复必要的绕过条件。

最后做三组回归：亮屏使用、锁屏后恢复、无线与蜂窝切换。每组使用原来失败的应用验证，并确认重启设备后授权与配置仍能正常恢复。若问题只与某个应用相关，补充它是否使用独立 DNS、是否被分应用排除及是否受后台限制；一般连接概念见常见问题，首次配置仍按快速上手教程完成，不在故障处理中反复重建全部设置。