Clash 故障排查大全

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

确认断网发生在哪一层

先关闭系统代理和 TUN 模式，再访问平时可以直连的网站。若仍然失败，检查无线网络是否需要网页登录、网线是否接通，以及操作系统是否获得有效网关。此时问题还没有进入 Clash 的处理范围。公共网络的认证页面通常应在直连状态完成；认证通过后，再恢复客户端并重复测试。

直连正常而开启代理后失败，下一步检查内核状态，不要只看托盘图标是否存在。进入客户端的日志页，确认配置已加载、监听端口已建立，且没有持续出现解析配置失败、地址被占用或启动后立即退出。界面进程与 mihomo 内核是两层，窗口能够打开不代表本地代理服务已经运行。

在设置中找到实际的混合端口。下面以本地端口 7890 为例，测试前应替换为正在使用的数值。命令直接指定代理，绕过浏览器是否读取系统设置这一变量。Windows 使用 curl.exe，避免某些 PowerShell 环境把 curl 解释为其他命令。

curl.exe -I --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:7890 https://example.com/

如果提示无法连接到本地地址，重点检查监听端口、内核状态及本机安全软件的拦截记录。如果已连接本地代理，随后才出现超时，则继续检查策略组和远端连接。若能收到 HTTP 响应头，即使状态码不是成功，也说明请求已经推进到服务端响应阶段，不能再笼统归类为本地代理未启动。

用日志判断规则与策略组

把模式切到“规则”，打开代理页，确认命中的策略组内已经选择一个可用出口。某些配置把业务分到多个组，只修改默认组不会改变其他组的去向。访问目标一次，然后在连接页或日志中查找对应域名，核对规则类型、策略组和最终策略；不要用其他网站的成功结果代替这条请求的证据。

rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

这段示例要求配置中已经存在名为 Proxy 的代理或策略组，不能单独作为完整配置导入。规则从上到下判断，先命中即停止；若目标在更前面命中了拒绝规则或直连规则，末尾的 MATCH 不会重新接管。修改时只调整目标对应的一条规则，保留原有顺序供回退。

可以短暂切到“全局”做对照，但应同时在全局策略组选择出口。全局正常、规则失败，通常把范围缩小到规则、业务策略组或相关 DNS 行为；两种模式都失败，则优先检查共同使用的本地监听和出口。完成对照后恢复规则模式，避免把临时诊断设置当作长期解决办法。

清理冲突后验证恢复

排查期间只保留一个接管网络的工具。其他 VPN、浏览器代理扩展、旧代理客户端和抓包工具可能同时改写入口。先逐个退出并复测，不要直接卸载网卡或重置整套网络。客户端退出后仍无法直连时，检查系统中是否遗留指向本地端口的代理设置；服务已经停止而入口仍保留，就会形成看似全机断网的状态。

恢复后分别验证一个直连目标、一个代理目标，并查看两者是否命中预期策略。网页打开只是结果，日志中的连接入口和规则去向才是定位依据。若仅浏览器失败而命令测试正常，转到系统代理章节；若错误集中在域名解析，则按DNS 章节继续，不必重新执行全部步骤。

节点超时：区分端口、握手与目标请求

先读错误发生的阶段

“超时”是等待超过期限的结果，不是单一原因。客户端连不上节点服务器、协议握手迟迟没有完成、出口连接目标失败，都可能显示类似提示。保留完整错误上下文，尤其关注服务器地址、连接方式以及错误发生在拨号、TLS 还是读取响应阶段。只截取最后两个字，会丢掉最有价值的线索。

先判断影响范围：同一个节点访问所有目标都失败，还是只有某个站点失败；同一份订阅内其他节点是否正常；换手机热点后是否恢复。每次对照尽量只换一个条件。若所有节点仅在某个无线网络失败，优先考虑该网络的访问限制、认证状态或出口策略，而不是同时修改每个节点的协议参数。

确认客户端实际使用的是当前订阅，而不是旧配置中的同名节点。在配置页选中目标配置，再回到策略组重新确认选择。有些组采用自动选择或故障转移策略，测试开始后最终出口可能变化；应以日志中最终使用的策略为准，而不是只看列表中某个节点的单次检测结果。

检查服务器地址和 TCP 可达性

