Clash 故障排查手册

无法上网：区分基础网络与代理链路

先验证关闭代理后的网络

所有网页都打不开时，先退出当前连接状态，而不是连续切换节点。关闭客户端的系统代理与 TUN 模式，再查看操作系统代理设置是否已经恢复。如果客户端异常退出，开关画面消失不代表系统代理已撤销。确认浏览器没有单独启用代理扩展，再访问日常能够直接连接的网站，同时检查无线网络是否需要网页登录。

关闭代理后仍然失败，优先处理路由器、网络认证、地址获取或其他 VPN 的残留设置。可以用同一设备切换手机热点，保持客户端配置不变：热点正常而原网络异常，说明问题与原网络环境有关。不要把网络图标显示已连接当成互联网可用的证据；它通常只能证明设备已经接入局域网。

用显式代理请求划分故障层

基础网络正常后，启动内核，暂时关闭 TUN，只保留一个本地代理入口。下例假设实际混合端口为 7890。Windows 使用 curl.exe，避免部分 PowerShell 环境将 curl 解释成其他命令；macOS 与 Linux 可使用 curl。命令中的端口必须与客户端运行设置一致。

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

连接被拒绝通常说明本机没有进程监听该端口，或客户端启动内核失败。已经连接本地代理、随后出现上游连接错误，应转到节点章节。收到目标服务器的 HTTP 响应，即使状态是拒绝访问，也说明这次请求已经走到远端，不能再简单归类为本地代理未工作。这个测试只代表该地址与该次请求，不证明所有网站都可用。

观察连接记录中的入口与出口

打开客户端连接页，清理筛选条件，然后在浏览器重新加载一个页面。如果没有新连接，检查应用是否实际使用了代理、是否命中绕过列表，以及本地端口是否填错。如果有连接，依次查看目标域名、匹配规则、策略组和最终出口。策略组名称只是中间选择器；必须继续展开到实际节点，才能知道请求最终发往哪里。

规则模式下只有部分网站失败，往往与规则匹配、DNS 或网站本身有关。临时切到全局模式测试时，应确认全局策略组也已选中可用出口，而不是仍指向直连。若全局正常、规则失败，比较两次请求的匹配结果，修正具体规则后再恢复规则模式。三种模式的流量差异可参照规则、全局与直连模式对照。

恢复时避免叠加多套接管方式

系统代理、应用内代理和 TUN 同时启用，不一定构成错误，但会增加定位成本。先用单一入口建立成功基线，再逐项恢复原设置。尤其不要让代理节点域名的连接又被另一套 VPN 接管，或把上游代理指回同一个本地端口。出现循环转发时，日志可能密集重复连接，却始终没有目标网站响应。

最后用两个不同网站、一个浏览器和一个命令行请求复测。若只有单个网站失败，停止修改全局网络，转查该站规则、证书、账户限制或服务状态。若退出客户端后网络再次中断，检查系统是否仍指向本地代理；若重新启用 TUN 才复现，则把排查重点移到路由、DNS 接管和权限，而不是重新导入订阅。

节点超时：检查解析、连接与握手

先确认超时发生在哪一步

节点超时不是单一故障。客户端可能无法解析服务器域名，也可能已经拿到地址但无法建立传输连接，或者连接成功后在加密握手阶段失败。先手动选中一个节点，关闭自动切换带来的干扰，发起一次真实访问，再查看同一时间段的日志。只有测速列表显示失败、真实网页却能访问，不能直接判定节点失效。

日志出现域名解析失败时，先处理节点服务器自身的 DNS。出现连接拒绝，常见于端口没有服务或被主动拒绝；连接超时则可能涉及链路丢弃、防火墙或服务不可达。证书验证、认证失败、协议不支持属于另一层问题。保留完整错误类型，不要只截取末尾的 timeout，否则会丢掉定位依据。

验证服务器端口，不把探测当结论

