Clash 安卓耗电高怎么办:后台保活与电池优化白名单设置

安卓上的 Clash 类客户端需要持续处理被接管的网络连接。出现耗电排名靠前、锁屏断连或机身发热时，先区分三件事：真实流量处理带来的消耗、系统对 VPN 流量的统计归属，以及后台被终止后反复重连。它们的解决方向不同，单纯关闭通知或放开全部后台权限，通常不能定位原因。

先看耗电统计，再做同条件对照

进入「设置」→「电池」→「电池用量」，找到当前使用的代理客户端。部分系统把入口命名为「耗电排行」。记录统计起止时间、前台与后台时长、掉电幅度，以及当时使用的是 Wi-Fi 还是移动网络。客户端占用“本周期耗电的 30%”，不等于消耗了整块电池容量的 30%。

VPN 会转发其他应用的流量。不同 Android 版本和厂商对流量、功耗的归属方式不同，客户端排名高只能作为线索，不能直接证明内核持续高负载。下载大文件、云相册上传和视频播放，都可能让这一排名上升。

用两轮锁屏测试建立基线

1. 暂停下载、视频和系统更新，选信号稳定的同一 Wi-Fi，保持设备温度接近，不要边充电边测。
2. 开启客户端，固定一个可用节点，锁屏 60 分钟。记录起止电量、是否断连、客户端流量增长和日志中的错误。
3. 在相近条件下停止客户端，再锁屏 60 分钟。两轮期间尽量保持其他应用与同步任务一致。
4. 如差异只有 1 个百分点，延长观察并重复一轮。电池百分比是粗粒度读数，短时间差异不足以下结论。

例如，记录表可以写成“代理开启：82% → 79%；代理关闭：81% → 79%”。这些只是填写格式示例，不是设备实测结果或合格标准。真正值得继续追踪的是多次复现的额外掉电，以及它是否同时伴随重连、超时或异常流量。

VPN 常驻通知与后台服务分别管什么

Android 的 VPN 接管通常通过 VpnService 建立虚拟网络接口。持续运行的 VPN 服务一般需要前台服务机制，并向系统提供通知。通知本身不是主要耗电来源；实际消耗来自数据处理、加解密、网络唤醒和连接重试。

• 状态栏 VPN 标记：表示系统存在 VPN 连接，不代表当前节点一定可用。
• 客户端服务通知：可显示运行状态、速率或断开按钮。速率显示过于频繁时，可在客户端支持的情况下降低刷新频率。
• 后台运行权限：决定服务离开前台后能否继续工作，与是否展示通知是两套控制。

Android 13 及以上提供通知运行时权限，但前台服务的系统要求并没有因此消失。关闭应用通知不能作为省电方案，也不能保证服务更稳定。排查阶段建议保留服务状态通知，方便确认锁屏后服务是否仍在运行。

“始终开启的 VPN”不是保活万能开关

常见入口为「设置」→「网络和互联网」→「VPN」→ 对应客户端旁的设置按钮。系统可能提供「始终开启的 VPN」以及「阻止未使用 VPN 的连接」。前者用于维持 VPN 使用状态，后者用于 VPN 不可用时阻断联网；两者都不能修复不可达节点或错误 DNS。

电池优化白名单：只放开当前客户端

电池优化白名单解决的是后台限制，不是直接降低功耗。合理的目标是避免服务被杀后反复重建连接，而不是让应用长期保持 CPU 唤醒。只有在锁屏断连、服务消失或系统明确提示后台受限时，才逐项调整并复测。

原生 Android 与 Pixel 常见入口

1. 长按客户端图标，进入「应用信息」→「应用电池用量」，允许后台使用；若有「不受限制」，可用于验证后台限制问题。
2. 部分较旧系统的入口是「设置」→「应用」→「特殊应用权限」→「电池优化」，切换为「所有应用」，找到客户端并选择「不优化」。
3. 返回桌面后开启代理，锁屏观察 15 分钟，再解锁检查服务是否持续、应用能否建立新连接。

不同 Android 版本可能只显示其中一种入口，不需要为了找齐菜单重复修改。若设为不受限制后仍然掉线，应转向节点、网络和日志检查，而不是继续给所有应用添加白名单。

厂商系统需要额外检查的项目

这些入口会随系统升级改名，优先使用系统设置搜索，不要照着另一品牌的截图寻找完全相同的按钮。最近任务界面的“锁定应用”有时只能防止一键清理，不能替代电池优化设置。自启动权限也不等于客户端已启用“开机启动”；如需重启后连接，还要检查客户端本身是否提供该功能。

锁屏掉线与高耗电同时出现：先查反复重连