Windows 可以使用 Test-NetConnection 检查服务器的 TCP 端口。下面的保留示例地址仅用于展示命令结构，实际测试须填写配置中的服务器和端口，不能直接拿示例结果判断服务状态。该测试不验证代理密码、协议参数或 UDP 可用性，只能说明一次 TCP 建连是否成功。

Test-NetConnection -ComputerName 192.0.2.10 -Port 443

TCP 不通时，核对服务器是否维护、订阅是否已更新、本地防火墙是否阻止进程，以及当前网络是否限制相应端口。能够连接也不代表代理一定可用：错误的密码、传输路径、TLS 服务器名称或协议选项仍会导致握手失败。由订阅管理的节点优先重新更新，不要凭猜测逐个修改认证字段。

如果日志显示证书验证失败，先同步系统日期、时区和时间，再确认节点域名与证书配置。不要把关闭证书验证当作通用修复；它会掩盖服务端配置错误及连接被干预的风险。网页端证书警告还可能涉及系统信任链，具体检查顺序见HTTPS 证书报错原因分析。

以域名填写的服务器还依赖启动阶段的 DNS。若服务器域名本身解析失败，远端连接尚未开始；更换目标网站无法验证这一层。查看错误中被解析的是节点域名还是访问域名。前者应检查直连可达的引导解析路径，后者则进入 DNS 与分流配置检查，二者不能混为同一个设置项。

把检测结果与实际业务分开

节点列表中的检测通常只请求指定测试地址。测试地址被阻断、响应方式不同或不适合当前网络时，会产生误判；反过来，检测成功也不保证视频、游戏和所有网页都正常。先用一个普通 HTTPS 请求测试，再换实际目标，观察失败是否只集中在特定服务。不要根据一次检测就批量删除全部节点。

游戏和通话还可能依赖 UDP。网页能打开、实时业务失败时，检查节点协议和服务端是否支持所需传输，以及客户端接管方式是否覆盖该应用。TCP 端口测试不能替代 UDP 测试，浏览器测速也不能证明 UDP 路径正常。若服务端能力未知，应向订阅提供方确认，而不是在本地反复切换开关。

持续重连会制造大量重复日志，反而难以观察最早的错误。暂停自动检测，选定一个出口，记录一次完整连接过程，再用另一个已知可用出口对照。如果新出口正常，保留旧节点的失败阶段与测试时间，交由服务提供方排查；若全部出口表现一致，则回到本机网络、DNS 或客户端入口这一共同层面。

最终恢复标准应是实际请求稳定完成，而不是检测按钮变为成功。验证后恢复原先的自动选择设置，并检查是否仍在使用临时全局模式。经常重复出现同一故障时，保留发生网络、节点类型和错误阶段这三项记录，后续更容易识别是网络环境变化、订阅更新滞后，还是某个出口长期不可用。

订阅失败：检查下载路径与配置解析

区分获取失败与导入失败

订阅更新分成获取内容和解析配置两个阶段。请求超时、连接被拒绝、HTTP 状态异常，属于获取阶段；内容已返回但提示 YAML 错误、字段类型错误或策略引用不存在，属于解析阶段。先在配置页查看更新错误，再找同一时间的日志。只反复点击更新，通常不会改变请求路径，也无法修复语法错误。

核对订阅链接是否完整，复制时有没有遗漏末尾参数、带入空格或换行。订阅 URL 往往带有账号访问凭据，不要贴到公开论坛、在线转换页面或截图中。需要求助时只保留域名、状态码和报错类型，隐藏路径中的私人标识。若链接已公开，应在服务端重新生成，而不只是删除已经发出的消息。

网页能打开服务商主页，不代表订阅接口同样可达。主页与订阅可能使用不同域名、访问控制或内容分发路径；还可能一个返回网页，另一个需要有效凭据。遇到未授权、禁止访问或请求过于频繁等响应，按服务方说明检查账号状态与更新频率，不要通过高频重试尝试绕过限制。

处理订阅更新的网络依赖

订阅域名若必须经代理访问，而当前配置没有可用节点，就会出现先有代理才能更新、先更新才能取得代理的循环。可切换到另一份已知可用配置，或使用能直连该接口的网络，再执行更新。不同客户端对订阅下载是否走代理的设置不同，应核对配置页相关选项，不要假定系统代理一定影响内核发起的请求。

