手机挂 Clash 耗电快怎么排查：后台保活、DNS 轮询与省电策略

先做对照：区分流量耗电、待机耗电和统计归因

手机开着 Clash 发热，不等于代理内核一直占满 CPU。视频下载、云相册上传、弱信号下的蜂窝网络重传，都可能同时发生。Android 的本地 VPN 会接收其他应用的流量，系统电池页面可能把部分网络活动归到 VPN 客户端；不同系统的统计口径也不一样。先看手机总掉电，再看应用排名，别只盯着第一名。

两轮测试，每轮至少 60 分钟

1. 固定条件：保持同一 Wi-Fi、相近起始电量和室温，暂停下载与系统更新，不边充电边测试。
2. 关闭代理测一轮：锁屏 60 分钟，记录起止电量、是否发热、后台应用和信号情况。
3. 开启代理测一轮：使用同一节点、同一配置，锁屏 60 分钟。重复两到三组，尽量交换测试先后顺序。
4. 补一组蜂窝测试：若只有移动网络明显异常，优先查信号、网络切换和连接重试，而不是立即更换 TUN 栈。

例如，电量从 80% 到 77%，只能记作“这一小时下降 3 个百分点”，不能据此推算精准功耗。下面这些是记录字段，不是本站实测结果。电量显示有取整误差，差异很小时，把测试延长到 3～6 小时更有参考价值。

后台保活：保留必要权限，停止反复拉起

Android 客户端通常通过 VpnService 建立本地 VPN 接口，再把流量交给内核处理。系统显示常驻通知，不代表持续高负载；反过来，强行隐藏通知、限制后台后，服务被终止再被自动启动，也可能造成断网与重复初始化。

先确认 Android 的三个入口

• 电池限制：Android 13～15 的常见入口是「设置」→「应用」→「查看所有应用」→选择客户端→「应用电池用量」。部分系统显示为「电池」→「不受限制／优化／受限制」。具体名称以手机为准。
• VPN 策略：原生 Android 常见入口是「设置」→「网络和互联网」→「VPN」→客户端旁的设置按钮，查看「始终开启的 VPN」和「屏蔽未使用 VPN 的连接」。后者用于断开时阻止流量，不是省电开关。
• 厂商后台管理：在应用信息页检查「自启动」「后台运行」等选项。先只调整当前客户端，不要把所有后台应用一起放行。

如果锁屏后连接稳定，没有服务退出记录，就不必为了“保活更强”额外开启定时重启、第三方守护工具或周期性网络请求。如果已经出现锁屏断线，应先允许客户端正常后台运行，再评估掉电变化。省电与不断线要分别验证，不能靠不断切换权限碰运气。

只让确有需要的应用进入 VPN，可以减少内核处理的连接数量，但不保证整机省电：被排除的应用依旧可能在后台下载。每次调整后检查浏览器、消息通知、地图和局域网访问，避免把功能缺失误认为省电成功。

定时任务：先查健康检查，再查订阅更新

待机时仍有周期性联网，常见来源是节点健康检查、自动选择策略和订阅或规则更新。它们不等于同一类定时器：节点探测用于测试可用性，订阅更新下载配置或节点列表，规则更新则刷新匹配数据。把三者全部改成几十秒一次，很容易制造额外请求。

检查间隔与节点数量一起看

假设某个节点集合有 80 个节点，每 60 秒完整探测一轮，仅按调度规模计算就是每小时 4800 次探测尝试；改成 600 秒一轮则是 480 次。实际次数还受懒检查、失败处理和客户端实现影响。这是配置量级示例，不是耗电实测，也不意味着所有节点会同时建立连接。

• 排查期间，先把不必要的自动测速关闭，或把 60 秒调整为 600～1800 秒。
• 暂时改用手动选择策略，观察同一节点下的锁屏耗电，排除频繁自动切换。
• 普通订阅可以先设为每 24 小时更新一次；需要更快接收变更时再缩短。
• 不要同时保留多组覆盖同一批节点的密集探测。健康检查与策略组测试可能各自发起请求。

mihomo 的 provider 参数示例

下面片段只用于替换现有 proxy-providers 中某个 HTTP provider 的对应字段；保留原有名称、订阅地址和路径，不要直接粘贴到 YAML 顶层。interval 与健康检查的 interval 在这里都以秒为单位，timeout 以毫秒为单位。

interval: 86400
health-check:
  enable: true
  url: https://www.gstatic.com/generate_204
  interval: 600
  timeout: 5000
  lazy: true

lazy: true 用于减少未被使用的 provider 的周期性检查，不会关闭正在使用节点的全部探测。检测地址需要能通过对应节点访问；若该地址在当前网络不可达，会把地址故障误判成节点故障。不同旧版 Clash 内核支持的字段可能不同，导入前确认内核类型，保存后查看配置错误提示。

客户端自己的“订阅自动更新”可能独立于 YAML 中的 provider 更新。两处都检查，不能只改一个数字。托管配置下次更新也可能覆盖手动修改，优先使用客户端支持的覆写或合并功能。

DNS 轮询：用日志定位重复请求，不盲目改解析器