服务存活但连接持续失败时，放开后台权限可能只会让失败重试持续更久。打开客户端「日志」页，先使用 info 级别，记录锁屏前后的时间。重点找反复出现的超时、域名解析失败、连接被重置，以及核心重新启动的记录。

• 服务重启：锁屏后通知消失，解锁后重新出现启动信息，优先检查后台限制和客户端崩溃。
• 节点超时：服务没有退出，但同一节点不断连接失败。固定另一个已确认可用的节点，再做同条件测试。
• 网络切换：关闭 Wi-Fi 转为移动网络时中断，重点检查系统切网、弱信号和隧道重建，不要直接归因于电池优化。
• 特定应用重试：只有一个同步应用持续产生连接，检查该应用的后台上传与命中规则。

诊断期间暂时固定一个节点，减少自动切换带来的变量。若配置对大量节点执行健康检查，过短的周期也会增加后台请求。例如，100 个节点每 30 秒各测试一次，理论上每小时会发起约 12,000 次测试请求；实际次数取决于客户端、懒加载与策略组是否被使用。

支持相应配置的客户端可考虑把不必要的高频检查调到 300 或 600 秒，再验证切换体验。不要把这个数值理解为所有客户端通用的菜单选项。订阅托管的配置更新后可能覆盖本地修改，持久调整应使用客户端支持的覆写功能。

TUN 与 DNS：减少重复接管和解析重试

安卓 VPN 接管不等于桌面 TUN 开关

桌面教程常把“系统代理”和“TUN 模式”作为两个入口比较；安卓客户端则通常已经借助 VPN 接口接管流量。某些基于 mihomo 的客户端还会展示 TUN 协议栈或相关选项，其具体行为由客户端实现决定。不能简单套用“关闭 TUN 就能省电”的结论，否则可能连代理接管一起停止。

• 先保留客户端默认协议栈；只有日志和项目文档指向兼容问题时，再单独切换测试。
• 检查是否同时开启了另一款本地 VPN、防火墙或网络过滤工具。普通个人配置通常不能同时维持两个基于 VpnService 的 VPN。
• 如客户端提供按应用接管，可让确实不需要代理的高流量应用退出接管；修改后确认该应用的直连行为符合预期。

DNS 超时比解析模式名称更值得先查

Fake-IP 会先返回用于映射的虚拟地址，Redir-Host 则涉及真实地址解析。两者的主要区别是解析与连接处理路径，不能只凭模式名判断谁一定省电。真正需要处理的是上游 DNS 不可达、加密 DNS 建连反复失败，或解析请求在代理与解析器之间形成依赖循环。

1. 在日志中检查是否持续出现 DNS timeout 或解析失败，并核对失败域名是否来自同一个后台应用。
2. 检查「设置」→「网络和互联网」→「私人 DNS」。若配置了自定义主机名，可临时切回「自动」做对照，测试后按需要恢复。
3. 确认客户端所用 DNS 上游能在当前网络访问；上游使用域名时，还需要可用的引导解析路径，不能让解析器依赖尚未建立的代理连接。
4. 每次只修改一处，重新测试锁屏与首次打开网页。不要同时替换 DNS、节点和规则，否则无法判断是哪项生效。

私人 DNS 与客户端 DNS 的具体交互取决于系统版本和接管方式，不能假设其中一个总会覆盖另一个。排查完成后，把临时的 debug 日志恢复为日常级别，并关闭持续刷新的连接监控页面，避免诊断工具本身增加工作量。

整理一套稳定的后台运行设置

完成上述测试后，保留最少且有效的调整。日常配置可以从“单一 VPN 接管、可用节点、正常间隔的健康检查、可达的 DNS、仅客户端获得必要后台权限”开始，再按需求增加功能。不要为了保活安装持续唤醒 CPU 的辅助工具，也不要为了省电反复强行停止服务。

修改后的验收清单

1. 锁屏恢复：先锁屏 15 分钟做快速检查，再观察 1 小时；解锁后打开一个新网页，而不只查看已有页面。
2. 切换网络：从 Wi-Fi 切到移动网络，再切回，确认能够重新建立连接，日志没有长时间连续超时。
3. 后台消息：用实际需要的通信应用验证消息是否能收到，区分其自身后台限制与 VPN 断开。
4. 电量复测：按第一节的相同条件记录掉电，至少重复两轮，不用一次短测判断优化效果。
5. 重启检查：如依赖开机连接，重启并解锁设备，检查客户端设置、系统 VPN 状态与实际联网结果。

如果客户端服务稳定、日志正常，而移动网络明显比 Wi-Fi 耗电，应继续关注信号强度、5G 切换和上游线路质量。若停止代理后仍持续发热，则需要回到系统电池页面检查其他应用与硬件状态。把代理耗电与整机耗电分开验证，才能避免在无关设置之间来回切换。