更新后先检查节点与策略组是否出现，再确认当前使用的是刚刚更新的配置。有些客户端支持多份配置并存，下载成功不一定会自动切换。若日志显示仍在使用旧服务器，检查配置选择状态、远程代理集合的刷新情况以及覆写规则是否保留了旧地址，避免把选择问题误判为缓存没有清除。

返回内容如果是登录页面、访问验证页或普通错误说明，文件即使保存成 YAML 扩展名也不能直接导入。解析器报错处可能只是网页中的某个符号，而不是订阅原本的规则有误。使用可信的本地文本工具检查文件开头与结构即可，不要把含账号信息的完整配置上传到公共语法检查服务。

定位 YAML 与引用错误

YAML 的缩进应使用空格，同层键名保持对齐。常见问题包括冒号后缺少空格、复制混入全角符号，以及把列表写成普通字符串。报错行号通常指向解析器发现冲突的位置，真正原因也可能在上一行。先检查附近几行和所属层级，不要为了消除报错而随意删除整个代理组。

proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - MATCH,DIRECT

这是一段结构说明，策略组暂时只包含 DIRECT，用于演示名称引用，不提供远端代理能力。规则里的 Proxy 必须与组名完全一致。远程代理集合与规则集合也要有对应定义；拼写、大小写或覆写操作导致名称变化时，下载成功的配置仍可能无法加载。

若客户端提供配置检查功能，先运行检查，再启用。命令行用户可在配置所在目录执行下方命令；配置含相对路径时，应使用实际工作目录。检查通过表示配置能够被该内核读取，并不证明所有远端节点都可连接，也不保证规则符合业务需求。

mihomo -t -f config.yaml

订阅本身正常而启用后失败时，临时关闭本地覆写、合并脚本或扩展配置，再加载原始订阅做对照。原始内容可用，说明问题更可能在二次修改层。逐项恢复修改，找到引入错误的那一项；不要直接覆盖唯一备份。跨设备同步时，还要确认不同客户端是否支持同样的覆写形式，参见多设备配置同步方案。

长期处理原则是把服务商提供的远端内容与本地个性化规则分开保存。更新失败时保留上一份可用配置，确认新配置加载成功后再切换。若订阅持续返回服务端错误，应提供已脱敏的状态码、发生时间和客户端名称给服务方，而不是重装系统或清空全部应用数据。

速度慢：按解析、连接与传输分段定位

先定义变慢的具体表现

首次打开网页等待很久、网页开始后加载缓慢、大文件传输忽快忽慢，是不同阶段的问题。先记录慢在开始之前还是传输过程中，并对同一目标连续测试。首次慢、再次快，可能与 DNS、连接建立或应用缓存有关；整个传输持续慢，才更适合继续观察无线信号、出口线路和服务端速率限制。

测速时固定设备、网络、目标和策略组选择，暂停系统更新、云盘同步及其他大流量任务。无线网络应先检查信号质量，必要时用有线网络对照。手机热点也可作为隔离本地宽带问题的辅助，但它同时改变运营商路径，结果只能缩小范围，不能单独证明某个节点或客户端有故障。

先看日志中的最终策略，确认慢请求确实经过计划中的出口。某个站点被规则分到另一个策略组，调整默认组不会改变它的速度。对于带有多个资源域名的网页，应观察主要文档与静态资源是否走向不同；页面主体很快但图片迟迟不出，可能只是其中一个资源域名的规则或远端连接异常。

使用时间分段，而非只看检测值

下面的命令输出请求过程的累计时间，用于同一环境下前后对照。Windows 使用 curl.exe，macOS 和 Linux 可改用 curl。代理端口按实际设置替换。经 HTTP 代理访问 HTTPS 时，域名可能交由代理侧解析，因此本地解析时间不等同于目标站点的完整 DNS 耗时。

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

这些数值从请求开始累计，不是彼此独立的耗时。连接阶段快、首字节等待长，可能涉及代理握手、远端建连或服务端处理；总时长增加还可能只是内容更多。macOS 和 Linux 把输出文件 NUL 改为 /dev/null。不要直接拿不同网页的总耗时比较线路质量，因为响应体和服务端行为并不一致。

节点检测关注一个小请求是否及时完成，不能直接代表下载带宽。线路也可能对单连接与多连接采用不同策略，浏览器下载、在线视频和测速工具未必得到相同结果。应选取有权访问的同一资源进行重复测试，再对照另一个出口；不要为了得到好看的检测结果频繁修改内核超时参数。

