• mihomo
  • 日志 · 规则 · 网络栈

Clash Meta
故障排查大全

按症状定位连接链路。先确认本地端口，再检查规则、DNS 与远端连接，每次只修改一个变量。

首次安装与订阅导入请按入门指南完成。本页面向已经配置、但出现异常的场景，是可按章节查阅的手册；恢复后可回到教程继续验证连接。客户端菜单名称会有差异，文中的“配置、连接、日志、设置”指对应功能区，最终以实际运行配置与内核日志为准。

无法上网：从本地入口检查

先区分原网络与代理链路

先停止客户端连接，关闭系统代理，并确认 TUN 已退出，再访问原本可以直连的网站。如果仍无法访问，优先检查 Wi-Fi 登录认证、网线、路由器与系统网络状态，不要继续修改规则。酒店和校园网络可能要求先通过网页认证；认证页尚未完成时，代理服务器再正常也无法建立连接。恢复原网络后，重新启动客户端，只加载一份已知可用的配置。

如果客户端退出后全网中断，检查系统是否还保留指向本机的代理地址。监听程序已经停止，而应用仍向该地址发送请求，会出现持续拒绝连接。Windows 在“设置 → 网络和 Internet → 代理”检查手动代理；macOS 在当前网络服务的“详细信息 → 代理”检查。先记录原值再调整，企业设备的自动配置地址可能由管理策略下发，不应直接清空。

确认内核启动与端口监听

打开客户端日志，从最近一次启动处向下查看。配置解析失败、端口占用和权限不足都可能使界面看起来已运行，内核却未提供代理。出现 address already in use 时，检查是否启动了第二个客户端或残留内核。不要只把端口改成另一个数字：若系统代理与终端环境变量仍使用旧端口，问题只是从端口冲突变成入口不一致。

mixed-port 是 HTTP 与 SOCKS 共用的本地入口，不是节点服务器端口。以下片段只用于与现有配置核对，不能替代完整订阅。确认运行端口是 7890 后，再用显式代理命令测试；若实际端口不同，命令中的地址也要对应修改。测试应选一个原网络可访问的网站，先验证本地入口，而不是把目标站点自身的限制混在一起。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
curl -I --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:7890 https://example.com

用连接记录定位中断位置

命令立即提示无法连接本机，说明入口没有监听或被本机安全策略拦截；进入连接记录后才失败，才继续追查规则与出口。在 Windows PowerShell 中建议明确使用 curl.exe，避免命令别名改变参数含义。收到任何有效 HTTP 响应都说明请求已到达某个 HTTP 服务，状态码不是成功码，也不能直接等同于代理未启动。

在连接页筛选目标域名，核对命中的规则、策略组与最终出口。规则按顺序匹配，前面的宽泛规则可能覆盖后面的精确规则。若选中策略组但其内部仍指向不可用代理，只切换外层组不会恢复。可以短暂使用全局模式并手动指定同一个已知可用出口作对照；测试后恢复规则模式，不要用永久全局掩盖错误分流。

显式代理正常、浏览器失败，应转到系统代理章节；日志显示域名解析错误，转到DNS 章节；只有某个出口失败，转到节点超时章节。每次测试记录目标、模式、出口和结果，避免在不同网站与不同节点之间来回切换，失去可比较的条件。

节点超时：拆分解析、连接与握手

测速失败不等于所有请求失败

客户端的延迟检测通常是通过指定代理向测试地址发起请求，反映的是这一次探测的结果，不是服务器端口的简单连通性。测试地址不可达、返回状态不符合预期，或服务器限制频繁探测，都可能显示超时。先通过同一出口打开实际需要的网站，并查看连接日志；如果实际访问正常，应检查测试地址与检测间隔，而不是立即删除订阅。

