Clash 故障排查
连接、配置与网络接管

无法上网：先拆分本地网络与代理链路

先记录症状出现的时间和范围：是全部应用断网，还是只有浏览器；是所有网站失败，还是单个域名失败；关闭客户端后能否恢复。不要一开始同时换节点、改 DNS、开启 TUN 和重装软件，这会消除故障证据。保存当前配置副本，记下代理模式、选中的策略组和系统代理状态。后续每一步都用同一目标重复验证，才有条件判断改动是否有效。

恢复直连基线

在客户端里关闭系统代理和 TUN，然后正常退出客户端。检查系统网络设置，确认没有残留的手动代理或自动代理脚本。用一个平时直连可访问的网站验证，并查看路由器、无线网络和其他设备是否正常。如果同一网络上的其他设备也失败，应先处理接入网络；如果只有本机失败，检查网卡连接、默认路由、认证页面和其他 VPN。公共无线网络可能需要先完成网页登录，代理接管反而会妨碍认证。

直连恢复后再启动客户端。确认界面显示的是内核正在运行，而不只是窗口已经打开。查看日志中是否有配置加载失败、端口占用或权限错误；如果内核没有启动，节点选择和模式切换都不会产生实际效果。先修正日志里的第一条明确错误，避免被后续连锁报错带偏。客户端退出后网络仍不恢复时，重新检查系统代理地址，而不是连续强制结束进程。

用明确代理请求验证入口

下面以本机混合端口 7890 为例。执行前在客户端设置中确认实际端口，并按实际值修改命令；目标 example.com 仅用于演示，可换成此次故障涉及且已知可访问的 HTTPS 地址。Windows 使用 curl.exe，避免命令别名影响结果。明确指定代理可以绕开系统代理读取差异，但在 TUN 开启时仍可能受到虚拟网卡路由影响。

# 明确使用本机 HTTP 代理
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 25 -I https://example.com

# 不读取环境变量中的代理；测试直连前应关闭 TUN
curl --noproxy "*" --connect-timeout 10 --max-time 25 -I https://example.com

如果返回连接本机端口失败，重点检查内核、监听地址和端口；如果已经连接本机端口，随后远端连接超时，继续查节点和出口；如果收到 HTTP 状态码，说明至少已走到目标服务，不能再简单归类为完全断网。部分站点不支持 HEAD 请求，返回方法错误也不等于代理失败，可去掉 -I 再试。不要仅凭浏览器空白页判断网络层原因。

检查规则与策略组的实际去向

明确代理请求成功而普通访问失败时，打开连接面板，找到同一时间、同一域名的请求。查看命中的规则、目标策略组和最终节点。规则模式下，目标可能被分到 DIRECT 或 REJECT；策略组名称正确也不代表组内已经选到有效节点。临时切到全局模式可以作为对照，但只对进入内核的流量有效；如果应用根本没有使用代理，全局模式不会把它自动接管。

若只有个别应用失效，检查该应用自己的代理设置、扩展和缓存，而不是修改全局网络。若所有 HTTPS 请求报证书错误，先核对系统时间和时区，再检查安全软件的 HTTPS 检查功能；不要用关闭证书验证作为长期解决办法。记录一次完整失败请求的时间、规则和错误文本，后续章节可直接使用这些证据，不需要重复猜测整个网络链路。

节点超时：区分测速失败与业务连接失败

节点列表中的超时只表示某次检测没有在规定时间内完成，并不直接证明所有业务都无法使用。检测地址可能不可达，节点可能不支持检测路径所需的连接方式，或者测速请求被过短的超时截断。先手动选中一个节点，通过浏览器和明确代理命令访问实际目标，再看连接日志。只有测速和真实请求同时失败，才应把重点放在节点连通性、认证信息和出口服务上。

建立同网络、同目标的对照

固定当前网络、目标地址和模式，分别测试两个不同节点。只有一个失败，通常是节点本身、线路或配置参数问题；全部失败而直连正常，检查订阅账户状态、服务器域名解析和客户端内核兼容性；同一个节点在另一网络恢复，则要考虑当前接入网络对端口或协议的限制。切换网络后还应重新建立连接，旧连接不会自动成为新网络质量的有效样本。