排除协议、路由和接管方式差异

只在 TUN 模式变慢时，先确认没有同时运行另一个 VPN，再检查日志中是否存在路由重复接管或连接循环。用系统代理做短时对照，可以区分应用入口与出口线路。若系统代理正常、TUN 异常，不应立即更换全部节点；先检查虚拟网卡、DNS 接管和网卡选择，尤其是安装了虚拟机或容器网络的设备。

某些应用优先使用基于 UDP 的传输。当前出口不支持相关流量时，可能在等待失败后才回退到 TCP，表现为开始阶段卡顿。可以在可控测试中临时关闭应用的相关传输选项，观察是否恢复，但应记录改动并在测试后复原。不要因此全局封禁 UDP，否则通话、游戏和其他业务可能受影响。

MTU 不匹配也可能造成小请求正常、大数据传输停滞，但它不是所有卡顿的默认解释。只有在特定网络或 TUN 路径稳定复现、其他入口正常时，才进一步检查。按客户端和网络环境的说明小范围调整，并保留原值；随机降低数值会增加包数量，也可能掩盖真正的链路或服务端问题。

长期运行后才变慢，应检查连接页是否积累了大量异常重连、调试日志是否持续写盘，以及设备是否处于省电或过热降频状态。先结束产生异常请求的应用，再观察客户端资源是否回落。高日志级别适合短时定位，不适合一直开启；磁盘写入与界面渲染开销也会影响低配置设备的体验。

处理结束后，用同一目标、同一网络和相同入口复测，比较是否消除了原本的等待阶段。若只有某个站点持续慢而其他服务正常，保留其域名、命中策略和时间范围，转向目标服务或出口路径排查。不要把一个站点的拥塞解释成整个客户端的性能问题，也不要根据单次测试承诺固定速度。

DNS 问题：核对解析路径与 Fake-IP 映射

先确认解析请求由谁处理

日志中的域名解析失败，需要先分清发生在操作系统、浏览器、mihomo 还是节点服务端。系统查询成功，不代表内核使用的上游正常；浏览器开启独立安全 DNS 后，也可能绕开系统解析路径。检查当前接管方式及 DNS 配置，再选对应工具测试，避免用一个层面的结果证明另一个层面正常。

先看错误指向的域名。节点服务器域名无法解析，会阻止代理链路建立；访问网站的域名无法解析，则可能发生在链路已启动之后。如果使用加密 DNS，上游解析器的主机名也可能需要先解析。把这三类名称区分清楚，才能判断是引导解析、代理服务器解析还是普通目标解析出现了依赖循环。

Windows 可用 Resolve-DnsName example.com 检查系统路径，macOS 和 Linux 可使用 nslookup example.com。测试指定 DNS 服务器前，要确认其地址与监听端口；系统工具通常默认访问标准 DNS 端口，不能直接拿来测试任意本地监听。命令成功只说明这条查询获得响应，仍需回到客户端日志核对实际请求。

理解 Fake-IP 的正常表现

Fake-IP 模式可能返回保留地址段中的映射地址，这是内核把域名关联到连接的一种方式，并不自动表示解析被污染。关键在于接下来发往该映射地址的连接是否仍进入同一内核。若 DNS 由客户端处理、连接却绕开客户端，应用就可能访问一个本来只在映射表中有意义的地址，从而失败。

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

这段是 DNS 局部配置示意，需要并入已有配置，且不应重复声明顶层 dns。两个上游地址只是可替换的示例，应依据所在网络的可达性选择。本地监听在回环地址的非标准端口，不会自动修改系统 DNS；是否接管系统查询，还取决于客户端设置、TUN 和具体平台，不要导入后假定所有应用都已切换。

局域网打印机、投屏设备和依赖真实地址的应用，可能需要通过 fake-ip-filter 排除特定名称。但应先确认这些名称实际如何解析、使用哪个本地 DNS，再添加必要范围。把所有域名都排除会改变整个模式的行为，难以继续对照。原理与过滤边界见Fake-IP 模式详解。

处理缓存与加密解析的依赖

更换 DNS 模式后，操作系统和浏览器仍可能缓存旧地址，应用也可能复用旧连接。按“保存配置、重新加载内核、关闭目标应用、清理必要缓存、重新测试”的顺序操作。Windows 可执行下方命令清理系统 DNS 缓存；它不会清除浏览器独立缓存，也不能修复服务器返回的错误结果。

