Clash 安卓后台耗电严重怎么办:省电设置与后台保活的平衡

先确认是正常常驻，还是异常耗电

Clash、Clash Meta for Android、FlClash 等客户端启动代理后，会通过 Android 的 VpnService 建立本地 VPN 接口。状态栏持续显示钥匙或 VPN 图标，只表示接口处于活动状态，不等于处理器一直高负载运行。屏幕关闭后，稳定连接通常只保留前台服务、少量连接状态和必要的网络唤醒。

判断耗电是否异常，应同时看电量下降、后台活动时间和移动网络状态。仅看到电池页面中 Clash 排名靠前，不能直接得出结论。若一段时间内主要只有这一个网络应用运行，它自然会获得较高的耗电占比。

使用固定条件做一次 8 小时基线测试

1. 将电量充至 80% 以上，记录测试开始时间。
2. 保持同一个 Wi-Fi 或移动数据环境，不在测试期间频繁切换网络。
3. 关闭视频播放、游戏、云相册同步和系统更新等明显负载。
4. 保留 Clash 连接，关闭主动测速与配置编辑页面，然后锁屏放置 8 小时。
5. 测试结束后打开「设置」→「电池」→「电池用量」，记录 Clash 的耗电量、后台活动时长及系统空闲耗电。

以一台电池健康度正常、容量约 5000 mAh 的设备为例，稳定 Wi-Fi 下锁屏 8 小时下降 2%–5% 通常不值得单独处理。若下降达到 10% 以上，或电池页面显示客户端持续在后台高负载运行，应继续检查延迟测试、重连循环、订阅更新和 TUN 参数。不同芯片、信号强度、系统版本及推送数量会改变结果，这组数值适合用于排查，不是所有设备的统一标准。

优先降低延迟测试与订阅轮询频率

后台耗电最常见的来源不是 VPN 接口本身，而是周期性网络任务。策略组中的 url-test、fallback 和负载均衡健康检查会按间隔访问测试地址。节点越多，单轮测试需要建立的 DNS 查询、TCP 连接和 TLS 会话越多。包含 80 个节点的策略组每分钟测试一次，与每十分钟测试一次，后台唤醒次数可能相差一个数量级。

把自动测速从 60 秒调整到 300–600 秒

在支持编辑策略组参数的客户端中，可检查「配置」→「覆写」或「设置」→「配置覆写」中的健康检查选项。不同客户端菜单名称会有差异。日常固定网络环境可将 interval 设置为 300 秒；节点数量超过 50 个时，可先试用 600 秒。频繁在 Wi-Fi 与移动网络之间切换的设备，可保留 300 秒，避免失效节点长期停留在当前策略中。

proxy-groups:
  - name: 自动选择
    type: url-test
    proxies:
      - 节点-A
      - 节点-B
      - 节点-C
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 80
    lazy: true

lazy: true 表示策略组未被实际使用时减少不必要的健康检查，是否生效取决于当前内核及客户端对配置字段的支持。tolerance: 80 可避免两个节点只差几十毫秒时频繁切换。频繁切换会重建连接，对稳定性和耗电都没有帮助。

不要把手动测速当作后台监控

• 节点列表中的「全部测速」适合故障确认，不适合长时间反复点击。
• 单次测试先选择当前策略组，不必同时测试订阅里的全部节点。
• 测试超时可设为 5000 ms 左右。过长超时会让失效节点占用更长检测时间。
• 连续执行三轮测速所得的微小差异通常来自网络抖动，不需要据此频繁换节点。

订阅自动更新保持小时级或天级

订阅内容一般不会按分钟变化。自动更新时间设置为 1440 分钟，也就是每天一次，足以覆盖多数使用场景。节点提供方明确要求更短周期时，可改为 360 或 720 分钟。将订阅更新设为每 15 分钟一次，会重复下载配置、解析 YAML、重建策略组，并可能触发节点健康检查。

处理厂商省电策略，避免杀进程后反复重连

把 Clash 强制限制到后台，看似可以省电，实际可能造成相反结果。系统终止前台服务后，客户端、自动化任务或网络变化又将其唤醒，VPN 接口会重新建立，DNS 与现有连接也要重新初始化。反复发生的「终止—唤醒—重连」比稳定驻留产生更多处理器唤醒和网络握手。