日志中的连接超时、连接被拒绝、认证失败和 TLS 握手错误属于不同阶段。超时常见于路径不通或服务无响应；拒绝连接说明目标地址可到达但该端口没有接受连接；认证失败需要检查账户、密码或服务端配置；握手错误可能涉及时间、服务器名称、证书或协议参数。把完整错误文本留存下来，比单独记住界面中的红色状态更有排查价值。

检查节点来源和协议字段

优先重新拉取可信来源的订阅，核对失败节点是否仍在提供服务。不要凭网上片段补写协议字段；同名协议也可能依赖不同的传输层、服务器名称或扩展参数。手工配置时检查服务器地址、端口、认证内容和缩进，端口应是服务端实际监听的值，而不是本机代理端口。配置能通过解析只代表语法成立，不能证明远端账号和协议参数有效。

若错误提示不支持某个协议或字段，先检查当前运行的内核，而不只看客户端名称。Clash Plus、Clash Verge Rev 和 FlClash 的界面负责配置管理，实际网络处理仍取决于内核及客户端集成。不要把适用于 mihomo 的完整配置直接交给不兼容的旧内核。需要调整客户端时参见下载页；Clash for Windows 与 ClashX Meta 已停止维护，排查时应把兼容性和系统集成差异纳入考虑。

调整测速方式，而不是伪造可用状态

下面展示自动测速策略组的结构，假定当前完整配置中确实存在名为 线路甲 和 线路乙 的节点。检测地址是教学示例，不承诺它在所有网络中可达。把该片段合并到配置时，应沿用自己的节点名和经过验证的检测地址，不要覆盖订阅里的其他策略组。

proxy-groups:
  - name: 自动选择
    type: url-test
    proxies:
      - 线路甲
      - 线路乙
    url: https://example.com/
    interval: 300
    tolerance: 50

interval 控制检测间隔，单位为秒；tolerance 是切换容差，单位为毫秒，用于避免微小延迟变化导致频繁切换。提高检测频率不会修复不可用节点，反而会增加请求量。自动组和手选组要分开理解：手选节点可用、自动组却持续切换时，重点检查检测目标和组成员，而不是盲目增加节点数量。

如果节点恢复后旧应用仍然失败，关闭该应用的长连接或重启应用再验证。切换策略一般影响新连接，不保证已经建立的会话迁移到新出口。需要稳定日常连接时，可保留一个经过业务验证的备用节点；延迟、倍率和地区的取舍见节点选择说明，自动策略的差异见策略组写法。

订阅失败：检查获取路径、响应内容与配置解析

订阅导入包含两个独立阶段：客户端先获取远端内容，再把内容解析为配置。下载失败和解析失败的处理方向不同。打开订阅详情或日志，先确认是域名解析失败、请求超时、HTTP 状态异常，还是内容已经下载但 YAML 无法解析。更新失败时保留上一份可用配置，不要先删除所有订阅。已有配置通常仍能用于对照测试，但服务端是否继续允许连接取决于账户状态。

确认地址没有被输入过程改变

从服务提供方的账户页面重新复制订阅地址，避免聊天软件换行、中文标点、首尾空格或遗漏查询参数。订阅地址中的参数可能用于认证，不能删掉看起来多余的部分。二维码导入后也应核对配置名称和导入结果，不能仅凭扫码成功认定订阅有效。不要将完整订阅地址粘贴到公开论坛、截图或在线转换工具；需要求助时先遮住路径中的认证内容和全部敏感参数。

返回未授权或禁止访问时，先检查账户是否到期、链接是否被重置以及服务方是否限制请求来源。返回未找到时，确认地址没有被截短，并从原始渠道重新获取。服务器错误或请求过于频繁时，停止连续点击更新，隔一段时间再尝试，并查看提供方公告。客户端不能通过改本机端口修复远端账户拒绝，也不应把服务端错误误判为本地配置损坏。

拆开直连获取与代理获取

