Clash 移动端耗电异常排查：后台运行、电池优化与连接策略

一、先建立可比较的耗电基线

直接查看“过去 24 小时”的电池排名容易受到屏幕使用、视频播放、移动网络信号和系统更新影响。建议选择一段使用方式相近的时间，例如夜间待机两小时或日常办公的一小时，分别测试关闭代理、仅开启系统代理能力、开启 TUN 或 VPN 接管后的变化。测试期间尽量保持同一网络、同一节点和相同应用活动。

记录四项关键信息

1. 电量变化：记录开始与结束时的电量，不要只看客户端在系统统计中的百分比排名。排名是相对值，其他应用使用较少时，代理客户端即使消耗不高也可能排在前列。
2. 设备温度：息屏后仍持续温热，通常意味着存在反复重连、大量日志、密集测速或异常网络请求。
3. 服务连续性：观察 VPN 图标是否反复消失，代理是否在解锁屏幕后才恢复，以及客户端日志中是否出现短时间内重复启动。
4. 网络条件：区分 Wi-Fi、蜂窝网络、弱信号和网络切换场景。移动网络信号差时，基带本身就会增加耗电，不能全部归因于 Clash。

若开启代理后的电量变化只略高于基线，且没有发热和服务重启，通常不需要继续压缩所有功能。过度限制后台活动反而可能导致系统终止 VPN 服务，随后由客户端或系统重新拉起，形成“停止—启动—重新建连”的循环，最终比稳定运行消耗更多电量。

二、检查后台运行与系统电池优化

Android 厂商通常会同时提供系统级电池优化、应用后台活动限制、自启动管理和省电模式。不同入口可能叠加生效：即使允许客户端后台运行，系统的深度省电策略仍可能在息屏后限制网络；即使允许自启动，应用也可能因为被归入“受限”电池模式而停止 VPN 服务。

Android 的检查顺序

1. 打开系统应用信息，找到当前使用的 Clash 或 mihomo 图形客户端。
2. 进入电池或耗电管理，将应用从“受限”调整为允许后台活动的模式。不同系统可能显示为“不受限制”“允许后台运行”或类似名称。
3. 检查自启动、关联启动和后台弹出界面等厂商扩展选项。这里只需保证系统能够在服务被回收后按正常机制恢复，不必同时开启与代理无关的权限。
4. 确认系统省电模式是否会关闭 VPN、限制后台网络或延迟定时任务。测试时先退出极限省电模式。
5. 在最近任务界面锁定应用只能作为辅助措施。部分系统仍会依据电池策略回收服务，因此不能代替应用电池设置。

如果问题表现为“锁屏十几分钟后断网，亮屏进入客户端又恢复”，优先怀疑后台网络或 VPN 服务被限制。如果表现为“代理一直可用，但客户端后台时间很长”，则应继续检查健康检查、订阅更新、日志级别和节点重连，而不是直接关闭后台权限。

频繁重启通常比持续驻留更耗电

代理服务启动时需要读取配置、加载规则集、初始化 DNS、创建虚拟网络接口并连接节点。如果系统每隔一段时间回收服务，客户端就要重复完成这些操作。日志中若连续出现配置加载、VPN 建立、接口创建和节点连接记录，说明重点应放在系统后台策略或客户端稳定性，而不是单纯追求更短的后台驻留时间。

三、比较连接模式、节点稳定性与重连行为

移动端客户端通常借助系统 VPN 接口接管流量，其作用接近 Clash 配置中的 TUN 模式，但具体实现由客户端和操作系统决定。相比只让少数应用读取系统代理设置，VPN 或 TUN 接管范围更广，需要处理更多连接、DNS 请求和路由判断，因此固定开销可能更高。移动端应用是否提供模式切换，应以客户端实际选项为准。

TUN 或 VPN 模式为何可能增加消耗

