手机端 Clash 耗电快怎么办:后台保活与省电策略设置

先区分持续耗电与后台断连

先做两件事：查看系统电池统计，再记录锁屏后的连接表现。持续发热、后台数据增长与锁屏后代理断开，属于不同问题。前两项需要减少实际网络活动；后一项才需要检查后台限制。直接把所有省电限制关闭，可能恢复连接，也可能让原有的高频测速继续消耗电量。

安卓移动客户端通常通过系统 VPN 接口接管流量，mihomo 等内核负责解析配置、匹配规则与处理连接。iOS 客户端则通常使用 Network Extension 中的隧道扩展。VPN 图标表示隧道处于连接状态，不代表手机一直在高负载运行，也不能仅凭图标判断耗电原因。

建立一次可复查的基线

1. 记录手机型号、系统版本、客户端版本与内核版本。内核信息通常在客户端的「关于」或运行日志中，菜单名称以实际应用为准。
2. 固定使用同一 Wi-Fi、同一个节点与规则模式，暂停系统更新、照片备份和大文件下载。
3. 锁屏观察 60 分钟，记下起止电量、是否掉线、客户端后台流量及日志中的重连次数。
4. 一次只修改一类设置，再重复观察。至少做两轮，避免把电量显示的整数跳变当作确定结论。

例如，某轮从 80% 降到 77%，另一轮从 80% 降到 78%，只说明这两轮分别下降了 3 与 2 个百分点。这是记录方法示例，不是本站实测结果；短时差异还会受到信号、温度和电池估算影响。

安卓后台保活：只放行必要的客户端

先保持默认电池策略。如果锁屏后连接正常，就不必额外授予无限制后台权限。只有在锁屏后服务被终止、VPN 图标消失，或日志显示进程重新启动时，再检查客户端的电池优化设置。

按系统找到电池设置

• Pixel / 接近原生的 Android 14：长按客户端图标 →「应用信息」→「应用电池用量」→ 检查「允许后台使用」。部分系统还会显示「不受限制」「已优化」「受限制」三个选项。
• 三星 One UI 6：「设置」→「应用程序」→ 选择客户端 →「电池」→「不受限制」。再检查「设置」→「电池」→「后台使用限制」，避免客户端被列入深度休眠名单。
• 其他安卓系统：在应用信息中查找「耗电管理」「后台运行」或「自启动」。不同厂商和系统更新会调整菜单名称，先按实际页面确认，不必照搬其他手机的路径。

自启动控制开机或进程被结束后的启动机会；电池优化控制后台执行限制；最近任务锁定只影响部分厂商的清理行为。三者不是同一个开关。逐项修改并记录结果，不要同时给所有联网应用加入白名单。

始终开启 VPN 不等于省电

安卓系统的「始终开启 VPN」主要用于维持 VPN 连接策略。「阻止未使用 VPN 的连接」则会在隧道不可用时限制其他网络访问。它们不是电池优化开关，也不能修复节点本身不稳定的问题。只有确实需要持续接管流量时才启用，并提前验证重启、切换网络与锁屏后的恢复行为。

iOS 后台刷新：与 VPN 隧道分开设置

在 iOS 17 或 iOS 18 中，可从「设置」→「通用」→「后台 App 刷新」检查应用权限。这个设置主要影响普通应用的后台刷新机会，不能把它理解为 VPN 隧道的总开关。承载流量的隧道扩展与客户端主界面有不同的运行机制；关闭后台刷新不必然断开 VPN，开启它也不保证隧道永不停止。

• 如果只是手动导入配置、手动更新订阅，可以先关闭客户端主应用的后台刷新，再测试隧道是否正常。
• 如果依赖自动订阅更新，应确认客户端是否支持该功能、是否需要后台刷新，以及系统实际允许的执行条件。
• 从「设置」→「电池」检查活动记录；开启低电量模式后，再观察刷新任务与连接恢复是否受到影响。

不要把安卓的“后台锁定”经验套到 iOS。也不要反复从应用切换器划掉客户端来测试省电：强制退出主应用可能影响后续后台任务，具体隧道行为仍取决于客户端实现。先使用客户端内的连接开关做明确的启停对照。

按需连接减少非必要在线时间

如果客户端提供按需连接、可信 Wi-Fi 或网络变化触发选项，先明确哪些网络需要代理，再设置触发条件。按需连接管理的是隧道何时建立，不是节点测速频率。规则过多或条件互相冲突可能导致网络切换时反复连接；先从一个条件开始，验证 Wi-Fi 与蜂窝切换后再增加其他条件。

测速间隔：减少批量探测与重复任务

优先检查自动策略组和代理提供者的健康检查。对 40 个节点每 60 秒执行一次探测，按所有节点都参与的一轮计算，每小时约有 2400 次探测；改为 600 秒则约为 240 次。这是计划请求数估算，实际数量还受懒惰检查、失败重试和实现细节影响，不能直接换算成固定电量。