部分订阅地址需要代理访问，但当前订阅恰好不可用，会形成获取配置依赖失效节点的循环。检查客户端订阅更新使用的网络路径：它可能走直连、系统代理、指定策略，也可能使用独立的下载逻辑。不要假定浏览器能打开就代表客户端也能获取。保留一条可用的旧连接，或在允许访问的另一网络上重新更新，再将新配置导入；使用哪种路径应以客户端设置和日志为准。

如果地址在浏览器中显示登录页、访问验证页或错误网页，而不是配置文本，客户端往往会报告解析失败。此时 YAML 报错只是后果，根因仍是远端响应不符合预期。请求内容还可能是节点链接集合、编码文本或另一种客户端格式，并不一定是完整 Clash 配置。确认提供方给的是适用于当前客户端的订阅类型，避免用改缩进的方法处理格式根本不同的输入。

按报错位置检查配置合并

看到行号时查看该行前后，而不只盯住单行。YAML 使用空格缩进，制表符、重复顶层键、错误的冒号位置都可能导致解析异常。策略组引用不存在的节点或规则引用不存在的规则集，可能在语法正确后继续报配置错误。客户端的覆写、全局扩展和脚本也会参与合并，因此源订阅正确并不代表最终交给内核的配置正确。先停用个人覆写做一次对照，保留原文件以便恢复。

成功更新后确认新配置已经启用，查看策略组是否保留了有效选择，再执行一次真实请求。仅出现更新完成提示，不代表活动配置已经切换。若客户端每次重启都恢复旧内容，应检查持久化目录权限和个人覆写，而不是继续重复导入。首次建立订阅的操作主线见使用指南；本章解决的是获取与解析故障，不要求为了更新而重新安装整套客户端。

速度慢：分离延迟、吞吐与应用侧限制

先明确慢的类型：网页首次打开慢、持续下载慢、视频缓冲频繁，还是游戏响应不稳定。这几种现象不共享同一个指标。节点测速通常测量小请求的往返时间，不能代表大文件吞吐，也不能说明目标服务是否限速。固定一个真实业务目标，记录连接建立耗时和稳定传输表现，再与直连、备用节点比较。不要把每次测试都换成不同网站，否则服务端差异会掩盖线路差异。

控制变量，避免测速互相干扰

关闭正在占用带宽的同步、下载和系统更新，先单独测试一个任务。无线网络信号弱、信道拥挤或设备省电会影响本地链路；如果直连下载同样慢，应先查局域网和运营商接入。桌面设备可以用有线网络做对照，移动设备可以分别测试无线网络和移动数据。对照必须在相近时间完成，高峰期和空闲期的结果不能直接归因于某个配置字段。

确认业务流量命中的最终节点。界面上选中的节点可能只属于某个策略组，而当前网站被另一组或 DIRECT 规则接管。连接面板显示的策略链比顶部选择更可靠。自动组还可能在检测后切换出口，导致连续测试并不使用同一线路；排查阶段可临时使用手选组固定节点，完成定位后再恢复自动策略。出口频繁变化还可能触发目标服务的会话验证，表现为重试或加载缓慢。

从连接阶段识别瓶颈

域名解析等待很久但建立连接后速度正常，优先看 DNS；TCP 建连或 TLS 握手慢而下载稳定，可能是路径延迟或重传；连接建立很快但持续传输低，考虑服务端限速、线路拥堵和本地带宽。以下命令明确使用代理并输出几个时间点，适合对比同一目标。使用 HTTP CONNECT 代理时，这些时间反映的是客户端观察到的阶段，不应直接当作远端 DNS 或节点 RTT。

curl --proxy http://127.0.0.1:7890 \
  --connect-timeout 10 --max-time 30 \
  -o /dev/null -sS \
  -w 'connect=%{time_connect} tls=%{time_appconnect} first=%{time_starttransfer} total=%{time_total}\n' \
  https://example.com/

该示例使用类 Unix 终端的续行与空设备路径。Windows 可将命令写成一行，使用 curl.exe 并将 /dev/null 改为 NUL。小页面的 total 主要用于连接对照，不能代替吞吐测试。若要测试持续传输，选择来源明确、大小已知且允许测试的文件，避免并发压测公共服务；重复两三次并观察波动，单次峰值不代表日常质量。

谨慎处理 UDP、MTU 与协议差异