• 所有经过虚拟接口的连接都要由内核读取并按规则匹配，包括部分系统服务和后台应用流量。
• UDP、实时通信和长连接可能需要维持会话状态，网络切换后还可能重新建立。
• DNS 劫持、Fake IP 或增强 DNS 模式会增加本地查询处理，但它们本身不必然导致异常耗电，关键在于是否出现查询循环、超时重试或配置冲突。
• 蜂窝网络与 Wi-Fi 切换时，旧连接失效，新连接需要重新选择出口。节点握手缓慢会放大这一阶段的耗电。

若客户端支持仅代理指定应用或绕过局域网流量，可以根据实际需要缩小接管范围。例如不需要代理的本地投屏、打印服务或局域网存储访问，可以走直连。不要为了省电随意排除需要代理的系统组件，否则可能出现部分应用无法联网、DNS 路径不一致或连接泄漏到错误出口。

节点不稳定是常见的隐性原因

节点延迟高并不一定等于耗电高，但频繁超时和断开会触发重试、策略组重新选择以及应用层连接重建。可先固定一个已确认稳定的节点，暂时不要使用会频繁切换的自动策略组，观察一段时间。如果温度和后台活动明显下降，再检查策略组测试地址、测试间隔和切换阈值。

url-test 会按设定间隔测试候选节点并选择符合条件的结果；fallback 关注可用性并在当前节点失效时切换；load-balance 会按策略分配连接。节点数量很多、测试间隔很短时，周期性探测会产生额外网络唤醒。移动端不需要把几十个节点都放入高频自动测试组，可先筛选常用地区和质量稳定的节点。

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

上例仅用于说明控制候选数量与检测频率的思路，不代表所有订阅都应采用相同数值。测试地址必须能够稳定返回预期结果；如果所在网络无法可靠访问该地址，客户端会持续得到失败结果，继而重复检测或切换节点。

四、缩小规则、DNS 与周期任务的排查范围

规则数量多不等于一定耗电异常。mihomo 会针对规则类型采用相应的匹配方式，正常维护的规则集即使规模较大，也通常比网络重试带来的影响更稳定。需要关注的是规则提供者频繁更新、配置重复加载、复杂脚本行为、DNS 查询循环，以及日志持续写入。

检查规则提供者更新周期

远程规则集和订阅需要定期请求文件并重新载入。若多个规则提供者都设置了很短的更新间隔，移动端会频繁唤醒网络。对变化不频繁的域名或 IP 规则集，通常没有必要每几分钟更新一次。先查看配置中的 rule-providers、订阅自动更新和客户端定时刷新选项，确认没有重复任务。

rule-providers:
  direct-list:
    type: http
    behavior: domain
    url: https://example.invalid/rules/direct.yaml
    path: ./ruleset/direct.yaml
    interval: 86400

示例中的地址只展示字段结构。实际配置应使用订阅或规则维护方提供的有效地址。调整更新周期后，需要重新载入配置，并观察日志中规则下载与配置刷新是否仍在短时间内重复出现。

识别 DNS 重试与解析循环

DNS 配置异常时，常见表现包括网页首次打开缓慢、日志中同一域名反复查询、节点域名无法解析，以及切换网络后长时间没有连接。若加密 DNS 服务器本身必须经过代理访问，而代理节点域名又依赖同一解析路径，就可能形成启动依赖问题。应为节点解析保留可用的基础 DNS 路径，并根据客户端与内核文档设置 default-nameserver、nameserver 和代理服务器域名解析。

Fake IP 模式会为域名分配虚拟地址，再由内核保存域名与连接的映射。它通常能改善规则匹配和透明代理兼容性，但部分局域网服务、特殊应用或探测域名可能需要加入过滤列表。过滤范围过宽会降低模式效果，范围过窄则可能让不兼容应用不断重试。排查时应针对日志中反复失败的具体域名处理，不要直接复制过大的过滤清单。

降低调试日志带来的持续写入

详细日志适合短时间定位故障，不适合长期保持。若日志级别设为 debug，大量连接、DNS 和规则匹配信息可能持续写入存储，并增加界面刷新负担。完成诊断后可恢复到 info、warning 或客户端推荐的日常级别。清理历史日志只能释放空间，真正影响后续行为的是日志级别和记录频率。

五、Android 与 iOS 的后台机制差异

