耗电排查的基本思路:先分类,再定位
移动端反馈的"耗电严重"很少是单一原因,通常是配置层、系统层两类问题叠加的结果。配置层指的是 Clash 或 mihomo 内核本身的运行参数,比如规则集刷新频率、日志输出级别、DNS 查询方式;系统层指的是 Android 或 iOS 对后台进程的省电限制,以及应用被系统判定为"非活跃"后触发的降频、休眠策略。排查时建议按下面的顺序逐层缩小范围:
- 先确认是否只在锁屏/后台时耗电异常,还是前台使用也偏高——前者多为系统调度问题,后者多为配置或代理链路问题。
- 查看内核日志输出量,判断是否存在频繁重连、DNS 超时重试、规则命中失败导致的循环请求。
- 检查订阅与规则集的自动更新周期,确认是否设置了过短的轮询间隔。
- 确认系统电池管理里客户端是否被标记为"受限"而频繁被唤醒重连。
下面各章节按这四个层面展开,给出具体的检查方式和调整参数。
规则集与订阅轮询:更新周期设置不当是常见诱因
mihomo 内核支持在配置文件中为 rule-providers 设置独立的 interval 字段,单位为秒,用于控制该条规则集的自动拉取周期。部分客户端图形界面默认沿用配置文件里写死的间隔,如果订阅作者将间隔设置为几分钟级别,手机会在锁屏状态下周期性唤醒网络模块发起 HTTP 请求,这是移动端耗电排查中最容易被忽略的一项。
rule-providers:
reject-list:
type: http
behavior: domain
url: "https://example.com/rules/reject.yaml"
path: ./rules/reject.yaml
interval: 86400
建议将非高频变动的规则集(广告拦截、直连列表等)的 interval 调整到 43200 秒(12 小时)以上,仅对分流规则频繁变化的场景保留较短周期。同理,订阅本身的自动更新(profile 层面的 update-interval 或客户端 GUI 里的"自动更新订阅"选项)也应避免设置为 1 小时以内,否则手机会在后台被反复唤醒执行一次完整的下载、解析、重载配置流程,这个流程本身涉及磁盘写入和内核重启,单次耗电成本并不低。
日志级别与 DNS 并发:配置文件里容易被忽略的耗电开关
日志级别设置为 debug 或 info 时,内核会对每一次连接建立、规则匹配、DNS 解析都写入日志条目,持续的磁盘 I/O 与字符串格式化操作会带来额外的 CPU 占用。移动端日常使用建议将日志级别调整为 warning,只有在主动排查连通性问题时才临时切回 debug,排查完成后及时切回。
log-level: warning
DNS 部分同样值得检查。启用 enhanced-mode: fake-ip 配合多个 nameserver 并发查询是常见配置,但如果同时配置了过多的上游 DNS(尤其是境外服务器)且未设置合理的 fallback-filter,每一次域名解析都会并发发出多组请求并等待超时判定最优结果,这在移动网络信号不稳定的场景下会显著增加无线模块的活跃时长。
dns:
enable: true
enhanced-mode: fake-ip
nameserver:
- 223.5.5.5
- 119.29.29.29
fallback:
- "tls://8.8.8.8:853"
fallback-filter:
geoip: true
geoip-code: CN
精简 nameserver 列表到两到三个响应稳定的服务器,并让 fallback 仅在明确判定为境外域名时启用,可以减少不必要的并发解析请求。
如果配置中启用了 TUN 模式并同时开启了逐包路由日志或连接追踪功能,移动端 CPU 占用会比单纯的系统代理模式更高。非必要场景下,普通上网可优先使用系统代理模式,仅在需要透明代理全局流量或处理 UDP 转发时才切换到 TUN 模式。
Android:电池优化白名单与后台自启动权限
Android 系统从 6.0 引入的 Doze 模式与各厂商定制系统(如基于深度定制的省电管理框架)会对长期驻留后台且屏幕熄灭后仍保持网络连接的应用进行限制,具体表现为服务被系统主动杀死后由 VPN 框架尝试重连,重连过程会短时间内多次唤醒网络硬件,造成"看似耗电但实际是被反复重启"的情况。解决方式是将客户端加入电池优化白名单,并保留必要的自启动权限:
-
打开系统电池管理设置
进入「设置 → 电池 → 电池优化」或对应厂商系统里的「省电策略」页面,找到 Clash 客户端应用。
-
将应用设为不受限制
选择「不优化」或「允许后台活动」,避免系统在锁屏后主动挂起该进程的网络连接。
-
检查自启动与关联启动权限
在应用权限管理里确认「自启动」处于开启状态,部分系统还需要额外允许「关联启动」,否则 VPN 服务被系统回收后无法自行恢复,只能靠用户手动重新打开应用。
-
确认通知常驻权限未被关闭
VPN 服务依赖前台通知维持进程优先级,如果通知权限被系统或用户手动关闭,服务的存活时间会明显缩短,进而触发更频繁的重连循环。
需要说明的是,加入白名单本身不会增加耗电,它只是阻止系统频繁杀死并重启进程。真正的耗电来源仍是前两章提到的规则轮询周期与 DNS 并发设置,白名单调整解决的是"连接不稳定导致的间接耗电",两者需要同时处理才能看到明显效果。
iOS:按需连接与 VPN 描述文件的省电配置
iOS 平台的网络扩展框架(NetworkExtension)对后台代理进程的限制更为严格,系统会根据设备的电量状态、网络类型、使用频率动态调整扩展进程的调度优先级。客户端在 iOS 上通常以 VPN 配置的形式接入系统,配置文件中的「按需连接」(On-Demand)规则直接决定了 VPN 隧道的建立时机,设置不当会导致隧道在不必要的场景下反复建立与断开:
- 进入客户端设置里的 VPN 配置管理页面,找到「按需连接」或「On-Demand Rules」选项。
- 确认规则不是设置为「始终连接」,而是按网络类型区分:例如仅在使用移动数据或指定 Wi-Fi 名称之外的网络时才自动建立隧道。
- 如果配置了「排除特定 Wi-Fi 不连接」,检查名单是否覆盖了家庭、办公室等长期停留的可信网络,避免在这些场景下 VPN 隧道无意义地保持建立状态。
- 在系统设置的「VPN 与设备管理」中确认对应描述文件状态正常,异常状态下系统会以更高频率尝试重新协商隧道,同样会增加耗电。
iOS 上的网络扩展进程被系统挂起后无法像常规应用一样保持后台活跃,规则集与订阅的自动更新在扩展进程休眠期间不会执行,这是设计上的限制而非故障,不需要额外排查。真正需要关注的是隧道建立频率,而不是扩展进程是否"一直在跑"。
此外,iOS 上开启的日志级别同样建议保持在较低档位,原因与 Android、桌面端一致:扩展进程一旦被唤醒执行高频日志写入,会延长该次唤醒的持续时间,间接影响系统对该扩展进程调度优先级的判定。
长期监控:借助面板工具持续观察耗电趋势
完成以上调整后,建议用客户端自带的连接面板或流量统计功能观察一段时间的运行状态,而不是仅凭主观感受判断是否解决问题。重点关注三个指标:活跃连接数是否在锁屏后仍持续增长、DNS 查询次数是否明显高于正常上网所需的数量级、规则集重载事件在日志里出现的频率。如果活跃连接数在锁屏后没有明显下降,通常说明存在后台应用持续发起网络请求的情况,这类问题的根源往往在系统层的其他应用而非 Clash 本身,可以通过临时开启分应用模式排查具体是哪个应用在锁屏后仍保持活跃连接。
耗电问题的排查本质是一次逐层排除,配置层的规则轮询周期、日志级别、DNS 并发设置决定了内核本身的基础负载,系统层的电池优化白名单与按需连接规则决定了后台存活方式是否高效。两者任一环节设置不当都会在续航表现上被放大,建议按本文顺序逐一核对,而不是只调整其中一项后就下结论。