视频应用或浏览器可能优先使用 QUIC，它基于 UDP，实际表现取决于节点支持、网络路径和接管方式。网页走 TCP 正常而某应用不稳定时，可在该应用提供设置的情况下临时停用 QUIC作对照，但不要把停用当成所有场景的固定优化。节点协议支持 UDP，也不保证服务端或上游线路允许 UDP。日志中有没有对应流量，比协议名称更能说明实际使用路径。

TUN 下小请求正常、大请求卡住，有时与路径 MTU 或分片处理有关。先记录当前 MTU、测试不使用 TUN 的代理入口，并排除 DNS 和节点问题；只有差异稳定复现，才逐项调整相关参数。没有统一适合所有网卡、隧道和接入网络的 MTU 数值。随意同时修改栈类型、MTU 和路由设置，即使暂时恢复，也很难知道是哪一项起作用，更难在换网络后维护。

如果只有一个服务慢，检查服务地区、出口 IP 风险控制、登录状态和应用下载限制；如果所有节点都在同一时间下降，检查本地接入与服务方容量。更换出口后重建连接再比较，已有连接可能继续留在旧线路。节点选择的具体取舍见延迟、倍率、地区与协议对比，无需为速度问题先删除整份规则配置。

DNS 问题：追踪解析来源与 Fake-IP 映射

DNS 故障常表现为域名打不开、部分应用提示网络错误，或者换节点也没有变化。先检查日志是否出现解析失败，再区分目标网站域名与节点服务器域名。前者影响业务连接，后者影响代理本身能否建立。如果节点地址无法解析，继续改网站分流规则不会修复入口。还要确认应用到底使用系统 DNS、内核 DNS、浏览器安全 DNS，还是应用内置解析；它们可能同时存在。

识别系统解析和内核解析的边界

nslookup example.com 一般反映系统所选 DNS 服务的回答，不能单凭它证明 mihomo 内核解析正常。若内核单独监听了 DNS 端口，需要向那个地址和端口查询；监听在非标准端口时，可使用支持指定端口的工具。下例以本机 1053 端口为教学设置，仅在实际配置监听该端口时才成立。测试工具未安装时可优先查看内核日志和连接记录，不必为排查强行安装整套工具链。

# 查询系统默认 DNS
nslookup example.com

# 使用 dig 查询示例中的内核 DNS 监听端口
dig @127.0.0.1 -p 1053 example.com A
dig @127.0.0.1 -p 1053 example.com AAAA

系统查询正常但应用失败，应继续检查应用独立 DNS、代理路径和目标连接；内核查询失败，检查上游解析服务可达性和启动日志。直接用 HTTPS 访问 IP 地址不是可靠替代，因为证书和虚拟主机仍依赖域名。用手工写入 hosts 的方式可能暂时绕过解析，却会掩盖地址变化和分流问题；只有明确掌握地址与用途时才适合做短期对照，完成后应撤销。

正确理解 Fake-IP

Fake-IP 会返回合成地址，并由内核保存域名与地址的映射，以便后续连接恢复域名并匹配规则。看到保留地址范围的回答不一定是异常，也不能把它当作真实服务端地址写进其他设备的永久设置。如果应用获取了合成地址，但后续连接没有进入维护该映射的内核，就可能连接失败。系统代理、TUN、DNS 接管和应用缓存必须组成一致的路径，不能只开启其中一半。

以下是本机 DNS 设置的局部示例，展示监听地址、模式和上游的关系，并非通用修复配置。上游地址需要在当前网络中可达，且不应与系统转发形成循环；合并前保留完整配置。监听使用回环地址，避免为了本机排查将 DNS 服务直接暴露给整个局域网。客户端可能覆写这些项，应检查最终运行配置而不是仅看原始订阅文件。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

处理兼容例外与缓存

局域网设备发现、部分游戏或需要真实地址的程序可能不适合接收 Fake-IP。先找到具体受影响域名，再按当前内核支持的过滤配置添加最小范围例外。不要一开始把所有域名都排除，否则会改变域名映射和分流效果。局域网名称可能依赖路由器 DNS、搜索域或组播发现，并不等同于公网 DNS；切换到公网解析服务不一定能解析打印机或内部主机。