区分单个出口、同一服务商全部出口和所有服务商出口三种范围。只有一个失败，优先检查该服务器与参数；一组同时失败，检查账号状态、订阅更新及服务端维护；所有出口都失败，则回到本机网络、DNS、时间和防火墙。手机热点可以作为不同接入网络的对照，但切换网络后要重新建立连接，旧连接的失败结果不能代表新网络。

按错误发生的阶段阅读日志

lookup 或 no such host 通常指向服务器域名解析；connection refused 表示目标主动拒绝连接，常见于端口未监听或服务配置不符；连接超时只说明在时限内未完成某阶段，不能据此断言账号失效。若日志已经进入 TLS 或协议握手，再检查认证、SNI、传输方式与系统时间，而不是继续反复更换 DNS。

日志线索优先核对不要直接推断
服务器域名解析失败节点域名解析器与直连网络节点认证信息错误
连接被拒绝服务端端口与监听状态本机规则顺序错误
TLS 证书错误时间、证书链、服务器名称关闭验证就是修复
握手后连接关闭协议参数、认证、服务端限制更长超时一定有效

手工维护代理时，逐项核对 type、服务器地址、端口、认证内容与传输层设置。TLS 的服务器名称不一定等于连接地址；WebSocket 的路径与 Host 也不能随意互换。应以提供方给出的 mihomo 配置为依据，保留大小写与字段层级。订阅转换后出现未知字段或协议不支持时，检查实际内核，而不是仅凭客户端名称判断能力。

区分协议能力与网络限制

某些出口使用 UDP 传输，普通 TCP 网站可访问并不能证明该出口的传输通道可用。反过来，TCP 代理正常而游戏失败，也可能只是应用使用 UDP、代理不支持该流量或策略组没有走到预期出口。先以普通 HTTPS 请求建立基线，再单独测试需要 UDP 的应用，避免把两类需求用同一个延迟数字作结论。

检查系统日期、时区与自动校时状态。时间偏差可能使证书被判断为尚未生效或已过期。若只有特定 Wi-Fi 出现证书错误，还要考虑认证门户或网络检查设备。不要把 skip-cert-verify 当通用解决办法；它会改变连接的信任边界，却不能修复服务器名称、证书链或认证参数本身的问题。

向提供方反馈时，保留错误发生时间及所在时区、接入网络类型、协议名称和脱敏错误行。不要发送完整订阅、二维码或包含密码的配置。若换网络即可恢复，说明故障与接入路径相关；若同一出口在多个设备和网络均失败，才更有依据请求服务端检查。延长超时只能用于确认慢响应，不能让未监听的端口或错误认证变得可用。

订阅失败：检查请求与配置生成

把下载失败与导入失败分开

订阅更新包含请求地址、接收响应、解析内容和生成运行配置几个阶段。先查看提示属于网络错误、HTTP 状态异常还是 YAML 解析错误。地址连不上与内容不能解析是两件事：前者检查网络、域名和访问授权，后者检查格式与客户端兼容性。不要在没有确认原因时连续新增相同订阅，否则会产生多个名字相似、更新状态不同的配置，增加误选概率。

复制地址时保留完整查询参数，检查聊天软件是否插入空格、换行或省略号。订阅 URL 经常携带访问凭据，不应放进公开截图、工单或在线转换页面。浏览器能打开也不一定代表内容正确：登录页面、验证码页面和流量用尽提示都可能以网页形式返回。应在本地检查响应类型和开头内容，确认得到的是客户端支持的配置，而不是 HTML。

根据响应定位服务端与本机问题

HTTP 401 或 403 通常需要核对授权、账号状态与服务端访问策略；404 可能是地址失效或路径复制不完整；429 表示请求过于频繁，应停止手动刷新并等待。服务器错误则应保留当前可用配置，稍后重试或联系提供方。这些状态不能只靠更换本地端口解决，也不应把一次更新失败当成已缓存配置必须删除的理由。