节点地址和端口应从自己的有效配置中读取，不要向公共查询网站提交。Windows 可以在 PowerShell 使用下面的交互命令输入地址与端口；输入内容不写入网页示例。该命令只测试 TCP 连接，不验证代理协议、账号、TLS 或 UDP 服务，适用于先排除明显的 TCP 不可达问题。

$server = Read-Host "输入节点服务器域名或地址"
$port = [int](Read-Host "输入节点端口")
Test-NetConnection -ComputerName $server -Port $port

基于 UDP 的协议不能用 TCP 测试结果判断好坏。即使 TCP 探测成功，也可能连到了错误服务。相反，服务器可能拒绝 ICMP，因此 ping 不通不等于代理端口不可用。遇到节点域名返回多个地址时，还要看客户端实际连接的是哪个地址；IPv4 与 IPv6 的可达性可能不同，另一设备的成功结果未必使用同一条路径。

按协议检查认证与时间

订阅刚更新后个别节点失败，先核对订阅是否已经应用到当前配置，而不只是下载成功。密码、用户标识、加密方法、传输类型与 TLS 参数必须与服务端一致。不要根据网络文章随意更换字段，也不要把一种协议的字段复制进另一种协议。客户端能够导入配置，只能证明它接受了文件结构，不能证明服务端认可认证信息。

系统日期、时区或时间同步异常可能造成证书尚未生效、已经过期等报错。恢复自动校时后重新建立连接。不要通过关闭证书验证长期绕过故障；这会掩盖域名、证书或中间网络的问题。配置中的服务器域名与 TLS 服务名可能不同，是否允许修改应以服务提供方说明为准，直接换成 IP 也可能破坏原有握手条件。

用交叉测试缩小责任范围

按照同一节点换网络、同一网络换节点、同一配置换受支持客户端的顺序测试，每次只改变一个条件。原网络全部失败而热点正常，重点检查出口网络限制、UDP 可用性与 IPv6 路径。只有一个节点在所有环境失败，优先联系服务提供方。所有节点在一台设备失败、另一台正常，则检查本机安全软件、时间和内核兼容性。

自动选择策略组可能根据健康检查结果暂时排除节点。先查看健康检查地址是否能代表实际用途，再检查测试走向。测试地址本身被限制时，可能造成一批正常节点都显示异常。不要把检测间隔调到极短来求恢复；频繁检测会增加请求量，也无法修复服务端故障。确认一个节点真实可用后，再恢复自动选择。

订阅失败：区分下载、解析与应用

先判断失败发生在获取还是解析

订阅导入包含获取远程内容、解析格式、生成运行配置和应用配置几个阶段。界面提示下载失败时，先看 HTTP 状态或连接错误；提示配置格式错误时，说明至少已经取得一部分内容，应检查返回体；显示更新成功却没有节点，则继续确认当前启用的是哪份配置。不要把这些不同问题都交给反复刷新处理。

确认复制的是完整订阅链接，而不是服务网站首页、付款页面或浏览器分享地址。复制过程中的换行、首尾空格、被聊天软件截断的查询参数都会改变请求。订阅地址通常携带访问权限，应视为敏感信息。查看时避免投屏，也不要粘贴到在线转换器、公开工单或搜索引擎；发生泄露后应在服务端重置链接。

按响应内容处理获取错误

状态码只能指明方向，不代表最终原因。例如访问控制页面也可能返回正常状态，但正文实际是登录提示。浏览器能打开链接不保证客户端能获取：浏览器可能已经登录、使用独立代理或保存了必要 Cookie。应优先使用服务方明确支持的客户端订阅入口，而不是试图把浏览器会话数据复制到配置文件。

检查 YAML 与订阅格式兼容性

Clash 配置、节点列表与其他客户端订阅格式不是同一种内容。只有编码后的节点链接列表，不一定能直接作为完整 YAML 配置运行。完整配置还可能包含策略组、规则与 DNS；客户端也可能通过模板补足这些部分。先确认导入入口需要的是完整配置还是节点提供器，不要用改扩展名的方式转换格式。