更改模式后，旧的系统缓存、浏览器缓存和应用连接可能继续使用之前的结果。Windows 可执行 ipconfig /flushdns 清理系统缓存；其他系统的清理方式取决于实际解析服务。随后重启受影响应用，并通过客户端支持的操作重新建立内核映射。不要在仍有大量旧连接时反复切换 Fake-IP 与其他模式，否则旧地址与新映射混用会让故障变得间歇且难以复现。

IPv4 可用而 IPv6 失败时，分别观察 A 与 AAAA 回答、节点支持及实际路由，不要仅凭一个开关判断。浏览器安全 DNS也可能绕开系统设置，导致浏览器与终端表现不同。排查时临时统一解析来源，验证后再决定长期配置；如果仍只有一个域名失败，检查规则目标和解析服务响应，而不是反复更换所有 DNS 参数。

系统代理不生效：按应用确认接管入口

系统代理不是全设备流量开关。它通常向读取系统代理设置的应用提供 HTTP 或 SOCKS 入口，应用是否使用、如何使用，由应用和操作系统接口共同决定。TUN 则通过虚拟网卡和路由接管进入对应路径的流量，仍受路由、排除项和权限影响。先明确需要接管的是浏览器、终端、游戏还是局域网设备，再选择检查方式，不要把两种机制当成同一个开关的不同名称。

先检查系统设置与浏览器设置

打开系统网络代理页面，核对代理地址和端口是否与客户端一致。常规本机入口通常使用 127.0.0.1，它只代表当前设备，不能让另一台设备连接这台电脑。检查是否同时启用了手动代理、自动配置脚本或其他代理工具。浏览器扩展可能覆盖系统设置，企业策略可能禁止修改，部分浏览器还使用独立代理参数。先停用相关扩展做对照，再查看目标请求是否出现在内核连接面板。

使用同一目标运行明确代理命令。如果明确代理成功、浏览器没有连接记录，通常应继续查浏览器入口；如果浏览器有记录却被分到 DIRECT，问题在规则而不是系统代理开关。若请求使用已有连接，切换设置后需要重新打开页面或重启浏览器才能形成有效对照。隐私窗口可减少扩展干扰，但不保证绕开企业策略和系统级网络软件。

终端代理需要单独设置

许多命令行工具读取环境变量，不自动读取系统代理。下面是类 Unix shell 中仅对当前会话生效的示例，端口须改为实际值。HTTPS_PROXY 中使用 HTTP 代理地址并不矛盾：工具可以通过 HTTP CONNECT 建立 HTTPS 隧道。个别工具只读取小写变量、专有配置或启动参数，因此最终仍应查工具说明，不能认为一组变量适用于所有进程。

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export NO_PROXY=localhost,127.0.0.1,::1

curl -I https://example.com

# 结束对照后撤销当前会话设置
unset HTTP_PROXY HTTPS_PROXY NO_PROXY

PowerShell 可用 $env:HTTPS_PROXY='http://127.0.0.1:7890' 设置当前进程环境，测试结束后用 Remove-Item Env:HTTPS_PROXY 移除。变量需要在启动子进程前设置，已经运行的编辑器、终端或服务不会自动获得新值。检查 NO_PROXY 是否包含目标域名或过大的匹配范围；还应留意旧的小写变量与大写变量并存，使不同程序读取了不同入口。

TUN 开启后仍要检查路由

先确认服务组件已安装、虚拟网卡已创建，并查看内核日志是否报告权限或路由写入错误。管理员授权或系统权限提示应按客户端指引完成，不要长期以关闭系统安全机制替代权限配置。其他 VPN、虚拟机网卡和企业隧道可能改变默认路由；先关闭不必要的同类工具做对照，但工作网络存在管理要求时，应遵循管理员策略，不要强行覆盖受管路由。

TUN 下访问局域网失败，检查路由排除与本地网段是否正确，而不是把所有目标统一交给代理。使用公司内部域名时，还要考虑内部 DNS 和分流隧道。系统代理与 TUN 可以在某些配置中并用，但排查初期分别测试更容易判断责任边界。若只有 UDP 应用失败，确认节点与出口支持 UDP，以及该流量是否真正进入内核；HTTP 代理本身不能作为通用 UDP 入口。