如果订阅地址只能通过代理访问，而当前配置恰好没有可用出口，就形成了更新依赖环。先尝试客户端提供的直连更新或代理更新选项，明确记录本次使用哪条路径；必要时切换到可访问该地址的网络。仍保留旧配置的情况下，可先选一个可用出口完成更新。不要为了下载订阅，把尚未取得内容的同一个订阅设置为唯一网络入口。

核对 YAML 与最终合并结果

出现缩进错误时，先查看日志中的行号及附近上下文。YAML 使用空格表达层级，Tab、中文冒号以及不成对的引号都可能造成解析失败。字段能解析也不代表类型正确，例如列表误写成字符串、布尔值放到错误层级，可能在内核加载时才报错。先撤销最近一次手动修改，再逐段恢复，不要同时重写整份文件。

mode: rule
proxy-groups:
  - name: 出口选择
    type: select
    proxies:
      - DIRECT
rules:
  - MATCH,出口选择

上例用于检查列表与缩进结构，只包含直连出口。实际订阅中的代理组名称必须与规则引用完全一致，包括空格与大小写。若日志提示找不到代理或策略组，检查生成后的运行配置，而不只是原始订阅文件。客户端可能在下载后继续执行覆写、合并或脚本处理，问题也可能由这些后处理步骤引入。

proxy-providers 提供代理来源，rule-providers 提供规则集合，两者的内容格式不同。规则提供器还需核对 behavior 与文件内容：域名集合、IP 集合和 classical 规则不能只换一个字段就混用。远程资源的路径也应各自独立，避免不同提供器写入同一缓存文件，出现更新后内容互相覆盖。

按“停用覆写 → 更新原始订阅 → 确认能加载 → 逐个恢复覆写”的顺序定位。更新成功后，检查当前激活配置、代理组成员与规则数量是否合理，并重新建立一条连接验证。多设备同步时尤其要区分订阅源与本机设置，端口和 TUN 权限不适合直接照搬，具体边界见多设备配置同步对比。

速度慢：区分带宽、延迟与负载

先建立可重复的比较条件

速度慢可能指网页首屏等待、视频缓冲、下载吞吐低或交互卡顿，四者不能共用一个判断标准。先固定设备、网络、目标和出口，再做前后对照。网页首次访问慢但后续传输正常，优先看 DNS、连接建立与握手；持续下载很慢，才重点看可用带宽、服务器负载与目标站限制。记录症状比反复点击全部节点测速更有价值。

先用直连可达的资源检查本地网络基线，再通过代理访问同一资源；对必须经代理访问的目标，则在两个可用出口间比较。测试时暂停系统更新、云盘同步与其他大流量任务，避免多台设备共享带宽造成误判。Wi-Fi 信号、路由器负载与移动网络拥塞都位于代理之前，换客户端无法绕开这一段瓶颈。

延迟检测不是吞吐能力排名

延迟较低的出口不一定拥有更高吞吐，也不一定适合所有站点。自动选择策略通常围绕测试请求作决策，而非持续测量下载带宽。若只在一个网站很慢，检查该网站的 CDN、账号限制和出口到目标的路径；如果所有目标都慢，再看接入网络与服务器整体状态。不要把某一次大文件下载结果推广成所有应用的体验结论。

用连接记录确认实际流量经过的策略组。规则里选了自动组，但自动组内部可能又引用另一个选择组；界面显示的外层名称不等于最终出口。修改策略后，已经建立的长连接可能继续使用旧路径，可关闭目标应用连接或只断开相关连接再重试。不要在重要下载或远程会话中直接清空全部连接，以免把排查变成额外中断。

检查 DNS、协议与 TUN 开销

如果每次打开新域名都先停顿，查看 DNS 请求是否多次超时后才回退。多个上游并不自动带来更快解析：其中一条不可达、引导解析依赖错误或查询经不稳定出口发送，都可能拖慢新连接。先保留一条当前网络可用的解析路径确认基线，再按需要增加分流。缓存只影响重复查询，不能替代正确的首次解析路径。

