Clash 安卓耗电异常排查：后台保活、厂商省电策略与 VPN 常驻

先确认耗电来自哪里

安卓状态栏出现钥匙或 VPN 图标，只能说明系统正在维持一条 VPNService 通道，不能直接证明 Clash 内核正在持续高负载。mihomo 内核、客户端界面、移动网络、Wi-Fi 扫描和被代理应用都会计入不同的电量项目。排查前先把“整夜掉电 20%”拆成可复现的数据。

做一轮可对照的 8 小时测试

1. 把电量充到 80% 以上，关闭游戏、云相册备份和系统更新。
2. 记录当前网络类型、信号强度、Clash 模式、所选节点和配置更新时间。
3. 第一晚保持 Clash 关闭，锁屏静置 8 小时，记录掉电比例。
4. 第二晚在相同地点开启 Clash，使用同一个 Wi-Fi 和节点，再静置 8 小时。
5. 进入「设置」→「电池」→「电量使用情况」，分别查看 Clash、Android 系统、移动网络和主要应用的占比。

例如，关闭 Clash 时 8 小时下降 3%，开启后下降 6%，可把额外 3 个百分点视为代理链路及其唤醒活动的近似成本。如果两轮分别下降 4% 和 19%，同时“移动网络”位居首位，应优先检查弱信号和 Wi-Fi 断连，而不是立即修改代理规则。

用系统工具观察后台活动

Android 14、Android 15 的菜单名称会被厂商调整，但通常可以在「设置」→「电池」→「电量使用情况」中点开 Clash，查看前台时间和后台时间。后台时间接近整晚属于 VPN 常驻的正常表现；异常信号是锁屏后 CPU 使用持续偏高、设备保持温热，或者 Clash 的耗电曲线出现连续陡坡。

具备 ADB 环境时，可以在电脑上补充查看系统统计。以下命令不会修改客户端配置：

adb shell dumpsys batterystats
adb shell dumpsys deviceidle
adb shell dumpsys connectivity
adb shell dumpsys vpn_management

不同安卓版本提供的服务项可能不同。如果最后一条提示找不到服务，使用前两项即可。重点看锁屏期间的唤醒次数、网络活动和 Doze 状态，不要只根据某一次瞬时 CPU 数值下结论。

先关掉高频测速与自动更新

很多耗电问题并非来自正常转发，而是客户端在后台重复执行 URL-Test、订阅更新或节点健康检查。一次测速通常会对策略组内多个节点建立连接；若一个组包含 80 个节点，并把间隔设为 60 秒，理论上一小时可能触发数千次连接尝试。弱网环境下的超时与重试会进一步拉长无线模块的活跃时间。

检查策略组的测速间隔

打开当前配置，查找包含 type: url-test、type: fallback 或 type: load-balance 的策略组。常见字段如下：

proxy-groups:
  - name: 自动选择
    type: url-test
    proxies:
      - 节点 A
      - 节点 B
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 80
    lazy: true

interval: 600 表示每 600 秒检查一次，比 60 秒更适合手机常驻。mihomo 支持的 lazy: true 会在策略组长期未被使用时减少不必要的探测。具体字段是否由客户端配置编辑器保留，要以导出后的 YAML 为准；部分订阅会在每次更新时覆盖本地修改。

客户端菜单名称并不统一。常见入口是「配置」→「当前配置」→「覆写」或「设置」→「订阅」→「自动更新」。若界面只允许设置订阅更新周期，策略组测速间隔仍需要在配置提供方或本地覆写中调整。

控制规则规模与 DNS 开销

Clash 的规则匹配通常不是手机常驻耗电的主要来源，但配置体积过大、规则集频繁更新、DNS 查询反复回退时，仍会增加内存占用和网络唤醒。问题常出现在多套规则重复加载，或者同时启用大量不参与实际流量判断的 provider。

减少重复规则与过密更新

打开配置日志，检查启动时载入的 rule-provider 数量。相同域名集合不应同时以远程规则集、内联 DOMAIN-SUFFIX 和脚本覆写三种方式重复存在。远程规则集更新周期建议按内容变化速度设置，广告或常规域名列表使用 12 至 24 小时通常足够，地理数据库按天更新也没有实际收益。

rule-providers:
  common-direct:
    type: http
    behavior: domain
    interval: 86400
    path: ./ruleset/common-direct.yaml

interval: 86400 代表 24 小时。规则提供器的下载由客户端或内核发起，频繁更新会唤醒网络并写入存储。若配置每小时更新一次，而规则文件本身数周才变化，应直接延长周期。

检查 DNS 循环与失败重试

DNS 配置异常会表现为网页首次打开缓慢、日志重复出现 timeout、客户端在待机时仍持续发起解析。Fake-IP 模式本身适合规则分流，不等于高耗电；真正需要排查的是 nameserver 不可达、fallback 反复超时，以及 DoH 地址必须先解析自身域名形成的依赖链。

• 为域名形式的 DoH 服务器配置可达的 bootstrap 解析路径。
• 避免在系统私人 DNS、浏览器安全 DNS和 Clash DNS 中堆叠多层同类转发。
• 确认局域网 DNS 没有把请求转回手机上的 Clash 监听端口。
• 日志持续出现 3 秒或 5 秒超时时，先替换不可达的上游，不要单纯增加并发服务器数量。

常见 mixed-port 是 7890，但 Android 客户端通过 VPNService 接管流量时，应用通常不需要手动填写该端口。给浏览器额外配置 127.0.0.1:7890，再叠加系统 VPN，可能造成路径混乱。除非正在测试局部代理，应让应用流量只经过一套入口。