ipconfig /flushdns

不要同时清空客户端所有配置与缓存。若只是 Fake-IP 映射与旧连接不一致，重启相关应用并重建映射通常比删除整个数据目录更有针对性。若问题在睡眠唤醒后出现，先检查网络是否更换、虚拟接口是否恢复，以及旧连接是否仍绑定原网络，再判断是否需要重新启动内核。

使用 DoH 或 DoT 时，应检查上游地址是否可达、证书是否有效，以及上游自身是否被规则送入尚未建立的代理。加密并不意味着自动可靠；在当前网络无法建立连接时，查询仍然失败。排查可先用明确可达的普通上游作对照，确认问题层级，再恢复原先的加密解析方案，而不是长期随意替换。

仅 IPv6 环境或双栈网络出现异常时，观察日志里选择的是 IPv4 还是 IPv6 地址，并与本机实际路由能力对照。系统获得 IPv6 地址，不代表每个出口都具备对应连通性。可以在一次受控测试中调整 IPv6 相关设置定位，但不要直接把关闭 IPv6 当作所有解析问题的固定步骤。

修复完成后，重新访问一个此前失败的域名和一个局域网目标，确认公网分流与本地发现没有互相影响。必要时记录系统 DNS、内核上游和浏览器独立 DNS 三者的设置，保持责任边界清晰。若只有某个域名返回异常，优先核对权威解析与规则，不必扩大为整机 DNS 重置。

系统代理不生效：检查应用入口与端口类型

系统代理并不覆盖所有连接

系统代理是向愿意读取该设置的应用提供代理地址，不是强制接管全部网络。浏览器、命令行工具、商店应用和游戏使用的网络库不同，行为也可能不同。网页正常而某个应用仍然直连时，先检查该应用是否支持系统代理、是否有独立代理设置，再决定是否使用 TUN，不要先改动已经正常工作的订阅。

确认代理地址指向当前设备的回环地址，端口与客户端设置一致。HTTP 端口、SOCKS 端口和混合端口不能随意互换；向只接收 SOCKS 的端口发送 HTTP 代理请求，可能表现为连接被关闭或协议错误。若客户端启用了混合端口，可用同一个监听接受相应代理协议，但应用端仍需选择正确类型。

先用显式指定代理的命令验证，再与不指定代理的应用访问对照。显式请求成功而浏览器失败，重点查浏览器扩展、独立代理、系统代理读取和绕过列表。两者都失败，则回到本地监听或节点链路。这样可以避免把“应用没有进入客户端”和“进入后无法转发”混在一起。

按平台检查实际设置

Windows 中，netsh winhttp show proxy 可以查看 WinHTTP 代理状态，但它不是浏览器用户代理设置的完整镜像。不要因为显示直连就断定客户端的系统代理没有启用，也不要为修复单个应用直接导入整套设置。先确认应用使用的网络栈，再按该应用文档配置，尤其是以服务身份运行的程序。

macOS 切换无线、有线或其他网络服务后，应确认客户端更新的是当前活动服务。若使用自动代理配置脚本，还要检查它是否与手动 HTTP、HTTPS 或 SOCKS 设置重叠。工作设备可能受管理策略控制，界面中保存的值会被重新覆盖；这类情况应与设备管理方确认，避免反复强制修改。

Linux 命令行程序常读取 http_proxy、https_proxy 和 no_proxy 等环境变量，但具体支持方式由程序决定。新变量通常只影响从该终端启动的进程，不会自动改变已运行的应用。需要临时验证时，给单条命令指定代理更容易回退，不必先修改整个会话或系统配置。

curl --proxy socks5h://127.0.0.1:7890 --connect-timeout 10 --max-time 20 https://example.com/

socks5h 表示让代理侧处理目标域名解析，适合区分本地 DNS 影响，但前提是该端口确实接受 SOCKS 请求。若改为让本地解析，测试路径就不同。记录命令中的协议和解析位置，后续比较结果时保持一致；只看“同样用了端口”不足以证明两次测试条件相同。

识别绕过与沙箱限制

检查系统或应用的绕过列表。目标若命中局域网、特定域名或自动配置脚本中的直连条件，就不会按预期进入代理。先针对目标精确调整，不要清空全部绕过设置，否则本地服务和办公资源可能受影响。浏览器扩展也能接管代理决策，排查期间可临时停用扩展，以系统设置作为单一入口。