浏览器可能优先尝试 HTTP/3，而出口或当前网络的 UDP 路径不稳定，最终回退到 TCP，表现为先卡顿后恢复。可以临时关闭该应用的 QUIC 作对照，但不宜把所有 UDP 永久丢弃当优化方案，因为语音、游戏与部分协议依赖它。诊断时同时观察连接类型与目标端口，确认缓慢请求是否确实走了 UDP。

TUN 接管范围更广，开启后可能暴露系统代理未覆盖的后台流量，也可能与安全软件、另一套 VPN 或虚拟网卡竞争路由。对同一目标比较“显式 HTTP 代理”和“TUN 接管”的结果：前者正常、后者慢，优先检查路由与网络栈，而不是更换订阅。修改 stack 前先确认当前内核与平台支持，并保留恢复原值的记录。

当小请求正常、大响应停滞时，可以怀疑路径 MTU 或中间设备行为，但应先排除目标限速与丢包。MTU 调整必须针对实际隧道接口并进行前后对照，不要照抄任意数字覆盖所有网卡。频繁关闭防火墙同样不是速度优化；应查看具体拦截事件，再只处理与客户端相关的程序或接口规则。

排查结束应保存一组可复现记录：同一目标、同一时段、两个出口、两种接入方式的结果，以及是否开启 TUN。若瓶颈稳定发生在特定服务端路径，把这些信息交给提供方更有效。清缓存、重装软件或增加并发连接数，都不应在没有证据时作为默认提速步骤。

DNS 问题：检查解析入口与出站路径

先确认是谁在发起解析

DNS 故障不只发生在内核。系统解析器、浏览器安全 DNS、应用自带解析器和 mihomo DNS 可以同时存在。先确认失败请求是否进入客户端，再查看日志中的解析错误。浏览器能打开而终端失败，可能两者使用不同解析路径；终端能解析而浏览器失败，也可能是应用自己的加密 DNS 不可达。单看一个查询工具的结果，不能代表所有应用。

显式 HTTP 代理访问域名时，目标名称通常可交给代理入口处理；SOCKS 则要区分本地解析与远端解析方式。以下命令使用 socks5h，让域名交给代理侧处理，用于与应用本地解析作对照。若它正常而应用失败，应继续检查应用的解析方式，而不是立刻修改所有系统 DNS。命令端口必须与实际混合端口一致。

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

理解 fake-ip 的正常表现

enhanced-mode: fake-ip 会为符合条件的域名返回虚拟地址，由内核保留域名与连接的对应关系。看到 198.18.0.0/16 范围内的地址，不应直接判断为解析污染。关键在于访问该地址的流量是否仍由同一内核接管；应用拿到虚拟地址后绕过代理，或在内核重启后继续使用过期映射，才可能发生连接异常。

先停止相关应用，再重启内核，清理与本次问题有关的系统或应用 DNS 缓存后重试。Windows 可使用 ipconfig /flushdns；其他系统应按实际解析服务处理。不要在未确认缓存来源时删除整个客户端数据目录。对局域网设备、打印机或特定认证域名出现兼容问题时，可评估定向 fake-ip 过滤，而不是把所有域名一并排除。

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

这只是 DNS 片段，上游地址需要在当前网络可达。监听 1053 不会自动让系统使用该服务，也不会自行接管所有 DNS 请求；需要客户端的接管机制或明确指定解析入口。可用 nslookup example.com 127.0.0.1 检查的是本地 53 端口，不能据此验证上例的 1053。若系统安装了 dig，可用下方命令指定端口。

dig @127.0.0.1 -p 1053 example.com A

避免引导解析与代理出口互相依赖

上游采用域名形式的 DoH 地址时，连接上游本身先需要解析；代理服务器也使用域名时，又存在节点域名的解析需求。应区分 default-nameserver 的引导解析用途与 proxy-server-nameserver 的代理节点域名解析用途。不要让节点域名必须经过尚未建立的节点才能解析，也不要把所有解析都强行送入同一条未验证的出口。

