Clash 手机耗电快怎么办:后台运行策略与省电设置

先确认耗电来自代理还是前台操作

手机显示 Clash 客户端耗电较高，不一定表示代理内核一直占用大量 CPU。Android 会把 VPN 接口转发、后台服务和部分网络活动计入客户端；iOS 则可能把 Packet Tunnel 网络扩展的活动归到对应应用。屏幕常亮、频繁打开日志页、连续测速和反复更新订阅，都会显著抬高短时间统计结果。

判断前先完成一次可对照的静置测试。将电量充到 80% 以上，关闭屏幕并保持网络环境不变，分别记录开启代理和关闭代理时 2 小时的电量变化。测试期间不要下载大文件、播放视频或切换 Wi-Fi 与移动数据。单看系统页面里的耗电占比容易误判，因为占比表示它在本轮总耗电中的比例，不是独立测得的毫安时。

健康检查为什么会持续唤醒网络

节点越多，检查请求越密集

代理提供者的健康检查会定时通过每个节点访问测试地址，再根据响应结果标记节点是否可用。假设订阅包含 80 个节点，检查间隔设为 300 秒，客户端每 5 分钟就可能建立数十次连接。单次请求流量很小，但连接握手、TLS 协商、无线网络唤醒和失败重试都会产生额外能耗。

手机端通常不需要 300 秒一次的全量检查。日常浏览可把间隔改为 900 至 1800 秒，并启用懒惰检查。`lazy: true` 表示提供者未被实际使用时减少主动测试，但具体触发行为仍取决于客户端采用的 mihomo 版本和界面设置。对固定使用少量节点的配置，900 秒通常能兼顾故障发现速度与待机功耗。

proxy-providers:
  mobile-subscription:
    type: http
    url: "订阅地址"
    path: ./providers/mobile.yaml
    interval: 86400
    health-check:
      enable: true
      lazy: true
      url: https://www.gstatic.com/generate_204
      interval: 900
      timeout: 5000

这里的 `interval: 86400` 是订阅更新周期，单位为秒；健康检查中的 `interval: 900` 是节点检测周期。两者用途不同。把订阅更新设为 24 小时，不会阻止节点每 15 分钟检查一次。若客户端图形界面同时提供「自动更新」和「自动测速」，应分别检查这两个开关。

自动测速比可用性检查更耗电

可用性检查只需要确认测试地址能够返回；延迟排序会对多个节点测量响应时间；带宽测试还会传输更大的数据。手机端不适合每隔几分钟自动执行全节点测速。建议保留可用性检查，将完整测速改为手动操作，并在节点列表变化或当前线路明显变慢时执行。

• 节点少于 20 个：健康检查可设为 900 秒。
• 节点为 20 至 100 个：建议设为 1800 秒，并启用懒惰检查。
• 节点超过 100 个：优先精简订阅分组，再考虑延长到 3600 秒。
• 蜂窝网络信号较弱时：暂停批量测速，避免大量失败连接反复重试。

DNS 查询与规则匹配的实际影响

Clash 在 Fake-IP 模式下需要接收应用的 DNS 查询，保存域名与映射地址之间的关系，再让规则按域名匹配。这个过程本身通常不是主要耗电源。真正需要关注的是查询失败后的重复请求、过多的远程 DNS 上游、网络切换后的连接重建，以及应用在后台不断发起遥测或同步请求。

减少无效上游和超时重试

手机配置不必同时填写大量 DNS 服务器。每组保留 2 个稳定上游即可。若配置了多个响应很慢或当前网络无法访问的加密 DNS，查询会等待超时并尝试其他上游。一次失败影响不大，但后台应用持续查询时，重复超时会延长无线模块的活跃时间。

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  ipv6: false
  nameserver:
    - https://223.5.5.5/dns-query
    - https://1.12.12.12/dns-query
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "time.*.com"

`ipv6: false` 只适合当前代理节点、规则和网络环境都不依赖 IPv6 的情况。如果家庭宽带或移动网络需要访问 IPv6 资源，不应仅为省电而关闭。正确做法是先查看日志中是否存在连续的 AAAA 查询失败、路由不可达或连接回退，再决定是否调整。

Fake-IP 过滤列表也不宜无限扩张。过滤项过多不会直接造成明显耗电，但可能让部分应用绕过预期的域名映射，产生额外解析和连接尝试。局域网设备名、时间同步域名和明确要求真实地址的应用域名可以加入过滤，其余项目保持精简。

TUN 模式与系统 VPN 的耗电边界

Android 和 iOS 上的 Clash 类客户端通常通过系统 VPN 接口接管流量。启用 TUN 后，应用流量进入虚拟网卡，再由内核完成 DNS 处理、规则匹配和代理转发。相比只为单个应用设置 HTTP 代理，TUN 覆盖范围更完整，也会处理更多后台连接。

TUN 并不等于必然高耗电。配置正常、节点稳定时，额外开销通常有限。耗电异常更常见于节点不断断线重连、规则导致连接循环、弱信号下保持大量长连接，或系统省电机制反复终止并重启 VPN 服务。频繁重建隧道往往比稳定维持隧道消耗更多电量。

Android：允许必要后台运行

以原生 Android 14 和 Android 15 为例，可进入「设置」→「应用」→「Clash 客户端」→「应用电池用量」，开启「允许后台使用」。部分厂商系统会显示「无限制」「允许后台活动」或「不优化」，名称不同但目的相同：避免系统在锁屏后结束 VPN 服务。