部分 Windows UWP 应用还涉及本地回环访问限制：代理监听正常，应用却无法连接回环地址。可参考UWP 回环限制处理方法，按目标应用处理豁免，或在适用环境使用 TUN。不要对所有应用批量开放权限，也不要把这个平台特有问题套到普通桌面程序上。

决定使用 TUN 前，先关闭冲突的 VPN，并确认客户端要求的服务或权限已经就绪。TUN 改变的是接管方式，不能修复失效节点或错误订阅。验证完成后检查系统代理是否仍有必要同时启用，记录最终组合。基础入口设置可对照系统代理上手步骤，后续以日志是否出现目标连接作为生效证据。

客户端崩溃：分离界面、内核与配置数据

确认退出的是哪个进程

窗口关闭、托盘消失和网络中断不一定由同一个进程引起。先查看任务管理器或活动监视器，判断界面进程是否仍在、mihomo 内核是否反复启动，以及退出前有无错误提示。界面无响应但代理仍可用，重点检查渲染与应用数据；界面正常而代理停止，则优先检查内核日志和配置加载过程。

记录触发步骤，例如启动即退出、切换配置后退出、开启 TUN 后退出，或睡眠唤醒后异常。能稳定复现的最短步骤比长时间的随机使用记录更有价值。先复制退出前后的日志到独立文件，再进行重启；频繁启动可能覆盖日志，清理应用数据则会直接丢失诊断线索。

同时检查操作系统事件记录、可用磁盘空间和安全软件拦截历史。磁盘写满、目录不可写或内核文件被隔离，都可能表现为启动失败。不要直接关闭全部安全防护；先确认被拦截的具体文件与下载来源，再按安全软件和客户端文档处理。工作设备上的策略限制应由管理方协助核对。

检查安装包与运行环境

安装包应与操作系统及 CPU 架构匹配。Windows、macOS 的不同架构，以及 Linux 的软件包格式，不应只凭文件名相似就混用。优先从客户端下载页选择对应平台，普通用户可先使用 Clash Plus。Linux 用户还需核对发行版依赖、图形会话和软件包管理器返回的具体错误，而不是直接替换系统库。

升级后出现异常时，先退出所有旧进程，避免旧界面连接新内核，或多个实例竞争端口。便携目录、系统安装目录与自动启动项也可能各自保留副本。确认当前进程的实际路径，再决定清理哪一份。不要直接删除名称相近的目录，里面可能包含仍在使用的配置与备份。

日志出现地址占用时，先查占用者，再决定是否换端口。Windows 可执行下面的命令，端口按实际监听值替换。输出中包含的进程编号需要到任务管理器核对；不要看到占用就强制结束未知进程，它可能是仍在工作的另一实例或其他本地服务。

netstat -ano | findstr :7890

如果确认是另一套代理工具，正常退出后再启动当前客户端。改端口也要同步更新系统代理、应用独立代理及相关脚本，否则内核启动恢复了，应用仍向旧地址发送请求。控制接口端口与流量代理端口的用途不同，不能因为数值接近就互换；不要把控制接口开放到不可信网络。

用最小变更定位配置问题

只有特定配置会触发退出时，先关闭本地覆写与脚本，再对原始内容执行配置检查。自定义规则集合过大、远程集合重复加载、脚本持续报错，可能增加启动和内存压力。逐项恢复扩展，观察是哪一项引入问题。直接改用另一份庞大配置无法形成有效对照，也不能证明内核本身有缺陷。

需要测试全新应用状态时，先导出订阅信息、覆写规则与策略选择，并把原数据目录备份到独立位置。按客户端文档暂时移开原目录，再启动测试；不要在不清楚目录用途时执行递归删除。新状态可运行只说明故障与原数据有关，仍应逐步恢复以确定具体文件，而不是永远丢弃原设置。

若问题只在开启 TUN 时发生，检查服务权限、虚拟接口和其他 VPN 驱动，不要直接重装整个应用。若只在打开日志页时界面卡住，可先降低日志量、关闭大量重复请求，再观察。两类现象对应不同组件；把完整流程写清楚，有助于维护者判断是否需要界面日志或内核日志。