企业域名与家庭局域网名称可能只由内网 DNS 知道。配置公共上游后，这些名称失败不代表公共 DNS 服务故障，而是查询发送到了不掌握内部记录的地方。应保留内网解析路径，并通过合适的域名策略定向处理；同时检查内网网段是否被误送入代理。修改前记录原网络提供的 DNS，尤其不要覆盖企业设备上的管理配置。

“DNS 泄漏”需要结合预期路径判断。测试页面显示某个递归解析器，只能说明该测试域名最终由它查询，不能直接证明其他连接绕过代理。先明确哪些域名应由哪条路径解析，再结合浏览器安全 DNS、TUN 的 DNS 接管和连接记录检查。加密解析保护的是查询传输，不会自动确保解析请求使用指定代理出口。

系统代理不生效：确认应用接入方式

系统代理不是全局网络接管

系统代理是提供给应用的代理设置，是否使用由应用及其网络库决定。浏览器正常而命令行工具、游戏或商店应用失败，并不必然是规则错误。先使用显式代理命令验证内核入口，再检查目标应用是否读取系统设置。部分应用需要独立填写 HTTP 或 SOCKS 地址，部分使用环境变量，还有部分更适合通过 TUN 接管，不能假定一个开关覆盖全部进程。

Windows 中用户代理、自动代理脚本和 WinHTTP 设置属于不同入口。netsh winhttp show proxy 可以查看 WinHTTP 状态，但它不代表当前浏览器使用的设置。不要为了修复一个应用直接把代理写入所有系统服务；服务账号、更新组件与用户会话的网络需求可能不同。先确定失败程序采用的网络库，再选择对应配置方式。

核对本机地址、端口与环境变量

本机应用通常使用 127.0.0.1 与实际监听端口。若系统代理写成旧端口，或应用把 HTTP 地址填到只支持 SOCKS 的字段，就会失败。allow-lan: false 不妨碍本机回环访问；另一台设备却不能把自己的 127.0.0.1 当成电脑地址。需要局域网共享时，才另行检查监听地址、防火墙与信任边界。

终端环境变量会被新启动的子进程继承。客户端切换端口后，已经打开的终端仍可能保存旧值；关闭系统代理也不会自动删除手工设置的变量。下例用于类 Unix shell 的当前会话对照，不修改永久配置。先查看既有变量并记录来源，再设置测试值；恢复时还要检查 shell 启动文件、开发工具设置和项目脚本是否重新注入代理。

env | grep -i proxy
export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
curl -I --max-time 20 https://example.com
unset http_proxy https_proxy

这里 https_proxy 的值仍使用 http://，表示客户端连接本地 HTTP 代理，再建立 HTTPS 隧道，并非把目标访问降级为明文。不同工具对变量大小写和优先级的处理不同，ALL_PROXY 与 NO_PROXY 也可能改变行为。检查时需包含这些变量，尤其要看是否有过宽的绕过域名或网段。

处理 UWP、容器与 TUN 场景

Windows 部分商店应用受回环访问限制，即便系统代理正确，也可能无法连接本机代理入口。先确认普通桌面应用通过同一端口正常，再评估对目标应用添加回环豁免，或使用 TUN。不要把所有应用一次性豁免当默认步骤；具体命令与影响范围见UWP 回环限制排查。这类问题不需要修改远端代理认证。

容器、虚拟机和 WSL 有独立网络视角，其中的回环地址未必指向宿主机。应按当前网络模式查找宿主机可达地址，并验证防火墙与监听范围。不要直接把本地代理开放到所有接口作为第一步；共享代理可能被同一网络中的其他设备使用。确需开放时，限定可信来源，并按客户端能力配置访问控制。

TUN 通过虚拟接口与路由接管流量，通常需要额外权限或服务组件。开启后检查日志中的设备创建、路由安装与 DNS 接管状态。两套 VPN 同时修改默认路由、虚拟机网段与隧道网段重叠，都可能造成部分目标消失。先停用其他接管程序做对照，恢复后再判断是否能通过明确路由共存，而不是连续重装网卡。

