手机开代理耗电快:Android 后台保活、省电白名单与 Clash 设置调整

先区分：正常转发耗电，还是后台反复重启

先做同条件对比，再调整电池白名单。手机开启代理后，多了一层流量转发、加解密和规则匹配，耗电有所增加并不意外。但熄屏后仍持续发热、每隔几分钟出现服务重启、移动网络下待机掉电明显加快，值得单独排查。把所有限制一次性放开，可能解决断连，却不能直接证明耗电原因已经消失。

Android 上的 Clash 客户端通常通过 VpnService 建立本地 VPN 接口，再把选定应用的流量交给内核处理。这与购买远程 VPN 服务不是同一概念；通知栏出现钥匙图标，也不代表全部连接都经过远端代理节点。规则命中 DIRECT 的连接仍可能经过本地转发，只是不走远端节点。

用两组待机记录建立基线

不要拿“昨天开代理、今天没开代理”的全天电量作结论。应用更新、信号变化和屏幕亮度都能改变结果。先完成下面的短时对照，再决定是否需要延长测试。

1. 记录环境：写下手机型号、Android 版本、客户端与内核版本、Wi-Fi 或移动网络、起止电量。版本通常能在客户端的「关于」页看到。
2. 固定条件：使用同一 Wi-Fi、相同位置和相近电量区间；暂停系统更新、云相册备份和大文件下载，不边充电边测。
3. 第一组关闭代理：确认 VPN 服务已经停止，熄屏待机 60 分钟，记录电量和后台网络活动。
4. 第二组开启代理：保持相同应用状态，选择固定节点与规则模式，再待机 60 分钟。不要同时执行“全部测速”。
5. 只改一项后复测：例如先延长健康检查间隔，其他设置不动；至少重复一次，避免把系统电量取整误差当成优化结果。

例如，记录得到关闭时从 80% 到 79%、开启时从 80% 到 77%，只能说明这两次测试相差 2 个百分点，不能据此推算所有手机的全天耗电。这里是记录格式示例，不是客户端实测数据。若一小时差异太小，可延长到 3 小时；移动网络信号较差时，应另做一组，不与 Wi-Fi 数据混用。

后台保活：按需设置电池优化白名单

白名单用于减少后台终止，不是省电开关。只有遇到熄屏断连、服务被清理或反复启动时，才优先调整这项。常驻通知本身不能证明客户端持续高负载；更应观察内核是否反复初始化、连接是否频繁重建。

Android 14 的参考操作路径

以接近原生系统的 Android 14 为例，可进入「设置」→「应用」→「查看所有应用」→选择 Clash 客户端→「应用电池用量」，检查是否被设为「受限」。需要持续代理时，可测试「不受限制」。不同系统更新可能使用「允许后台使用」等名称，以设备实际页面为准。

• 厂商电池管理：在系统设置中搜索「电池优化」「后台活动」或「自启动」。如系统额外提供应用启动管理，只给需要长期代理的客户端授权，不必放开所有应用。
• 最近任务锁定：部分系统提供锁定卡片功能，可减少手动清理时误关，但它不是 Android 通用保活保证，也不能代替电池设置。
• 通知与服务状态：保留客户端运行状态的可见性。Android 13 及以上的通知权限与前台服务运行不是同一开关，不能仅凭通知消失判断 VPN 已停止。
• 省电模式：先确认故障是否只在系统省电模式下发生。测试时暂时保持一致，不要一组开启、一组关闭。

检查“始终开启的 VPN”是否符合需求

原生风格系统一般位于「设置」→「网络和互联网」→「VPN」→对应配置旁的设置按钮。若客户端支持，可看到「始终开启的 VPN」及「屏蔽未使用 VPN 的连接」。后者会在 VPN 不可用时阻断网络；它并不是提升节点稳定性的选项。启用前先理解断线后的行为，不要把系统按设计阻断流量误判为 DNS 故障。

Android 通常只允许每个用户或工作资料同时运行一个基于 VpnService 的服务。另一个 VPN 型防火墙、过滤器或代理应用启动后，可能替换当前服务。遇到来回断开，先检查是否存在这类竞争，而不是继续增加后台权限。

健康检查：先减少探测次数，再考虑更换节点

节点检查会发起实际网络请求。大量节点配合很短的检查间隔，可能增加无线网络唤醒和连接活动。尤其在移动网络下，短而密集的请求可能让无线模块更久地保持活跃；具体影响取决于网络与设备，不能只看每次请求的数据量。

mihomo 中，代理提供者的健康检查位于 proxy-providers 下的 health-check。下面是已有提供者定义的局部片段，不是完整配置；mobile-pool 需要替换为已有提供者名称，原有的类型、地址、路径等字段必须保留。

proxy-providers:
  mobile-pool:
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600
      lazy: true