最终测试应包含冷启动、加载配置、发起一次请求和正常退出，必要时再验证睡眠恢复。归档客户端名称、系统架构、触发操作与已脱敏错误，不编造版本信息；实际版本可从“关于”页面读取。仍需更换客户端时，先保留原数据，参见客户端横向评测理解界面、接管方式和配置兼容性的差别。

移动端专项：VPN 权限、后台限制与网络切换

先检查系统 VPN 接管状态

手机上的客户端通常依赖系统 VPN 接口接管应用流量。首次启动需要确认系统授权，状态图标出现只说明接口已建立，不表示远端节点已经连通。打开客户端日志，再从目标应用发起请求，确认连接是否进入内核并命中预期策略。若没有对应记录，优先检查接管范围与应用排除设置。

排查时只启用一个 VPN 类服务。企业 VPN、基于本地 VPN 的过滤工具及其他代理应用，可能争用系统接口；后启动的服务会导致前一个失效。若设备受工作资料或管理策略控制，还要区分个人空间与工作空间，某一空间的应用不一定使用另一空间建立的网络路径。

Android 可先选 Clash Plus，也可根据需求使用 Clash Meta for Android、FlClash 或 Surfboard；配置支持范围与菜单并不完全相同。iOS 可在iOS 下载入口查看 Clash Plus，官网为 clashplus.io。不要把桌面端专有的服务模式或系统代理步骤直接套到手机上。

Android 后台与分应用代理

亮屏正常、锁屏后中断，先检查电池优化、后台活动限制和厂商自启动管理。按需要允许客户端在后台运行，再观察是否仍被终止。系统省电设置通常分散在应用信息、电池管理和后台启动页面，名称可能不同；不要为解决一个客户端问题把所有应用都设为不受限制。

启用“始终开启 VPN”或阻止未经过 VPN 的连接后，客户端一旦停止，系统可能继续阻止网络，这是预期的保护行为之一。排查时记下原设置，临时关闭相应限制做对照；修复完成后按需要恢复。若只退出应用而没有检查系统状态，容易把这一结果误认为无线网络本身故障。

只代理部分应用时，核对当前采用的是包含列表还是排除列表。列表方向选反，会让目标应用始终直连；新安装的应用是否自动加入，也取决于客户端行为。修改范围后关闭目标应用并重新打开，避免已有连接继续沿用旧路径。浏览器与应用内网页可能属于不同进程，应分别验证。

应用自身还可能使用独立 DNS、专用协议或直接连接固定地址。一个浏览器可用不能证明所有应用已被接管。先在日志里查找目标请求，再判断是入口缺失、规则错误还是出口不支持。Android 的基础导入与启用流程可对照Android 上手步骤，不要在故障状态下反复重新导入相同配置。

iOS 与网络切换后的恢复

iOS 上先确认系统 VPN 配置属于正在使用的客户端，关闭其他可能自动连接的 VPN，再启动当前连接。若系统设置中的状态与客户端不同步，正常停止连接后重启应用，重新授权时核对应用名称。不要随意删除企业管理配置；涉及组织设备的网络要求，应先确认其管理边界。

从无线切到蜂窝网络后，旧连接可能仍绑定原来的路径。先等待系统完成切换，再在客户端重新连接，并关闭目标应用重试。如果只在蜂窝网络失败，检查客户端及目标应用的蜂窝数据权限、运营商网络限制和当前节点传输方式。网络切换会同时改变 DNS、地址族和路由，不能只归因于节点失效。

酒店和机场无线网络需要网页登录时，可先停止代理完成认证，再恢复连接。若系统设为必须通过 VPN 才允许通信，认证页面可能无法出现，应暂时调整该限制并记录。完成认证后访问普通页面确认直连恢复，再验证代理；不要在认证未完成时频繁修改订阅或 DNS，否则问题层次会被混淆。

手机可以联网而热点共享设备不能使用同一路径，也不一定是故障。操作系统未必把共享网络流量送入本机 VPN，部分客户端也不提供这种能力。不要仅凭手机上的成功结果承诺热点设备已被代理。需要局域网显式代理时，先确认客户端支持、监听范围和访问控制，并只在可信网络中启用。

移动端修复后，分别验证亮屏、锁屏恢复以及无线与蜂窝切换，查看目标应用是否继续命中预期规则。若仅某个场景失败，记录该场景与系统限制，而不是每次都重装客户端。常见按钮与日志字段可结合客户端界面速览核对；回到日常使用前，恢复临时关闭的安全设置并保留可用配置备份。