YAML 常见错误包括用制表符缩进、列表层级错位、引号未闭合，以及重复定义同一顶层字段。错误行号附近应连同上一行一起查看，因为解析器发现异常的位置不一定是最初写错的位置。对 mihomo 的本地配置，可以使用其校验命令；这里的 config.yaml 指当前目录中准备检查的文件，执行前应确认它不是唯一备份。

mihomo -t -f config.yaml

校验通过只说明配置结构和相关引用可被内核接受，不会证明节点账号有效，也不等于所有规则资源都能实时更新。若出现未知字段或不支持的代理类型，核对客户端所带内核，而不是只看客户端外壳名称。需要更换时从下载页选择适合系统的维护中客户端，并保留原配置用于对照。

更新成功后检查实际应用结果

更新订阅后回到配置列表，确认正确配置处于启用状态，再检查策略组是否仍引用旧节点名称。服务端重命名节点可能让手动选择失效；本地覆写也可能保留旧规则或覆盖新 DNS。先在备份后暂时停用覆写进行比较，确认问题来自订阅本身还是本地合并过程，再决定修改哪一层。

多设备共用订阅时，各客户端的更新周期、缓存与模板未必一致。电脑已经更新不代表手机也已应用同一份内容。可以比较节点名称与配置更新时间，但不要为此公开订阅链接。具体同步边界参见电脑与手机共用配置方案。自动更新恢复后，应降低手动重试频率，避免触发限流再次造成假性故障。

最后检查订阅获取是否依赖当前不可用的代理。若客户端允许选择更新时的网络路径，可在基础网络正常的前提下比较直连与现有可用出口。没有可用节点时，不应强制所有订阅请求经过已经失效的代理。涉及服务方指定访问方式的情况，按其说明处理，不要同时叠加不明转换服务。

速度慢：分开测首包、吞吐与稳定性

明确慢的是哪一种操作

网页等待很久才开始显示、下载开始后速度低、视频播放中反复缓冲，分别可能对应解析与握手、持续吞吐、链路波动等问题。先记录慢发生的阶段，再选择测试方法。客户端列表中的节点延迟通常来自一个短请求，并不等价于大文件下载能力，更不能直接代表特定视频网站或代码仓库的体验。

选择一个平时会用的目标，在相近时间比较直连、固定代理出口和另一网络。不要同时运行多项测速，否则测试本身会抢占带宽。停止云盘同步、系统下载等后台任务，并检查本地无线信号。路由器连接正常但无线干扰严重时，代理节点可能完全正常；可以用有线连接或靠近接入点进行对照。

观察时间组成，而不是只看总耗时

下面的命令通过本地 HTTP 代理发起请求，输出连接、握手、首字节和总耗时。它们是 curl 记录的累计时间点，不应直接相加。使用 HTTP 代理建立 HTTPS 隧道时，部分时间包含代理协商，远端域名解析也未必体现在本机解析时间中；因此它适合做同条件比较，不适合孤立判断某一个 DNS 服务的性能。

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

macOS 与 Linux 将 curl.exe 改为 curl，并把输出文件 NUL 改为 /dev/null。小页面测试主要用于观察建立连接，不适合测最大带宽。需要比较持续下载时，选择可信、允许测试的文件源，保持文件与时段相同，并考虑目标服务器限速。不要把单个站点的限流结果当成整个代理网络的上限。

检查策略组切换与连接复用

自动选择组可能频繁切换出口，而已经建立的连接仍使用原节点。用户切换后立即刷新，浏览器还可能复用旧连接，因此看到的结果与界面选择不一致。可以关闭目标页面、结束对应连接后重新测试。不要直接结束所有连接作为常规操作，这会中断下载、会议与其他正在进行的任务。