Android 原生与 Pixel 系列

打开「设置」→「应用」→「Clash 客户端」→「应用电池用量」，将后台用量设置为「允许」。如果系统提供「优化」「受限」「不受限」三档，持续使用 VPN 时可选择「不受限」。Android 版本不同，入口也可能显示为「设置」→「应用」→「特殊应用权限」→「电池优化」。

小米与 HyperOS 设备

• 进入「设置」→「应用设置」→「应用管理」→「Clash 客户端」→「省电策略」，选择「无限制」。
• 打开系统「安全中心」→「应用管理」→「权限」→「自启动管理」，允许客户端自启动。
• 在最近任务界面长按客户端卡片并锁定，降低一键清理造成的服务终止概率。

三星 One UI 设备

• 进入「设置」→「电池」→「后台使用限制」。
• 确认客户端不在「深度休眠应用程序」列表中。
• 需要长期连接时，将客户端加入「从不自动休眠的应用程序」。

OPPO、OnePlus 与 realme 设备

通常可在「设置」→「应用」→「应用管理」→「Clash 客户端」→「耗电管理」中启用「允许后台活动」。部分版本还需要进入「设置」→「应用」→「自启动」允许自动启动。菜单文字会随 ColorOS 或 realme UI 版本变化，可在系统设置顶部搜索「后台活动」或「电池优化」。

完成白名单设置后，不要再叠加自动清理工具。稳定后台的目标是让一个 VPN 服务低频运行，而不是让系统每隔数分钟重新创建服务。若调整前日志中频繁出现服务启动、网络变更或配置重新加载，白名单设置完成后应明显减少。

按需选择 TUN 模式、系统代理与 DNS 参数

Android 上的 Clash 客户端通常通过 VpnService 接管流量，但客户端内部仍可能提供不同的 TUN 栈、应用分流、DNS 增强和嗅探选项。功能越多不代表必须全部开启。省电调整应以实际流量接管需求为边界。

只代理常用应用时，先配置应用分流

如果只有浏览器、即时通信和少量工具需要代理，可在「设置」→「网络」→「访问控制」或「设置」→「VPN 服务」→「应用分流」中选择需要接管的应用。排除本地视频播放器、局域网投屏、系统备份和大型游戏下载程序后，可以减少不需要进入代理内核的连接数。

访问控制通常有「仅允许所选应用」与「排除所选应用」两种逻辑。修改后应分别打开一个代理应用和一个被排除应用进行验证。不要同时启用含义相反的名单，也不要把 Android 系统组件批量排除，否则可能出现 DNS 查询与实际连接路径不一致。

TUN 栈以稳定为先，不要连续叠加参数

mihomo 内核常见的 TUN 栈包括 system、gvisor 与 mixed。具体可选项由客户端和内核版本决定。system 倾向使用系统网络栈，性能开销通常较低；gvisor 使用用户态网络栈，在部分兼容场景有价值，但处理路径更长；mixed 会按协议组合处理。不存在适用于全部设备的固定最省电选项。

1. 保留客户端默认栈，完成一次 8 小时静置测试。
2. 只有在特定应用无法连接、UDP 异常或连接频繁中断时，再切换另一个栈。
3. 每次只修改一个参数，清除旧日志并重新连接。
4. 对比电量、断线次数和日志中的错误，不只比较网页打开速度。

DNS 与嗅探配置保持最小必要范围

fake-ip 会为域名返回映射地址，再由内核根据映射关系执行规则匹配。它本身不等于高耗电，但过大的规则集、重复 DNS 查询、不可达的上游 DNS 和持续超时会增加后台活动。出现耗电异常时，应检查日志里是否持续出现 DNS timeout、fallback 重试或同一域名高频查询。

域名嗅探用于从连接中恢复域名信息，适合处理无法直接获得域名的流量。若当前规则已经能正确匹配，且没有透明接管兼容问题，不必为了参数齐全而扩大嗅探端口与协议范围。关闭或缩小非必要功能后，应验证视频、游戏、消息推送和局域网访问是否正常。