Android：重点检查 VPN 服务是否被回收

Android 客户端一般通过 VpnService 建立本地 VPN。系统通知栏中的常驻通知通常与前台服务有关，它让系统知道该网络服务正在持续运行。若手动关闭通知权限、限制后台活动或启用厂商的深度休眠，可能影响服务稳定性。具体行为取决于系统版本和客户端实现，因此应结合系统电池记录与客户端日志判断。

Android 还可以查看应用崩溃、无响应或启动次数等系统信息。若客户端本身频繁退出，先升级到适配当前系统版本的稳定版本，并验证同一份配置是否能正常加载。配置文件过大、语法错误或内存压力都可能造成启动失败，但不能只凭“代理断开”推断内核崩溃。

iOS：区分应用界面与网络扩展

iOS 上的兼容客户端通常通过 Network Extension 提供代理或 VPN 能力。应用界面进入后台后，网络扩展仍可由系统管理，因此从多任务界面移除应用不一定等同于按客户端内的停止按钮结束隧道。电池统计也可能把部分网络活动归入客户端、系统网络服务或正在传输数据的应用。

排查 iOS 耗电时，应检查低电量模式、蜂窝网络质量、按需连接规则和客户端内的节点测试计划。若设置了按需连接，网络环境变化会触发规则评估；若同时配置了高频健康检查，频繁在 Wi-Fi 与蜂窝网络之间切换时，连接重建会更加明显。测试阶段可固定网络并暂停非必要的节点测试，再比较电池曲线。

无论使用哪一平台，都不建议照搬另一系统的后台设置名称。应围绕三个事实检查：代理隧道是否保持连续、系统是否反复终止服务、配置是否持续触发网络任务。设置入口不同，但诊断逻辑一致。

六、按阶段完成移动端耗电排查

阶段一：确认是否与代理直接相关

1. 在相同网络环境下记录一段关闭代理的待机电量。
2. 开启代理并固定单个稳定节点，不进行下载、视频播放或大规模同步。
3. 比较掉电、温度和后台活动。若差异很小，应继续观察更长周期，不要依据短时间百分比波动下结论。

阶段二：排除系统反复回收

1. 允许客户端正常后台运行，并退出系统极限省电模式。
2. 观察锁屏后代理是否中断，解锁后是否重新出现启动日志。
3. 若服务频繁恢复，检查电池优化、自启动、后台网络和 VPN 权限。

阶段三：减少周期性网络任务

1. 暂停订阅自动刷新和远程规则集的高频更新。
2. 减少自动策略组候选节点，延长健康检查间隔。
3. 把日志从调试级别恢复为日常级别。
4. 固定一个稳定节点，排除节点超时和策略组反复切换。

阶段四：检查 DNS 与接管范围

1. 查看日志中是否存在连续 DNS 超时、相同域名重复查询或节点域名解析失败。
2. 确认基础 DNS 能够在代理尚未建立时完成必要解析。
3. 根据需求调整应用绕过、局域网直连和 TUN 接管范围，每次调整后重新测试。

阶段五：恢复功能并验证

找到明显改善耗电的变量后，不要立即结束测试。逐项恢复订阅更新、策略组和原有规则，每恢复一项就观察一段时间。如果恢复某项后异常重新出现，即可进一步缩小范围。例如只有启用某个自动策略组后才发热，应检查该组的节点数量、测试地址和间隔，而不是删除整份配置。

结论：稳定运行优先于过度限制后台

Clash 移动端耗电异常通常不是由单一开关造成，而是系统电池限制、VPN 服务重启、弱节点重连、密集健康检查、订阅刷新和 DNS 超时共同作用的结果。最有效的处理方式是先建立关闭代理与稳定代理的对照基线，再检查服务是否连续运行，随后减少周期任务并验证 DNS 与节点质量。

对需要全天保持代理的设备，稳定驻留往往比反复终止和恢复更节能。对只在特定场景使用代理的设备，则可以在客户端内主动停止服务。完成设置后至少观察一个完整的日常使用周期，并分别记录 Wi-Fi 与蜂窝网络表现，才能得到可靠结论。