同一地区名称不代表相同线路，距离近也不保证跨网质量好。比较时固定最终节点，不仅固定策略组名称。若某服务只有特定出口慢，查看其区域限制、拥塞和服务端响应。若多个出口在同一网络都慢，而手机热点正常，应优先检查本地网络、运营商路径或其他隧道软件，而不是不断追加分流规则。

谨慎处理 UDP、MTU 与资源占用

部分应用使用 QUIC 等 UDP 传输，代理链路对 UDP 的支持情况会影响体验。临时关闭浏览器的相关实验功能可以用于对照，但不应把永久禁用协议当成通用优化。若 TCP 正常而 UDP 应用不稳定，先确认节点协议、客户端设置与当前网络都允许 UDP，再考虑局部规则或应用层调整。

TUN 环境下，网页小请求正常而大传输停顿，可能涉及路径 MTU，但不能仅凭这一现象就认定原因。先排除服务器限速与丢包，备份原设置，再按客户端支持范围一次调整一个参数并复测。盲目把 MTU 改得很小会增加包数量，也可能降低吞吐；企业网络或叠加隧道时应交由网络管理员一起确认。

如果速度下降伴随 CPU 占用明显升高，检查是否同时开启详细日志、大量健康检查与多个配置更新任务。连接数量持续增长也可能来自应用重试。先暂停额外任务，再以单个应用复测。确认问题属于远端服务或上游线路后，应停止继续改本机 DNS；DNS 调整无法提高已经建立连接的持续传输带宽。

DNS 异常：核对解析入口与 Fake-IP

先区分本机解析与代理内解析

浏览器报域名错误时，至少可能涉及操作系统解析器、浏览器安全 DNS、客户端 DNS 和节点服务器使用的解析路径。先确认失败的是目标网站域名还是节点服务器域名。节点域名无法解析时，连接还没有到达上游；目标域名失败则要结合代理入口和 DNS 模式继续判断。不要直接把所有解析都指向同一个公共地址。

使用显式 HTTP 代理或 SOCKS 远端解析时，目标域名可能交由代理端处理，因此系统命令查询失败与浏览器代理访问成功可以同时存在。反过来，系统查询成功也不证明客户端内解析正常。先画清楚请求走向，再用对应入口测试，避免用系统 DNS 的结果替客户端内部 DNS 下结论。

理解 Fake-IP 返回结果

Fake-IP 模式会给域名分配映射地址，内核通过映射还原目标域名后处理连接。看到保留地址段并不自动表示解析受到干扰；应先确认这个地址是否来自客户端配置的 Fake-IP 范围。若应用把该地址缓存后绕过内核直连，就可能失败，因此模式切换后需要重新建立连接，必要时重启受影响的应用。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
  nameserver:
    - https://dns.alidns.com/dns-query

该片段用于解释字段关系，应合并到现有配置的唯一 dns 块中，不要直接覆盖整份订阅。上游地址只是示例，实际可达性要在当前网络验证。使用域名形式的加密 DNS 上游还需要能够解析其自身域名，相关引导解析应遵循所用内核文档。公司内部域名通常需要内部解析器，不能全部发送到公共服务。

围绕具体域名设置例外

局域网设备发现、某些游戏和需要核对真实解析结果的应用，可能不适合 Fake-IP。先找出确切失败域名，再加入 fake-ip-filter 做对照。过滤后返回真实地址，但最终流量是否直连仍由规则决定；过滤列表不等于直连名单。将所有域名都加入过滤会失去该模式的主要作用，也可能让原有分流行为改变。

浏览器启用自己的加密 DNS 时，查询可能绕开预期的本地 DNS 入口。诊断阶段可以暂时使用系统解析路径，观察故障是否改变，再决定保留哪套方案。TUN 的 DNS 接管也不代表能透明识别所有加密查询，尤其是应用内置的 HTTPS 查询。更完整的映射过程可阅读Fake-IP 与过滤列表说明。

按解析链清理缓存并检查 IPv6