最终要在目标应用内发起一次新请求，并在连接页确认进程或目标、命中规则与出口。网页显示出口变化，只能证明该网页所用路径正常。修复后分别测试浏览器、命令行与原先失败的应用，退出客户端再检查系统代理能否恢复，避免留下指向已停止端口的设置。

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

先确定退出的是哪个组件

图形界面、后台服务与 mihomo 内核不是同一个组件。窗口消失但流量仍能通过，可能只是界面异常；窗口保留而所有连接中断，则检查内核是否退出。先记录故障发生在启动、导入配置、开启 TUN 还是运行一段时间后，并查看对应时间的日志。仅描述“闪退”无法区分解析失败、权限错误、进程崩溃和系统主动终止。

不要在首次异常后立刻清空数据。先退出客户端并备份配置目录、覆写文件与必要日志，再检查后台是否仍有残留进程。重复打开界面可能启动第二个内核，进一步引入端口冲突，使原始问题被覆盖。若客户端提供“打开日志目录”或“诊断信息”，优先使用该入口；目录路径因平台与客户端而异，不应照抄另一款软件的路径。

用最小配置验证内核

将内核启动与订阅内容分开验证。下面的配置只监听本机并使用直连规则，目的是确认程序能否启动，不用于代替实际代理配置。保存为独立测试文件，不覆盖原配置。若最小配置稳定、完整订阅失败，再逐步恢复代理提供器、规则提供器、DNS 与 TUN，定位具体触发项。

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

独立使用 mihomo 时，可先执行配置测试。下例假定当前目录包含内核与测试配置，图形客户端用户不必额外下载内核来执行。测试命令通过只代表配置可被解析与检查，不证明远程资源可下载或代理能连接。外部规则文件路径、相对目录与运行时权限仍需在真实启动环境验证。

# Linux 或 macOS
./mihomo -t -f ./config.yaml

# Windows PowerShell
.\mihomo.exe -t -f .\config.yaml

检查架构、权限与升级遗留

确认安装包适合操作系统与处理器架构。能下载文件不代表文件能在当前系统运行，命令行内核也不是图形客户端安装程序。普通用户可先从安装包页面选择 Clash Plus，再根据平台需求比较其他客户端。不要把多个客户端的内核文件与配置目录互相复制，界面预期的控制接口与启动参数可能不同。

若只在开启 TUN 或安装服务后退出，优先检查管理员授权、后台服务状态与安全软件拦截记录。macOS 应通过系统提示允许必要的网络组件；Windows 应核对服务安装是否成功；Linux 应检查实际启动用户与设备权限。不要对整个配置目录递归放开所有权限，也不要长期以最高权限运行所有界面操作来掩盖单个服务权限问题。

界面启动后白屏，可能涉及渲染环境或应用缓存；内核日志却持续正常时，不要修改代理协议。先完全退出再启动，若客户端提供受支持的渲染兼容选项，可单独测试。重置界面缓存之前备份数据，并确认该操作不会一起删除配置。系统日志中的应用崩溃记录可帮助判断是否属于图形组件或底层运行环境。

持续运行后退出，要观察系统内存压力、磁盘空间与日志增长，而不是编造一个固定的“正常内存值”。调试日志只在复现期间开启，结束后恢复 info；长期记录大量连接既占用空间，也会保存敏感访问痕迹。若只有启用某个远程规则集合后发生异常，保存脱敏后的最小复现配置，并注明触发步骤。

原客户端停止维护时，迁移比反复安装同一归档包更适合长期使用。Clash for Windows 与 ClashX Meta 的归档身份不代表其配置可以未经检查直接迁入其他客户端。应分别迁移订阅、自定义规则与覆写逻辑，完成一次连接验证再移除旧软件，流程见迁移到 mihomo 内核客户端。

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