• interval: 600：健康检查间隔为 600 秒。可从 300～600 秒开始观察，不必为了显示最新延迟每隔几十秒检查一次。
• lazy: true：提供者节点未被使用时，跳过其周期检查。实际是否被视为使用中，取决于策略组引用和使用状态。
• url：应选择当前网络与节点可达、响应较小的测试地址。地址不可达会产生误判，不能用缩短间隔补救。

做一个数量级估算：若每轮检测 50 个节点，间隔 60 秒，理论上每小时最多安排约 3000 次节点探测；间隔改为 600 秒，则约为 300 次。这个算式不代表实际耗电倍数，也未计入惰性检查、超时和其他策略组检查，但能帮助定位配置中的重复工作。

还要检查 url-test、fallback 等策略组自身的 interval，以及客户端是否启用了自动批量测速。提供者检查和策略组检测可能同时存在。proxy-providers 的 interval 是订阅内容更新间隔，health-check.interval 才是这里的健康检查间隔，不要改错层级。

DNS 与连接重试：处理持续请求的根因

DNS 不是越多上游越稳定。某个上游长期不可达，或解析请求依赖一个尚未完成解析的代理连接，都可能让应用不断重试。日志中若连续出现 i/o timeout、context deadline exceeded，先记录对应域名、目标地址和时间；这些错误也可能来自连接或探测，不能仅凭报错文字就断定是 DNS。

1. 确认只有一套预期路径：检查客户端 DNS、Android「私人 DNS」以及其他过滤应用。原生系统的参考入口是「设置」→「网络和互联网」→「私人 DNS」。不要同时修改三处。
2. 短时对照私人 DNS：若设置了自定义服务商主机名，可记录原值后暂时切到「自动」，验证是否与当前 VPN 路径冲突。测试结束按实际需求恢复。
3. 检查 mihomo 字段：dns.nameserver 是默认解析上游，dns.proxy-server-nameserver 用于代理节点域名解析；是否使用后者应结合现有配置与内核文档，不要机械叠加。
4. 观察重复来源：如果同一应用不断访问失败域名，先检查它实际命中的规则、节点出口和解析结果，而不是反复清空缓存。

fake-ip 与 redir-host 是 DNS 处理方式，不是耗电档位。切换模式可能改变应用兼容性和缓存行为，却不能保证减少耗电。已有网站能正常访问时，不应只为省电大范围修改 DNS；优先修复明确的超时与重复请求。

规则、TUN 与日志：减少不必要的处理

规则模式不等于流量绕过本地 VPN

mode: rule 按规则选择出口，DIRECT 只表示不经过远端代理节点。若应用流量已经进入 Android 本地 VPN，仍可能经过内核处理。因此不能承诺“切回规则模式就不耗电”。不过，相比不必要地把全部流量送往远端，合理直连可以减少额外链路和部分加密工作。

如果客户端提供“分应用代理”或“绕过应用”，可按实际需求减少接管范围。但要确认该页面采用允许列表还是排除列表：两者含义相反。把应用排除后，它的联网通常不再受到这套代理规则控制，应先评估连接需求，再做调整。

不要套用桌面 TUN 的省电经验

手机端本来就常使用 VPN 接口接管流量，不应把桌面上的“关闭 TUN、只开系统代理”直接当成 Android 的通用替代方案。是否支持其他工作模式由具体客户端决定。tun.stack 的可选值与表现也受内核和集成方式影响，不要只凭名称选择；应在相同网络与工作负载下测试兼容性和耗电。

排查结束后恢复常规日志级别

长时间保留详细日志会增加处理与存储开销。定位问题时可短时启用详细日志，复现后导出必要片段，再把有效配置中的 log-level 恢复为 info 或客户端原有级别。不要在后台持续打开实时连接刷新、循环测速和日志滚动页面来做待机对照。

调整后的验收顺序

建议按下面顺序收尾。目标是同时确认后台稳定、联网正常和待机开销可接受，而不是只让电池排行中的某个数字变小。

1. 先验后台：熄屏 30 分钟后亮屏，检查 VPN 服务是否仍运行，网络能否正常恢复，日志是否出现反复启动。
2. 再验配置：确认健康检查间隔已经在最终配置中生效，自动批量测速没有再次启动，订阅更新后修改仍保留。
3. 复测电量：按前面的 60 分钟同条件方法比较，记录掉电与异常连接；结果波动较大时延长时段，而不是继续堆参数。
4. 最后恢复日常设置：关闭临时详细日志，恢复不需要的测试权限，保留确实用于后台稳定运行的设置。

若移动网络明显比 Wi-Fi 耗电，先检查信号质量与节点路径；若只有某个节点持续超时，固定换到可用节点再复测。若换客户端后问题仍在，也要回到系统网络与后台应用检查，不应直接归因于某个内核。

需要重新核对导入流程，可查看使用文档；遇到覆写未生效、DNS 超时或规则出口不符合预期，再进入进阶配置逐项确认。分享日志前应删除订阅地址、访问令牌、节点密码和个人连接记录。