url-test 的移动端起点

下面是 mihomo 的策略组片段，时间单位为秒。节点名称必须与现有配置中的名称一致；不要把片段直接覆盖到整份订阅。优先在客户端支持的覆写或合并功能中修改，避免下一次订阅更新还原设置。

proxy-groups:
  - name: 移动自动选择
    type: url-test
    proxies:
      - 日常节点
      - 备用节点
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 100
    lazy: true

• interval: 600：把定时测速间隔设为 10 分钟，适合先做省电对照；它不是所有配置的最优值。
• tolerance: 100：以毫秒为单位提供切换容差，减少因小幅延迟变化触发的切换。它不是连接超时时间。
• lazy: true：组未被使用时减少定时探测，具体触发行为以当前 mihomo 版本为准。
• url：这里是探测地址，不是订阅地址。确认当前网络能稳定访问它，避免把探测目标故障误判为全部节点故障。

如果只使用一个可靠节点，可先用手动选择组做对照。不要一边缩短自动测速间隔，一边开启客户端的全节点周期测速。还要检查 proxy-providers 下的 health-check：它可能与策略组形成两套探测任务。减少重复任务后，再根据断线恢复需求调整频率；较长间隔也意味着发现故障可能更慢。

订阅与规则集：更新频率按内容变化设置

订阅更新、代理提供者更新、规则集更新与节点测速是四种不同任务。订阅可能包含整份配置；代理提供者主要提供节点；规则提供者加载规则内容；测速只验证节点可用性。把它们都设成每分钟运行，通常不能带来相应的日常收益。

这些值用于建立对照，不是对所有服务的统一要求。节点经常变动的订阅可以缩短更新周期；变化较少的规则集可以维持每日更新。mihomo 的 HTTP 类型 rule-providers 中，interval: 86400 表示 24 小时；客户端完整订阅的自动更新间隔可能使用分钟或小时，填写前一定确认界面单位。

日志保留可定位信息即可

日常可使用 log-level: warning，需要定位断连时临时切换到 info，复现后再恢复。持续 debug 会增加日志生成与处理开销，长期开着实时连接面板也会增加界面刷新任务。减少日志前先保存关键错误记录，否则无法判断是认证失败、DNS 超时还是隧道重启。

TUN、DNS 与弱信号：检查实际流量来源

移动端的 VPN 接管不能简单等同于桌面系统代理开关。是否能按应用绕过、是否显示 TUN 选项，取决于客户端与平台能力。安卓部分客户端支持按应用分流，可以让确实不需要代理的应用绕过；iOS 的普通个人 VPN 场景不能照搬安卓的应用排除列表。

先确认大流量来自哪个应用，再检查规则命中。视频自动播放、云盘同步和系统下载会持续占用无线网络，即使客户端自身没有测速也会耗电。把目标交给 DIRECT 可以减少不必要的远程代理路径，但不等于流量完全绕过 VPN 接管，更不等于停止传输。

不要把 DNS 模式当成单独的省电开关

• 先找重复解析失败、DNS 超时和连接重试，再修改解析配置。正常工作的 Fake-IP 不应仅因耗电排名靠前就被停用。
• 保持解析路径明确。内核 DNS、系统加密 DNS与其他 VPN 类工具叠加时，应检查是否出现无法访问的解析目标或循环转发。
• 网络切换后偶尔重建连接属于正常现象；同一网络下持续重试，则需要核对节点可达性、解析结果与日志时间。

蜂窝弱信号会增加无线通信开销。在同一地点先比较 Wi-Fi 与蜂窝，再比较两个节点，避免把信号问题归因于代理协议。延迟最低的节点也不一定最省电：稳定传输、少重试和少切换通常比一次测速的低数字更有参考价值。

按三轮对照确定保活与省电的平衡

1. 第一轮，减少后台任务：固定节点，测速设为 600 秒，规则集设为每日更新，关闭持续调试日志，保持系统电池策略不变。
2. 第二轮，验证后台限制：只有锁屏掉线时，才给安卓客户端放宽电池限制；iOS 则分别检查主应用刷新与隧道连接状态。
3. 第三轮，检查实际使用：恢复日常应用，记录视频、同步与蜂窝使用量，观察耗电是否随这些活动增长。

最终保留能满足锁屏连接、网络切换恢复与日常访问的最少后台任务。如果出现持续发热、短时间大量流量或每分钟重复重启，先暂停连接、保存脱敏日志，再前往故障排查定位。日志分享前应移除订阅地址、令牌、节点密码和可识别个人的信息。

更换客户端时，先确认操作系统与内核兼容性，不要同时更换客户端、节点和全部规则。需要重新配置时，可按使用指南逐项恢复，保留一份已经验证稳定的配置作为对照。