TUN、VPNService 与常驻图标怎么取舍

安卓上的 Clash 类客户端通常通过系统 VPNService 建立虚拟网络接口，再把流量交给 mihomo 内核处理。状态栏持续显示 VPN 图标是系统行为。只要代理处于启用状态，这条服务就应保持存在；强行隐藏通知、冻结进程或定时清理后台，反而可能造成隧道频繁重建。

哪些场景值得全天常驻

• 消息、协作和开发服务需要随时按规则分流。
• 手机在 Wi-Fi 与移动数据之间频繁切换，需要自动恢复代理路径。
• 配置含直连规则，大部分国内流量不会绕行远端节点。
• 客户端设置了合理的测速与订阅更新周期。

如果每天只在固定应用中短时使用代理，按需开启更节电。全天常驻的价值是连接连续性，不是速度提升。关闭 Clash 后，系统会撤销 VPN 接口；再次开启时，现有 TCP 连接可能需要重建，这是正常现象。

常规 VPN 与始终开启 VPN

Android 原生设置中通常可以进入「设置」→「网络和互联网」→「VPN」→ 对应 Clash 项目的齿轮按钮，看到“始终开启的 VPN”。厂商系统也可能把入口放在「更多连接」→「VPN」。打开后，系统会尝试持续拉起该 VPN 应用；如果同时打开“屏蔽未使用 VPN 的连接”，那么 Clash 启动失败时，其他应用可能完全断网。

TUN 模式会接管更广泛的 TCP、UDP 流量，适合不遵循系统 HTTP 代理的应用。在 Android 客户端中，VPNService 本身通常已经承担 TUN 接入职责，不应照搬桌面端“系统代理加 TUN”的组合思路。客户端若提供“绕过局域网”“仅代理所选应用”或“分应用代理”，优先通过这些选项缩小处理范围。

各厂商后台白名单设置

后台被系统清理与持续耗电是两个方向相反的问题。白名单的目标是避免进程被错误终止，不是把所有权限全部打开。建议先允许自启动和后台运行，再观察 24 小时；只有锁屏后隧道仍会断开，才继续调整电池优化。

系统版本、地区和设备型号会改变菜单名称。找不到对应入口时，在设置搜索框输入“电池优化”“后台活动”或“自启动”。调整后锁屏 30 分钟，再从另一设备向手机发送消息，随后切换一次 Wi-Fi 与移动数据，确认 VPN 图标和网络连接是否连续。

最近任务页的“锁定应用”只能减少一键清理造成的终止，不能替代系统电池白名单。相反，把 Clash 加入白名单之后仍频繁手动清理最近任务，也可能让前台服务被中断。稳定配置应尽量减少这类相互冲突的操作。

按日志定位异常连接与循环重启

如果手机锁屏后发热，打开 Clash 的日志页并按时间排序。正常待机可能出现少量连接、规则集检查或网络变化记录；异常情况通常呈现为同一条错误每几秒重复一次。

重点识别四类重复记录

1. DNS timeout：上游解析不可达，内核持续等待并尝试其他服务器。
2. connection refused：本地端口或远端服务拒绝连接，某个应用仍在快速重试。
3. network changed：Wi-Fi 信号差或双卡数据切换导致隧道反复重建。
4. provider update failed：订阅或规则集地址不可达，更新周期又设置得过短。

先把日志级别保持在 info。debug 或 trace 会产生更多日志写入，只适合短时复现。记录 5 至 10 分钟后恢复普通级别，并保存错误出现的时间、网络类型和对应应用。

分应用代理也可用于定位。先让 Clash 仅处理浏览器，锁屏观察；若耗电恢复正常，再逐批加入社交、视频和同步工具。某个批次加入后后台连接数量明显增加，就检查该组应用的推送、自动播放、云备份或轮询设置。代理负责转发连接，但发起频率通常由具体应用决定。

一套从低风险到高影响的排查顺序

不要同时修改十几个开关，否则无法判断哪一步有效。按下面顺序执行，每一步至少观察一个完整的 8 小时待机周期。

1. 建立关闭 Clash 与开启 Clash 的待机基线，确认额外掉电比例。
2. 把 URL-Test 间隔提高到 600 秒以上，订阅更新改为 12 至 24 小时。
3. 关闭客户端延迟面板，日志级别恢复为 info。
4. 检查 DNS timeout、provider 更新失败和网络切换循环。
5. 精简重复规则集，把规则提供器周期改为 86400 秒。
6. 通过分应用代理定位持续产生后台连接的应用。
7. 允许 Clash 后台活动与自启动，避免省电策略反复终止服务。
8. 确有全天连接需求时，再启用系统“始终开启的 VPN”。

最后还要排除客户端版本与配置不兼容。升级基于 mihomo 的客户端后，如果旧配置立即触发崩溃或循环重启，可先导出配置，再新建一份只包含一个节点、一个策略组和基础 MATCH 规则的最小配置。最小配置待机正常，说明问题集中在原配置；最小配置仍异常，则继续检查客户端版本、系统 VPN 权限和厂商后台策略。

安卓代理常驻的合理目标是：VPNService 稳定、锁屏后连接连续、测速和更新按低频执行、设备不持续发热。后台时间长并不等同于高耗电，VPN 图标常驻也不代表故障。用对照测试、日志和逐项修改定位，通常比反复清理进程更快得到稳定结果。