Clash 手机端耗电过快排查：后台保活、健康检查间隔与省电策略设置

先区分流量转发耗电与待机异常

手机开启 Clash 后，系统电量榜中的 VPN 客户端占比可能上升。这不等于客户端自身一直在高负载运行。Android 的流量归属和耗电估算会受到 VPN 转发影响；视频、下载和同步产生的部分网络开销，可能出现在 VPN 应用的统计中。判断问题应同时看整机掉电、屏幕使用时间、网络类型和客户端日志，而不是只看应用排名。

本文主要面向使用 Clash Meta for Android 或其他 Mihomo 内核 Android 客户端的设备。Clash Verge Rev 是桌面客户端，不能把它的服务模式、系统代理菜单直接套到手机上。Android 通常通过 VpnService 建立本地 VPN 接口接管流量；其他平台客户端的后台机制和菜单不同，下面的 Android 电池设置不适用于 iOS。

建立可比较的电量记录

用同一网络做三组对照

在 Android 中先查看「设置」→「电池」→「电池用量」，再进入对应客户端的应用详情。不同系统可能将入口命名为「耗电排行」或「应用耗电管理」。记录前台时间、后台时间和测试起止电量；如果系统提供移动网络活跃时间，也一并记录。

1. 基线组：停止代理服务，在稳定 Wi-Fi 下锁屏 60 分钟，记录整机电量变化。
2. 当前配置组：恢复代理服务，保持相同 Wi-Fi、应用同步设置和锁屏时长，不手动测速。
3. 调整组：只延长健康检查间隔，或只修改后台策略，再重复 60 分钟。

测试期间不要充电，不要同时下载订阅、更新应用或播放音频。移动网络信号差时，基带功耗可能远高于代理计算开销；不要把一次 Wi-Fi 测试与一次弱信号 5G 测试直接比较。电池百分比只有整数精度，60 分钟结果接近时，应延长到 3～6 小时并重复测试。

这类短时顺序测试仍会受到温度、后台任务和电量区间影响。它适合筛选方向，不足以证明某个设置一定节电。保存每次使用的订阅配置和客户端版本，后续才能复现差异。

健康检查间隔：先检查节点数与重复探测

健康检查通过指定 URL 检测节点可用性和延迟。一次检查通常涉及连接建立，使用 HTTPS 时还包含 TLS 交互。节点越多、间隔越短，网络活动越频繁。在移动网络中，密集的小请求也可能延长无线模块的活跃时间。

区分三个容易混淆的间隔

• proxy-providers 下的 interval：远程节点提供者的更新间隔，不是节点测速间隔。
• health-check.interval：节点提供者的健康检查间隔，单位是秒。
• url-test、fallback 等策略组下的 interval：该组按自身机制进行检测的间隔，不能只改 provider 就认定所有探测都已减少。

例如，100 个节点每 60 秒做一轮全量检查，按“每节点一次”的简化模型约为每小时 6000 次尝试；改成 600 秒约为 600 次。这个计算只用于说明量级，不代表真实发包数，实际行为还与惰性检查、节点使用情况、超时和内核实现有关。

从 600 秒开始，而不是持续手动测速

对移动端日常浏览，可先将有关自动检查间隔调整到 600 秒，观察节点故障切换是否仍满足需求。网络经常变化时可以试 300 秒；固定节点且稳定时可以评估 1800 秒。间隔越长，发现故障可能越慢，不能把最长间隔当作统一最优值。

# 合并到现有 proxy-providers 的对应提供者中。
# 保留原有 type、url、path 和订阅更新 interval。
# 此片段不是可直接导入的完整订阅。
proxy-providers:
  mobile:
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600
      timeout: 5000
      lazy: true

其中 interval 单位为秒，timeout 单位为毫秒。lazy: true 用于减少未使用提供者的例行检查，不等于停止所有策略组探测。若原配置的提供者名称不是 mobile，应编辑原有条目，不要额外创建一个缺少订阅地址的新条目。

修改前备份配置；优先使用客户端支持的本地覆写机制，避免订阅更新后被覆盖。保存并重载配置后，短暂查看日志确认加载成功，再根据下一轮检查时间判断是否生效。不要为了验证省电设置而连续点击“全部测速”，那会引入新的测试负载。

后台保活：仅为持续代理开放必要权限

Android 的 VpnService 授权解决“能否建立 VPN”，电池策略解决“后台进程如何被调度”，二者不是同一个权限。已经同意 VPN 授权，仍可能在锁屏后被厂商后台管理限制；反过来，设为不受电池限制，也不能解决失效节点或错误 DNS。

按断连表现选择设置