先确认配置已经应用，再清理受影响层的缓存，否则旧设置仍在运行，清缓存只能带来短暂变化。Windows 可执行下面的系统缓存清理命令；浏览器、应用和客户端可能各有独立缓存，应按各自界面处理。macOS 与 Linux 的缓存机制随系统服务变化，不宜照抄一条命令反复执行。

ipconfig /flushdns

同一域名同时返回 IPv4 与 IPv6 地址时，应用可能优先尝试当前不可达的地址族。应检查系统 IPv6 路由、节点出口和客户端解析设置，而不是立即关闭整台设备的 IPv6。可以在受控测试中比较地址族，确认确实有关后，再调整客户端支持的选项。改变解析顺序之后，必须重建连接才能观察结果。

如果只有内网域名失败，确认搜索后缀、内部 DNS 地址与访问网络是否正确。连接企业 VPN 后可能新增分域解析设置，代理客户端的通用 DNS 覆盖会打断这一机制。保留企业策略，针对内部域名设置解析与路由边界。定位结束时应同时验证公共网站、局域网设备和工作服务，避免修好外网却破坏内网访问。

系统代理失效：检查应用入口与 TUN 路由

确认应用是否读取系统代理

系统代理开关只修改系统提供的代理配置，不会强制所有程序使用代理。浏览器通常会读取相关设置，但命令行工具、游戏、容器和某些桌面应用可能采用独立网络栈。判断入口是否生效，应以客户端连接记录为准。应用完全没有产生连接时，先检查其代理支持方式，而不是调整出站规则。

Windows 的用户代理与 WinHTTP 设置属于不同入口，某些服务不会跟随用户界面中的代理。macOS 按网络服务保存代理，切换有线与无线后应检查当前服务。Linux 桌面代理、环境变量和应用内部设置也不完全一致。不要为了让一个程序工作，就把所有入口同时写成同一个值；先确认该程序实际读取哪一项。

端口、环境变量与绕过列表

客户端混合端口改变后，应用内代理与终端变量可能仍指向旧端口。先在当前运行配置中读取实际值，再检查本地监听。下面给出 Windows 和 Linux 的检查命令；它们用于确认端口状态，发现占用后应识别所属进程，不要直接结束所有监听进程。

# Windows PowerShell
Get-NetTCPConnection -LocalPort 7890 -State Listen

# Linux
ss -lntp 'sport = :7890'

终端中的 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 与 NO_PROXY 可能影响不同工具，但支持情况并不统一。查看变量时注意其中可能包含认证信息。修改当前终端的变量不会自动影响已启动的其他程序；桌面应用也未必继承终端环境。绕过列表如果包含目标域名，应用可能直接访问，从而在客户端中没有记录。

TUN 需要权限、路由与正确排除项

TUN 通过虚拟网络接口接管流量，适合处理不读取系统代理的应用，但需要相应系统权限与路由配置。先确认客户端辅助服务或权限授权已经完成，再检查虚拟接口是否建立、路由是否实际写入。界面显示开关开启而日志提示权限不足，说明接管尚未成功。容器、远程桌面与服务器环境更需要谨慎，错误路由可能中断管理连接。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

该示例适用于支持这些字段的 mihomo 环境，不代表所有平台都应原样使用。客户端可能通过界面生成并覆盖 TUN 配置，应修改其指定入口。自动检测出站接口在多网卡、虚拟机、其他 VPN 并存时可能选错，应结合实际默认路由确认。DNS 端口接管也不等于接管所有加密 DNS 流量。

处理其他代理与网络切换残留

浏览器扩展、另一个 VPN、企业安全软件和代理客户端同时工作时，可能争用系统代理、虚拟网卡或路由。诊断时先暂停可以自行关闭的额外工具，保留企业强制策略，并记录原状态。只允许一个入口控制系统代理，再观察设置是否被其他进程改回。不要通过循环点击开关与另一程序争抢配置。