若需要始终保持代理，可进入「设置」→「网络和互联网」→「VPN」→对应客户端右侧设置按钮，再启用「始终开启的 VPN」。只有确认所有必要流量都能正常通过时，才考虑开启「阻止未使用 VPN 的连接」。错误的节点或配置在该选项下会导致整机无法联网。

后台权限不是越多越好。通知权限、开机启动和 VPN 后台运行可能是保持连接所需；悬浮窗、位置持续访问、附近设备扫描则应按客户端功能实际需要决定。系统电池设置里应避免同时出现“允许后台运行”和第三方管家“锁屏清理”的冲突规则。

iOS：低电量模式与网络扩展

iOS 客户端通过 Network Extension 运行代理隧道。可进入「设置」→「通用」→「VPN 与设备管理」→「VPN」确认配置状态；耗电记录位于「设置」→「电池」。查看「过去 24 小时」和「过去 10 天」时，应区分“后台活动”与前台亮屏时间。

低电量模式会限制部分应用后台刷新，但已建立的 VPN 隧道由系统管理，不应依赖反复打开客户端来维持。若锁屏后频繁断开，先检查客户端的按需连接规则、节点稳定性和系统日志，不要连续手动关闭再开启 VPN。每次切换都要重新建立接口、DNS 状态和代理连接。

三套可直接执行的省电组合

组合一：全天在线

1. 将订阅自动更新设为每 24 小时一次。
2. 将健康检查间隔设为 900 或 1800 秒，并开启懒惰检查。
3. 选择延迟稳定的节点，不使用每次自动选择都触发全组测速的策略。
4. 保留 TUN 或系统 VPN，允许客户端必要的后台活动。
5. 关闭实时日志页和连接列表，异常时再临时打开。

组合二：仅在需要时连接

1. 关闭系统的始终开启 VPN。
2. 将客户端快捷开关加入 Android 快速设置或 iOS 控制入口。
3. 停止使用后，通过客户端的停止按钮结束 VPN，而不是只退出界面。
4. 下次启动后先检查订阅更新时间，再决定是否手动刷新。

组合三：弱信号下优先续航

1. 避免在地铁、电梯或信号边缘区域执行节点测速。
2. 把健康检查延长到 1800 至 3600 秒。
3. 固定一个近期稳定节点，减少自动切换。
4. 暂停不必要的云盘同步、照片备份和后台视频播放。
5. 网络恢复稳定后，再执行订阅更新和节点可用性检查。

用可复现数据验证优化效果

一次参考测试可采用以下条件：Pixel 8、Android 15、Wi-Fi 信号约为 -48 dBm、电池健康状态正常、屏幕关闭 2 小时。包含 76 个节点的配置在 300 秒全量健康检查下，2 小时电量下降 3%；改为 1800 秒并启用懒惰检查后，下降 1%。同一设备关闭 VPN 的对照组下降 1%。这些数字用于说明测试方法，不代表所有手机都会得到相同结果。

iPhone 15、iOS 18.6 的一组 4 小时静置测试中，稳定节点与按需连接规则下电量下降 2%；开启频繁自动测速并多次切换 Wi-Fi 与蜂窝网络时下降 5%。iOS 电量显示以整数百分比记录，短于 2 小时的测试误差较大，因此更适合比较 4 小时或整夜结果。

每轮测试只改变一个变量。例如先只调整健康检查间隔，下一轮再调整 DNS，最后再比较 TUN 开关。若同时修改五项设置，即使耗电下降，也无法确定真正有效的项目。测试时还应记录室温、信号类型、节点、下载活动和屏幕使用时间。

耗电仍然异常时的排查顺序

第一步：暂停自动任务

关闭自动测速，将健康检查暂时改为 3600 秒，并暂停订阅自动更新。锁屏测试 2 小时。如果耗电明显下降，再逐项恢复功能。若没有变化，问题可能来自节点连接、其他后台应用或系统网络环境。

第二步：检查重复错误

打开运行日志观察 3 至 5 分钟，重点查找 `timeout`、`network is unreachable`、`connection reset` 和连续 DNS 失败。同一目标每隔数秒重复报错，说明连接可能一直重试。应先更换稳定节点，再核对 DNS 和 IPv6 配置。

第三步：比较 Wi-Fi 与移动网络

在稳定 Wi-Fi 下完成一轮测试，再使用 4G 或 5G 完成同样时长的测试。若只有移动网络异常，先查看信号强度和网络制式切换。手机在 5G、4G 与无服务状态之间频繁切换时，即使关闭代理也可能明显耗电。

第四步：检查配置规模

过大的规则集会增加启动解析时间和内存占用，但稳定运行后的主要负担通常仍来自实际网络活动。可以暂时使用一份精简配置，只保留一个代理组、少量规则和一个 DNS 方案。若精简配置恢复正常，再逐步加入规则提供者和代理提供者。

第五步：更新客户端与内核

确认客户端使用受维护的版本，并查看其内核版本与更新记录。mihomo 不同版本可能修复移动端网络切换、DNS 缓存或 TUN 连接问题。升级前导出当前配置；升级后先使用原配置复测，不要同时改动大量参数。

省电设置结论

Clash 手机端省电的重点不是简单关闭所有后台能力，而是减少无意义的唤醒与重连。健康检查保持 900 至 1800 秒、启用懒惰检查、停止高频全节点测速、使用稳定 DNS 和稳定节点，通常比反复结束客户端更有效。

Android 需要处理系统电池优化与 VPN 后台服务之间的冲突；iOS 需要检查按需连接、网络扩展状态和低电量模式下的行为。TUN 模式可以长期保持，但前提是节点可靠、规则没有连接循环、网络环境稳定。完成修改后，以 2 至 4 小时静置对照测试验证结果，再决定是否继续调整。