正常 DNS 查询通常由应用解析域名触发。开启 fake-ip 本身不会要求手机按固定周期查询所有域名；它主要改变域名映射和连接处理方式。所谓“DNS 轮询耗电”，可能实际来自应用重试、健康检查、加密 DNS 连接重建，或 DNS 配置形成回路。

打开短时日志，找三类模式

1. 同一域名每隔几秒出现：先确认是不是消息、广告请求、同步任务或测速地址。必要时暂停对应应用，观察请求是否停止。
2. 大量超时后立即重试：检查 DNS 上游是否可达，是否依赖尚未建立的代理连接，以及解析上游域名所用的引导解析器。
3. 本地地址反复互相转发：检查客户端 DNS 是否又转向被自己劫持的入口。不要把 127.0.0.1 的某个监听端口同时当成上游，形成闭环。

排查时先保留一组已验证可达的 DNS 上游，暂停重复的覆写，再逐项恢复。不要为了省电清空所有解析规则，也不要把缓存失效时间强行拉长：这可能使域名切换后的地址迟迟不更新。nameserver-policy 用于按域名选择解析器，不是减少定时器的总开关。

Android「设置」→「网络和互联网」→「私人 DNS」也值得记录。系统私人 DNS、浏览器安全 DNS和客户端内置 DNS可能并存；具体路径取决于 VPN 路由和应用实现。TUN 中对 53 端口的劫持不等于能接管所有加密 DNS。需要对照测试时，一次只改一项，测试完恢复符合自身隐私要求的设置。

日志级别与连接页面：排障结束后收回开销

调试日志会增加格式化、写入和界面刷新。问题定位时可以临时打开，但不适合长期挂着滚动日志页。连接列表若每秒刷新，也会增加前端工作；测试锁屏耗电时应退到后台，不要让仪表盘一直亮屏。

mihomo 的日常日志级别可以先使用下面这一项。它放在配置顶层，和 dns、tun 同级；这里的正确值是 warning，不是 warn。

log-level: warning

• 复现问题时，临时改为 info，记录 5～10 分钟即可。
• 需要更详细诊断时再启用 debug，避免边测试边持续导出大量日志。
• 分享日志前隐藏订阅地址中的令牌、节点凭据和个人访问记录。
• 如果客户端还有单独的界面日志设置，同时检查；内核日志级别不一定控制所有前端日志。

日志降级主要减少记录开销，不会修好节点丢包或 DNS 回路。若错误仍在密集出现，应处理错误来源，而不是仅把日志隐藏起来。

TUN 栈与节点协议：按实机结果选择

在 Android 上，VpnService 提供虚拟网络接口，客户端再决定如何处理收到的数据包。桌面教程里的 TUN 开关与 Android 的实现不能机械对应。有些移动客户端由自身创建接口，YAML 中的 tun 字段未必控制全部行为。

先确认可选项，再做单变量测试

mihomo 常见的栈选项包括 system、gvisor 和 mixed，但移动客户端是否开放、如何接入，以该版本为准。不存在所有手机通用的“最省电栈”。默认栈运行稳定时先保留；只有出现 CPU 持续占用、UDP 异常或已知兼容性问题，才测试另一种受支持的栈。

1. 记录当前客户端和内核的完整版本号，备份可用配置。
2. 只切换栈，保持节点、规则、DNS 和测试网络不变。
3. 按客户端提示重新建立 VPN，分别测试锁屏待机与实际使用。
4. 检查网页、语音通话、游戏 UDP、IPv6 和局域网设备访问；有回归就恢复原设置。

节点端的丢包、拥塞和协议实现也影响耗电。弱网络下持续重连，比一次正常握手更值得排查。先换同一协议的稳定节点，再讨论协议差异；不要把更换节点、关闭 IPv6、切换栈三个操作同时进行，否则无法判断哪项真正有效。

省电调整清单：按风险从低到高执行

iPhone 用户也应先做相同网络下的对照，但不要照搬 Android 电池白名单或 VpnService 菜单。iOS 客户端通常依赖 Network Extension；订阅更新、测速和日志设置需在具体应用内检查。本文的 mihomo YAML 片段也只有在客户端明确支持对应配置时才适用。

仍然耗电：提交能复现的问题记录

完成上述步骤后，如果手机仍持续发热，准备一份最小复现记录，比一句“后台很耗电”更容易定位问题。到客户端项目的问题反馈页提交时，至少包含以下信息：

• 手机型号、系统版本、客户端版本、内核版本，以及问题是否在升级后首次出现。
• Wi-Fi 或蜂窝条件、是否锁屏、测试起止时间，以及开启和关闭代理两组总掉电记录。
• 健康检查与更新间隔、日志级别、TUN 栈、是否启用分应用代理。
• 去除敏感信息后的短时日志，注明首次异常时间，以及是否伴随服务重启或网络切换。

如果关闭代理后同样掉电明显，就转查信号、后台同步、电池健康和系统更新任务。排查顺序始终是先测量、再减少无效唤醒、最后调整底层实现。一次改一项，留好回退配置，结果才有可比性。更多基础操作可查看使用指南，连接异常则继续查阅完整文档。