从无线切到有线、休眠恢复或连接热点后，默认网卡和网关可能已经变化。若 TUN 只在切网后失效，可先断开连接、重新启动接管，再看新连接记录。若重新启用即可恢复，应进一步检查接口检测与客户端日志，而不是定时重启整个系统。对于 macOS 的授权问题，可参照网络扩展与钥匙串设置说明。

验证时分别检查一个遵循系统代理的浏览器和一个原先不遵循代理的应用。前者正常、后者失败，说明系统代理通路可能已经修好，但 TUN 或应用配置仍需处理。最后退出客户端，再测试基础网络是否恢复；确认代理地址撤销、虚拟路由清理后，才能认为恢复流程完整。不要长期把本地代理端口开放给不可信网络。

启动失败与崩溃：分离界面、内核和配置

先确认退出的是哪个进程

客户端窗口关闭、托盘图标消失与内核停止不是同一件事。有些程序关闭窗口后仍在后台运行，也有些界面存在但内核已经崩溃。先看托盘、任务管理器或系统活动监视器，再检查本地端口与日志。不要因为看不到主窗口就连续启动多个实例；多个实例可能争用端口、配置目录和辅助服务，制造新的启动故障。

观察故障发生时机：刚启动就退出，多与环境、权限或配置有关；导入配置后退出，重点检查内容与资源；运行一段时间后退出，则考虑内存、磁盘、日志增长或特定连接触发的问题。记录最后一次正常操作及随后做过的改动，比直接清空所有数据更有价值，也便于后续复现。

核对系统架构与安装环境

安装包必须匹配系统和处理器架构。Windows、macOS 与 Linux 的安装方式不同，不能把相似文件名当作兼容保证。macOS 还需区分 Apple Silicon 与 Intel；Linux 需同时考虑发行版包格式、运行库和桌面环境。优先从平台下载入口选择 Clash Plus 或适合当前系统的维护中客户端，不要用旧教程中的历史安装包替代。

安全软件隔离、系统应用控制或文件执行权限也可能阻止启动。先查看系统给出的具体提示，确认文件来源，再按系统正常流程授权。不要全局关闭安全机制，也不要从不明站点补下载所谓缺失组件。企业设备上的安装限制应由管理员处理；绕过策略可能导致辅助服务无法正常运行，后续仍会出现网络接管失败。

备份后建立最小运行环境

处理配置损坏时，先退出客户端并备份数据目录。备份可能含订阅地址与认证信息，应保存在本机可信位置，不要自动同步到公开仓库。然后使用客户端提供的重置或新配置功能测试，避免直接删除整个目录。若最小配置能启动，再逐步恢复订阅、规则资源与覆写，每恢复一部分就重启验证。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
rules:
  - MATCH,DIRECT

这个最小示例仅用于检查内核和本地监听能否工作，全部流量按直连处理，不提供代理出口。测试前确认端口未占用，并暂时关闭 TUN。若这个环境正常，原配置中的代理类型、规则提供器、脚本化覆写或外部资源值得重点检查。恢复业务配置前，应明确切回有效订阅，避免把诊断用直连配置误当成正常运行状态。

区分端口冲突与资源耗尽

日志出现地址已被占用时，定位具体监听进程，确认是否为旧实例、另一代理或系统服务。可以临时更换混合端口验证，但相应应用代理设置也必须一起更新。控制端口与代理端口用途不同，不能只改一个界面数值就认为所有冲突已经消除。若辅助服务仍加载旧配置，需按客户端流程重新启动服务。

运行后逐渐卡死，检查磁盘剩余空间、日志文件增长、规则资源规模与连接数量。长期保持调试日志可能增加写入负担；大量连接也可能由应用故障重试造成。先停止触发问题的应用，再观察资源是否回落。内存占用高本身不等于泄漏，应结合持续增长、释放情况与稳定复现条件判断。

升级后才出现问题，应记录升级前后的配置变化与系统提示，保留回退所需备份。不要同时更新客户端、修改 DNS 和更换订阅，否则很难识别触发因素。提交问题时附上系统架构、客户端名称、内核报错和最小复现步骤，删去私密字段；只有可复现的边界，维护者才能区分界面问题、内核问题和配置不兼容。

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