检查完成后撤销临时环境变量、恢复浏览器设置，并只保留实际需要的代理入口。更完整的浏览器与终端分线步骤见系统代理开启但不生效。如果目标已经出现在连接面板却无法打开，应转向节点或 DNS 章节，而不是继续反复点击系统代理开关。

客户端崩溃：拆分界面、内核与服务组件

客户端闪退、界面卡住和内核退出不是同一种故障。界面进程负责显示与管理，内核负责网络连接，服务组件可能负责权限和 TUN。先判断窗口是否消失、系统代理是否残留、内核进程是否仍在运行，以及日志最后记录的错误。只看到托盘图标并不能证明网络工作正常；界面打不开也不必立即认为所有配置已经损坏。保存故障时间，后续查系统事件时需要用它对齐记录。

先恢复网络，再保留证据

如果闪退后无法上网，先通过系统设置关闭残留代理，确认基础直连恢复。尽量使用客户端正常退出功能；无法操作时才结束相关进程。复制配置、订阅管理数据和个人覆写，再考虑重置。订阅地址、节点认证内容和日志中的完整 URL 可能含敏感信息，提交反馈前需脱敏。不要把清空应用数据作为第一步，因为这会同时删除故障现场和已知可用的恢复入口。

日志提示配置解析失败时，转到订阅章节；提示端口被占用时，检查是否启动了两个代理客户端或遗留内核。先确定占用者，再关闭多余实例或修改监听端口，并同步系统代理与应用设置。仅修改内核端口而不更新应用入口，会把启动错误变成新的连接失败。不要看到进程名就直接终止系统服务，企业软件和开发工具也可能合法使用相同端口。

# Windows：检查示例代理端口，输出中的 PID 用于进一步定位
netstat -ano | findstr ":7890"

# Linux：查看监听端口与可见的进程信息
ss -lntp

# macOS：检查示例 TCP 监听端口
lsof -nP -iTCP:7890 -sTCP:LISTEN

用最小变动排除配置与界面状态

如果启用某份配置就崩溃，先回到上一份可用配置，停用个人脚本、覆写和额外规则提供器做对照。不要在恢复过程中重新拉取大量资源，以免同时引入新的远端变化。若只在打开连接面板时卡顿，观察连接数量、日志等级和界面刷新开销；临时降低日志详细程度、关闭高频刷新，再比较网络是否仍正常。排查日志可以短时开启详细级别，但不应长期大量记录。

如果空闲也崩溃，检查系统磁盘空间、用户目录写入权限、安全软件拦截记录和系统事件。安装目录与数据目录可能分开，重新安装程序未必会清理损坏的用户状态。使用客户端提供的重置功能前阅读说明，确认哪些内容会被删除，并做好副本。不要随意删除整个用户目录或提升所有文件权限；针对明确被拒绝的路径修复，比扩大权限更安全且便于复核。

核对平台、架构与启动方式

安装包应与系统和处理器架构匹配。macOS 用户区分 Apple Silicon 与 Intel，Android 用户按设备 ABI 选择，Linux 用户检查发行版包格式和运行依赖。误用安装包可能表现为无法启动、服务安装失败或更新异常，而不是普通网络故障。优先从下载页选择适配包；常规用户先考虑 Clash Plus，Linux 图形桌面可按页面说明选择 Clash Verge Rev 或 FlClash。

Linux 上如果图形客户端与手工启动的 mihomo 同时运行，可能争抢端口或修改路由。使用 systemd 托管时，应确认用户、工作目录、配置路径和文件访问权限，不要一边运行桌面内核一边反复启动服务。日志应从实际负责网络的进程读取，终端中另一份测试配置的结果不代表后台服务状态。部署目录和权限关系见Linux mihomo 部署说明。

最终反馈应包含系统与架构、客户端名称、触发步骤、故障时间、是否使用 TUN，以及脱敏后的关键错误。用最少步骤稳定复现，比提交整份未经整理的日志更有帮助。Clash for Windows 与 ClashX Meta 已停止维护；若问题与新系统兼容性有关，应优先评估仍在维护的客户端，同时保留旧配置以便迁移，不要编造一个版本号来认定问题已经修复。