Android：先检查 VPN 服务状态

Android 客户端通常通过系统 VPN 服务接管流量。同一用户或配置文件下，另一款 VPN、部分本地过滤工具或企业安全应用可能占用这一能力。先停止其他接管程序，再在 Clash Plus、Clash Meta for Android 或 FlClash 中重新连接，并确认系统 VPN 标记与授权状态。不要只依据应用首页的按钮颜色判断后台服务持续存在。

若只有某些应用失败，先检查应用分流列表。排除列表中的应用不会按预期进入代理；仅代理选中应用时，未勾选的应用也不会受接管。系统工作资料与个人资料可能拥有不同的应用和 VPN 环境，个人空间连接正常，不能证明工作空间也使用同一通道。先明确问题应用所在的资料，再判断是否需要管理员处理企业策略。

锁屏断流：区分省电与路由遗留

前台正常、锁屏后断流，先查看 VPN 服务是否仍运行，再看系统是否限制后台活动、后台数据或自启动。Android 各厂商设置路径不同，可从“设置 → 应用 → 对应客户端 → 电池”寻找后台运行权限，再检查移动数据限制。逐项修改并锁屏复测，不要一次关闭所有省电措施，否则无法确定真正需要保留的例外。

系统启用了始终开启 VPN 或阻止未通过 VPN 的连接时，服务被回收后可能表现为整机断网。这是阻断策略与服务状态共同作用的结果，不一定是节点突然失效。临时恢复网络时，应先理解该选项的保护目的，再在系统 VPN 设置中调整，恢复客户端后重新验证。完整判断路径见安卓后台与电池优化排查。

耗电偏高也不应只看应用排名。VPN 进程会承担其他应用经过隧道的流量，系统统计可能把一部分网络消耗归入它。比较相近使用时段的亮屏时间、传输活动与网络类型，再检查是否存在过密健康检查、频繁订阅刷新或持续重连。空闲时仍有大量日志，先找重复请求来源，而不是立刻关闭所有 DNS 功能。

iOS：检查隧道与按需连接

iOS 可从安装包页面进入 Clash Plus 的 App Store 页面，官网为 clashplus.io。连接异常时，先检查系统 VPN 配置与应用中的当前配置是否一致，再确认其他网络扩展是否参与接管。界面切到后台并不代表隧道退出；应以系统 VPN 状态和新请求的结果共同判断。

若启用了按需连接，系统可能在网络变化后自动重建隧道。手动断开后又立即连接，不一定是操作未生效，应检查当前按需规则及适用网络。出现 Wi-Fi 正常、蜂窝网络失败时，先确认应用的蜂窝数据权限，再核对当前网络能否访问订阅和出口。手机网络切换会改变原连接的源地址，少量长连接中断需要重新建立。

切网、认证门户与局域网访问

从 Wi-Fi 切到蜂窝网络后，等待系统网络稳定，再重新发起目标请求。若仍失败，先重连 VPN，不要直接删除配置。公共 Wi-Fi 的认证页面可能依赖本地网络或特定域名，必要时暂停代理完成认证，然后再开启。若系统始终阻止隧道外流量，还要按前述 VPN 策略检查，避免认证请求被拦在无法建立的隧道之前。

手机投屏、打印或访问家庭服务器失败时，检查局域网地址是否被错误送入远端，以及 VPN 设置是否允许所需的本地访问。不要为了一个打印机把全部流量改为直连；应记录目标内网地址与域名，使用范围尽可能小的规则处理。应用使用设备发现协议时，仅添加一个 TCP 目标规则也未必足够，还需考虑本地广播或组播行为。

移动端复现记录至少包含系统平台、接入网络、锁屏前后、VPN 是否保留以及失败应用范围。不要通过公开分享完整配置来求助。恢复后依次测试前台访问、短时锁屏、Wi-Fi 与蜂窝切换、局域网访问；基础概念可查疑难解答，重新导入配置则回到入门指南的配置步骤。