mode: rule

dns:
  enable: true
  enhanced-mode: fake-ip
  ipv6: false

tun:
  enable: true
  stack: system
  auto-route: true
  strict-route: false

这段配置仅用于展示排查时需要关注的字段，不应直接覆盖现有订阅。部分 Android 客户端会通过图形设置生成 TUN 参数，订阅更新也可能覆盖手动修改。实际调整前应复制当前 Profile，并在副本中测试。

检查网络切换、弱信号与并行 VPN 冲突

移动网络信号弱时，基带本身就会增加耗电。Clash 在 Wi-Fi 与蜂窝数据之间切换后还需要迁移或重建连接，因此通勤、地下车库和双卡弱信号环境中的耗电不能全部归因于代理客户端。测试时可对比同一路线下「关闭 VPN」与「开启 VPN」两次结果，并保持屏幕使用时长接近。

关闭其他会占用 VPN 接口的服务

Android 同一用户通常只能维持一个主要 VPN 连接。防火墙、去跟踪工具、企业 VPN 和其他代理客户端也可能使用 VpnService。多个应用轮流请求连接，会表现为钥匙图标消失后重现、通知反复刷新、网络短暂中断以及客户端重新加载。

• 在「设置」→「网络和互联网」→「VPN」中确认当前活动的 VPN。
• 暂时关闭其他 VPN、防火墙或本地过滤服务，观察 2 小时。
• 不要同时为两个代理客户端启用「始终开启的 VPN」。
• 若启用了「阻止未使用 VPN 的连接」，更换客户端前先关闭该选项，避免切换期间全部断网。

检查循环重连的日志特征

进入客户端的「日志」页面，将级别保持在 info。正常静置时，日志新增速度应较低。若每隔几十秒重复出现 network changed、start service、reload configuration、DNS timeout 或连接超时，应按时间顺序定位触发源。排查阶段不建议长期使用 debug 级别，详细日志会增加写入量，也会让关键事件更难辨认。

如果重连只发生在熄屏后，优先检查电池优化与 Wi-Fi 休眠策略；如果固定每 60 秒发生，优先检查健康检查间隔和自动化任务；如果只在移动数据下出现，检查信号、双卡切换、IPv6 和运营商网络可达性。

一套可执行的省电调整顺序

同时修改十几个开关会失去对照条件。更稳妥的方式是从高频任务开始，每完成一组调整就观察至少半天。以下顺序兼顾连接可靠性与排查效率。

1. 保留当前配置副本。复制正在使用的 Profile，记录内核版本、当前节点、TUN 栈和 DNS 模式。
2. 停止反复测速。将健康检查间隔改为 300–600 s，启用受支持的懒惰检测。
3. 降低订阅轮询。自动更新调整为 720–1440 min，手动更新后确认配置可正常加载。
4. 设置后台白名单。允许后台活动、自启动与前台 VPN 服务稳定运行，移出深度休眠列表。
5. 排除 VPN 冲突。关闭其他占用 VpnService 的应用，只保留一个活动客户端。
6. 收缩接管范围。通过应用分流排除不需要代理的大流量应用。
7. 最后调整 TUN。只有前述步骤无效时，才逐一比较 system、mixed 或客户端提供的其他栈。

调整后的验收标准

• 锁屏 8 小时内没有周期性断线通知。
• 日志不再按固定短间隔重复加载配置或启动服务。
• 电池页面中的后台活动与实际 VPN 使用时长相符。
• 消息推送、浏览器、终端应用和局域网访问均按预期分流。
• Wi-Fi 与移动数据切换后，可在数秒内恢复连接，不需要手动重启客户端。

若完成全部步骤后，静置耗电仍明显高于关闭 VPN 的基线，可新建一份只含少量节点与基础规则的测试配置。测试配置正常时，问题多半位于原订阅的策略组、健康检查或规则规模；测试配置仍异常时，再考虑客户端版本、系统固件或设备网络模块的兼容问题。升级客户端前记录当前版本和配置备份，升级后使用同一套条件重新测量，才能判断变化是否有效。