Android 先确认 VPN 授权与唯一接管者

Android 客户端通常通过 VpnService 建立本地 VPN 接口，系统授权弹窗属于网络接管步骤，不表示设备连接到了某个远程 VPN 服务。首次启动应确认授权已经完成，再看状态栏与客户端连接状态。多数常规场景同一用户只能有一个活动 VPN；广告过滤器、工作资料 VPN 和其他代理工具可能与当前客户端发生接管冲突。

系统的始终开启 VPN 与阻止未使用 VPN 的连接会改变断开后的行为。如果启用了阻止选项，客户端停止时整机断网可能正是系统策略，而不是无线网络故障。诊断时先记录这些设置，再决定是否临时关闭。工作设备的受管 VPN 不应自行删除，应让管理员确认个人代理是否允许并存，以及哪些应用属于受管范围。

锁屏断连重点检查后台限制

亮屏正常、锁屏一段时间后失效，先检查电池优化、后台活动、自启动与厂商的应用休眠功能。把客户端从严格省电限制中放行，再锁屏复测。只授予通知权限未必足够，通知存在也不能证明内核仍正常运行。应在恢复亮屏后查看服务状态与日志时间，确认是进程被结束、网络被暂停，还是连接本身过期。

不要一次关闭手机全部省电功能。先针对客户端设置允许后台运行，保留其他应用原状态，再按同样时长复测。不同系统菜单名称不同，可在设置中搜索电池优化、后台运行或自启动。具体检查路径见Android 后台断连与省电白名单。如果某个网络下才复现，还应检查路由器休眠与无线省电策略。

iOS 检查隧道状态与按需连接

iOS 使用 Clash Plus 时，先在客户端确认配置启用，再到系统 VPN 状态查看隧道是否实际连接。首次使用若授权未完成，客户端保存了订阅也不会开始接管。需要安装或重新安装时，通过iOS 下载入口进入商店；其官网为 clashplus.io。重新安装前先确认配置是否已安全备份。

按需连接可能在切网、重新联网或满足规则时自动建立隧道，用户手动关闭后又出现连接，不一定是程序异常。先检查按需设置、系统保留的其他 VPN 配置和当前启用项，不要反复删除所有网络描述信息。若隧道显示已连接但只有某个应用失败，继续看分流与 DNS，而不是直接重置整机网络。

区分无线与蜂窝网络的差异

同一节点在无线正常、蜂窝失败，可能涉及 UDP、IPv6、运营商路径和移动数据权限。先确认客户端允许使用移动数据，再固定同一节点做对照。某些网络采用不同地址转换方式，不能根据服务器能够 ping 通就认定代理协议可用。切换时保持一次只改一个条件，记录连接断开的时间和重新建立所需步骤。

公共无线网络常要求先完成网页认证。接管流量后认证页可能无法正确弹出，可暂时断开代理、完成网络登录，再重新连接。认证页面是否可信应由网络环境判断，不要在不明页面输入订阅地址或代理账户。若酒店或校园网络限制某些协议，应联系网络管理方确认允许的访问方式，不要把本地配置反复重置。

移动端还要检查分应用代理名单。名单采用仅代理所选应用还是排除所选应用，方向弄反会造成一个应用有连接、另一个完全没有记录。修改后通常需要重新建立隧道并重启目标应用。热点共享设备是否经过手机代理则取决于系统与客户端能力，手机自身访问正常不能证明热点下的电脑也会自动使用同一出口。

跨设备比较时，确认手机与电脑真正使用相同订阅内容和最终节点，且不是一个走规则模式、另一个走全局模式。移动端菜单简化不意味着内核行为完全相同；不受支持的字段可能被忽略或由界面覆盖。对不熟悉的术语可先查术语表，需要重新梳理操作顺序则返回入门指南，按导入、选择、连接与验证主线建立新的成功基线。