• 持续代理且锁屏后服务消失：长按应用图标 →「应用信息」→「电池」或「应用电池用量」→「不受限制」。部分系统还需开启「允许后台活动」和自启动。
• 服务稳定、没有锁屏断连：先保留当前后台策略，不必为所有相关应用统一开放权限。
• 只在短时任务中使用：任务结束后在客户端内停止代理服务。只关闭界面或划掉最近任务，不一定停止 VPN。

Android 13、14 等系统的具体页面名称仍随厂商变化。可在设置内搜索「电池优化」「后台运行」「自启动」定位入口。最近任务锁定属于部分厂商的额外机制，不能替代 VpnService 授权，也不能保证系统永远不回收进程。

如果设置过始终开启 VPN，检查「设置」→「网络和互联网」→「VPN」→对应应用旁的设置按钮。启用“无 VPN 时阻止连接”后，一旦服务停止，普通联网也可能被系统阻断。它适合明确需要阻断回落流量的场景，不是省电开关。

DNS 与规则：定位超时，不盲目切换 Fake-IP

DNS 配置错误常表现为网页长时间转圈、应用反复刷新，以及日志持续出现解析超时。耗电来自重复请求和连接重试，而不是“某种 DNS 模式天然高耗电”。Fake-IP 用合成地址维持域名映射，供后续连接和规则匹配使用；切换为真实地址模式并不能自动解决不可达的上游服务器。

1. 先确认时间关联：在客户端「日志」页短暂使用 info 级别，打开一个出现问题的应用，观察是否反复出现 DNS 超时、连接超时或同一域名的失败记录。
2. 检查上游可达性：确认 DNS 服务器能经预期路径访问，特别是需要代理访问的加密 DNS，是否依赖尚未成功解析的代理节点域名。
3. 检查系统专用 DNS：Android「设置」→「网络和互联网」→「专用 DNS」可能影响部分解析路径。记录原设置后再做单变量对照，不要同时更换内核 DNS 和系统 DNS。
4. 复查规则结果：规则模式按顺序匹配，通常由首条命中的规则决定去向。某个高流量应用被错误分配到不稳定节点，会持续重连；先修正规则或策略选择。

不要为“解析更快”堆叠很多 DNS 上游。部分配置会并发查询，更多上游不等于更少请求。已有稳定设置时，优先减少错误路径，而不是复制整段不明来源的 DNS 配置。也不要批量清除缓存来测试续航，这会增加冷启动解析和新建连接。

分应用代理、日志与网络切换的取舍

分应用代理与 DIRECT 规则不是一回事

客户端若提供分应用代理，可只让确有需求的应用进入 VPN。Android 分应用机制能够在 VPN 接口层限定应用范围；而 DIRECT 规则通常仍是在流量进入内核后选择直接出站。这两种方式的处理路径不同，不能把直连规则理解为“完全绕过客户端”。

如果选择“仅代理选中应用”，应实际测试浏览器、消息通知、登录跳转和文件下载。应用可能调用系统下载组件或其他应用完成操作，名单过窄会造成相关连接走不同路径。办公、金融或单位网络场景还应遵守对应的网络使用要求。

排查结束后收回诊断负载

• 将临时开启的 debug 日志恢复为 info 或客户端默认级别；日志级别不能修复连接问题，但详细记录会增加处理与写入。
• 关闭无需常驻的连接监控页面，避免用持续亮屏观察代替锁屏测试。界面刷新与屏幕功耗会干扰结论。
• 检查订阅自动更新频率。若并不需要频繁更新，可评估 12 小时或 24 小时一次；这与 600 秒健康检查是两个独立设置。
• 在 Wi-Fi 与蜂窝网络之间切换后，允许旧连接重新建立。若只在弱信号区域异常，先用稳定 Wi-Fi 对照，不急于更换整份订阅。

移动端 VPN 接管与桌面 TUN 模式都涉及虚拟网络接口，但配置入口不同。不要照抄桌面端“关闭系统代理、开启 TUN”的菜单路径。Android 上优先确认 VPN 服务状态、分应用范围与所用配置是否一致。

按症状收敛设置，保留一份可恢复配置

一套便于开始排查的组合是：保留规则模式，使用已验证可用的节点，将有关自动健康检查先调整到 600 秒，仅在确有后台断连时开放电池限制，并在排查结束后恢复常规日志级别。这是对照起点，不是适用于所有手机的固定参数。

每次只改一类设置，记录修改时间和恢复方式。若要反馈问题，提供手机型号、Android 版本、客户端与内核版本、网络类型、锁屏测试时长，以及去除敏感信息的错误日志。订阅 URL、访问令牌和节点凭据不要直接公开。可复现的记录，比一张耗电排名截图更容易定位问题。