移动端专项：VPN 权限、后台运行与耗电

移动端需要同时检查系统 VPN 状态、客户端运行状态和实际网络。状态栏出现 VPN 标记，只能说明系统建立了某种 VPN 连接，不能证明选中的节点、DNS 和目标服务正常。先在前台连接并访问实际目标，再锁屏、切换应用和切换网络，分别记录在哪一步失效。把手机问题直接套用桌面系统代理方法，往往会遗漏权限、后台限制和网络切换这些关键条件。

Android：授权与后台限制分开检查

首次连接时完成系统 VPN 授权，确认没有另一款 VPN 占用同类通道。设备开启始终开启 VPN 或阻止未经过 VPN 的连接时，客户端停止可能导致全部流量被系统阻断；排查前记下这些选项，按使用需要做对照，再恢复原策略。不能只卸载客户端却保留相关系统设置。工作资料或受管设备的 VPN 由管理员控制，遇到限制应先确认管理要求。

前台正常、锁屏后断开时，检查电池优化、后台活动、自启动和厂商的省电管理。不同品牌入口名称不同，应针对当前客户端查系统设置。先只调整这一款应用，不必全局停用省电功能。清理工具或一键加速可能结束后台服务，最近任务中的锁定操作也不一定代替系统电池白名单。修改后锁屏一段时间再发起真实请求，确认恢复不是单纯来自重新打开应用。

按应用代理功能会改变覆盖范围：检查目标应用在包含列表还是排除列表，浏览器成功不代表游戏或聊天应用已经被接管。应用更新、工作资料和双开应用可能使用不同身份或包名，需要重新确认选择。Android 私人 DNS 也可能影响解析路径，先观察它与客户端 DNS 的关系，再临时统一来源做对照；不要因为一次失败就长期停用所有系统 DNS 功能。

iOS：检查系统 VPN 配置与隧道状态

iOS 用户可从iOS 下载入口安装 Clash Plus，官方产品站点为 clashplus.io。首次使用按系统提示允许添加 VPN 配置，连接后同时检查应用中的隧道状态和系统 VPN 设置。其他 VPN 配置、受管网络策略或已有隧道可能影响连接，先停用不需要的同类连接做对照；不能用重装应用替代系统权限检查。

iOS 的网络隧道与普通应用界面具有不同的运行机制，界面进入后台不必然代表代理停止；同样，允许后台 App 刷新也不能保证隧道始终工作。若返回应用后才恢复，记录系统 VPN 是否已经断开、是否发生网络切换，以及日志有没有重新建立隧道。不要反复强制结束应用作为保活方法，先通过正常断开与重连验证，必要时重启设备清理异常隧道状态。

网络切换与热点使用的边界

无线网络切换到移动数据后，旧 TCP 会话可能中断，DNS 和默认路由也可能变化。先等待客户端完成重连，再关闭失败页面或重启业务连接。公共无线网络先处理认证门户，漫游环境还应检查数据服务本身是否可用。手机开启 VPN 不代表热点连接的电脑自动经过同一隧道，系统对转发流量的处理不同；热点设备应独立验证入口，不要只看手机的 VPN 标记。

耗电排查从重复工作开始

高频节点测速、规则集更新、详细日志和不断失败重连都可能增加耗电。先减少不必要的周期任务，保留稳定节点，再比较相似使用时段的电量与温度。后台流量可能来自系统同步和业务应用，不应全部归因于代理。只统计一小段空闲时间容易受信号强度和充电状态影响，应结合系统电池页面与客户端日志判断。具体设置取舍见手机端耗电与后台策略。

完成排查后恢复临时修改的电池、DNS 和 VPN 设置，保留能够复现问题的最小记录。需要迁移客户端时先保存订阅来源和个人规则，再按使用指南重新导入，不要把旧应用的全部内部数据直接复制到另一款客户端。问题仍存在时，返回对应的节点、DNS 或代理入口章节，移动端限制只是链路的一部分，不应替代对远端服务的验证。