手机挂 Clash 耗电异常排查:Android 后台策略与省电设置清单

掉电两成先别怪客户端:定位问题的 3 个信号

手机挂着代理过夜,早上起来发现掉了 20%~30% 的电量,第一反应容易归咎到客户端本身。但代理软件的常驻耗电主要来自三个可量化的环节:系统是否允许它在后台持续运行、网络层是否频繁唤醒 CPU、以及规则匹配是否消耗多余算力。判断到底是哪一环出问题,先看三个信号。

信号一:打开系统设置里的电池详情,看 Clash 客户端的「后台活动时长」是否接近整夜时长。如果接近,说明它没有被系统限制,处于持续唤醒状态,这本身是正常的代理工作方式,不是异常。信号二:看同一时段的「唤醒锁定次数」或「App 待机异常」提示,次数异常高往往意味着探测间隔设置过短或者规则命中不稳定,导致频繁重连。信号三:对比不开代理时的待机掉电速度,如果差距在 5% 以内,说明耗电大头其实是其他后台应用,不该继续在客户端设置上纠结。

系统省电策略是头号变量:后台白名单逐项设置

Android 从 Doze 机制开始,各厂商定制系统又叠加了一层更激进的省电策略,这是导致代理频繁掉线、进而触发重连风暴的最常见原因。核心逻辑很简单:系统判定 App 长时间处于后台且屏幕关闭后,会限制其网络访问和 CPU 唤醒,代理进程被冻结后,TUN 虚拟网卡的流量转发随之中断,手机重新联网时又要重建一次连接,这个反复重连的过程才是真正的耗电大户。

不同厂商系统的设置入口和限制强度都不一样,逐项检查以下几处:

• MIUI(小米):设置 → 应用设置 → 应用管理 → 找到 Clash 客户端 → 省电策略选择「无限制」,同时关闭「自启动管理」里对应的限制项。
• ColorOS / realme UI(OPPO/realme):电池 → 应用耗电管理 → 找到客户端 → 允许后台运行 + 允许高耗电,并在「其他设置」里关闭「休眠电量优化」对该应用的限制。
• OriginOS / Funtouch OS(vivo/iQOO):i管家 → 应用管理 → 权限管理 → 后台高耗电,把客户端加入白名单;同时关闭系统自带的「智能省电」对该应用的限制。
• EMUI / HarmonyOS(华为):电池 → 更多电池设置 → 应用启动管理,将客户端改为「手动管理」并勾选自启动、关联启动、后台活动。
• One UI(三星):设置 → 电池 → 后台使用限制,把客户端从「休眠中的应用」或「深度休眠应用」列表移出。
• 原生 Android / Pixel:设置 → 应用 → 找到客户端 → 电池 → 将「电池使用情况」改为「不受限制」。

这一步几乎决定了代理在后台能否稳定存活。没有做系统白名单,后续所有客户端内部的省电调优都是治标不治本。

TUN 模式常驻与省电的取舍

TUN 模式通过虚拟网卡接管全局流量,不依赖单个 App 设置代理,兼容性最好,但代价是它需要一个常驻的后台服务持续监听网络接口变化。这个服务本身耗电极低,真正拖累电量的是配合不当的省电策略:系统一边限制后台进程唤醒,TUN 服务却需要随时响应网络切换(比如从 Wi-Fi 切到移动数据),两者冲突就会导致服务被杀后自动重启,重启过程伴随一次完整的路由表重建和 DNS 重新解析,这才是耗电尖峰所在。

如果确认不需要全局透明代理(比如只是给个别 App 分流),可以考虑关闭 TUN 模式,改用系统 VPN 接口或者应用级代理设置,减少一个常驻网络服务。但如果依赖 TUN 做全局分流或者需要拦截 UDP/ICMP 流量,保留 TUN 模式的同时把上一节的系统白名单做到位,比关闭 TUN 更划算。

测速间隔与并发探测:被忽略的耗电来源

策略组配置里的 url-test 类型会按固定间隔对节点发起延迟探测,这个间隔由 interval 字段控制,单位是秒。很多订阅默认写得很短(比如 60 秒甚至更短),意味着客户端每分钟都要唤醒网络模块、对每个节点发起一次 HTTP 请求。夜间待机时手机本该进入深度休眠,却被这类定时探测反复唤醒,累积下来是一笔不小的电量支出。

proxy-groups:
  - name: 自动选择
    type: url-test
    proxies: [节点1, 节点2, 节点3]
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

把 interval 调大到 300~600 秒,对绝大多数使用场景没有明显影响,却能显著减少夜间唤醒次数。如果策略组里节点数量多,探测是并发发起的,节点越多单次唤醒的耗时和耗电也越高,没必要把订阅里几十个节点全部塞进同一个自动测速组,精简到常用的 5~10 个足够。

规则复杂度拖累 CPU:如何精简

规则段的匹配是按顺序从上到下逐条比对的,规则条数越多、越靠后命中,单次连接建立时消耗的 CPU 周期就越长。一份几千条规则的社区规则集,如果放在规则列表最前面且大量域名靠字符串精确匹配而非分类规则集(RULE-SET),每一次新连接都要跑一遍冗长的比对逻辑,长期高频次建连(比如后台 App 保活、推送心跳)会让 CPU 占用曲线出现频繁的小尖峰,这些尖峰叠加起来也是耗电的一部分。

精简思路很直接:把命中率高的规则(比如直连的国内域名、常用的分流域名)放在规则列表靠前位置,减少平均比对次数;尽量使用 RULE-SET 引用维护好的分类规则集而不是逐条堆砌单条域名规则;删除明显重复或已经被上层规则覆盖的条目。规则集本身的加载和索引方式已经做了优化,比逐条明文规则效率更高,规则数量少一个量级,匹配开销也随之下降。

可照做的省电设置清单

按下面的顺序逐项过一遍,基本能把非客户端本身导致的耗电异常排除掉:

1. 打开系统电池设置,把 Clash 客户端加入后台运行白名单,取消所有厂商定制的「智能省电」「休眠优化」限制。
2. 检查自启动权限、关联启动权限是否被关闭,后台被冻结的进程即便加了白名单也可能无法自行唤醒。
3. 确认是否真的需要 TUN 模式;不需要全局分流时,改用应用级代理可以少一个常驻服务。
4. 打开配置文件,把 url-test 策略组的 interval 调整到 300 秒以上,减少定时唤醒频率。
5. 精简自动测速组里的节点数量,只保留常用的几个,减少单次探测的并发开销。
6. 检查规则段条数,优先使用 RULE-SET 引用规则集,把高命中率规则挪到列表靠前位置。
7. 对比开启代理前后的待机掉电速度,如果差距仍在 10% 以上,再回头逐项复查前面几步是否生效。