Clash 移动端耗电异常排查：后台运行、系统限制与省电设置

移动端开启 Clash 或兼容 Mihomo 内核的客户端后，系统通常会显示持续运行的 VPN 标记。这个标记只能说明设备中的网络连接正在经过本地 VPN 接口，不能直接证明代理客户端就是电量下降的唯一来源。真正消耗电量的环节可能是蜂窝网络反复重连、某个应用持续传输、DNS 查询过密、节点连接不稳定，也可能是系统频繁终止并重新拉起后台服务。

排查时应先区分“电池统计中占比高”和“实际耗电速度快”。如果手机一天只消耗了少量电量，Clash 在应用列表中的百分比仍可能显得很高，因为系统展示的是当期耗电构成，而不是额外损失。相反，待机时机身发热、每小时电量持续明显下降、移动网络活动长时间不归零，才更接近需要处理的异常状态。

持续 VPN 为什么会进入耗电统计

Android 与 iOS 上的 Clash 类客户端一般通过系统 VPN 接口接管网络流量。应用把设备发出的数据包读入本地虚拟网卡，再依据配置执行 DNS 处理、规则匹配和代理转发。即使规则结果是 DIRECT，流量也可能先经过这个本地处理路径。因此，系统会把部分网络活动、CPU 时间和后台运行时间计入 VPN 客户端。

持续运行不等于持续高负载

设备锁屏且没有活跃连接时，正常的本地 VPN 服务可以处于低活动状态。少量保活、健康检查或系统网络切换会让服务偶尔被唤醒，但不应长期占用大量 CPU。若待机耗电明显，重点不是简单观察“后台运行了多少小时”，而是检查这段时间是否伴随大量数据、频繁唤醒、节点重连或高频日志。

蜂窝网络比稳定 Wi-Fi 更容易放大差异。移动信号较弱时，基带需要提高发射功率；网络在 Wi-Fi 与蜂窝数据之间来回切换时，代理连接也可能重新建立。此时电池页面可能把一部分活动归到代理客户端，但根因实际上是网络环境与连接重建共同作用。

规则模式仍有计算成本

规则模式会根据域名、IP、进程信息或规则集决定连接去向。对普通配置而言，一次匹配的成本通常很低，不会仅因为规则条目多就立刻形成明显耗电。不过，超大的规则集、重复规则、过多远程规则提供者、频繁更新和持续的域名嗅探会增加内存占用与后台活动。问题通常来自多个功能叠加，而不是某一条 DOMAIN-SUFFIX 规则。

先判断是客户端、配置还是其他应用

有效的排查需要一次只改变一个变量。直接同时关闭 TUN、删除规则、切换节点并修改省电设置，虽然可能暂时降低耗电，却无法知道是哪一步生效。建议保留当前可用配置的副本，再按照以下顺序做对照。

1. 确认统计周期。查看系统电池页面的时间范围，排除刚完成系统升级、应用更新、照片备份或大文件下载的时段。
2. 记录实际电量斜率。在相同网络下锁屏待机 30 至 60 分钟，记录起止电量、设备温度与是否有持续上传下载。
3. 检查流量来源。在客户端连接页面中查看是否有某个应用反复创建连接。浏览器标签页、云盘、相册同步、即时通信备份和媒体应用都可能在后台持续工作。
4. 更换稳定节点。选择已确认可连接的节点，暂时停用频繁自动切换的策略组，观察重连次数是否下降。
5. 使用精简配置对照。保留必要的 DNS、少量规则和单一代理策略，关闭非必需的调试功能。若耗电恢复正常，再逐项加回规则集、嗅探和健康检查。
6. 最后对照关闭 VPN。只有关闭代理后的同环境数据，才能说明本地 VPN 路径是否带来了可测量差异。

查看连接列表比只看节点延迟更有用

节点延迟测试只代表某次探测请求的响应时间，不表示后台没有持续流量。若连接列表中同一域名每隔几秒出现一次，先识别它属于哪个应用，再判断是推送、广告请求、遥测、同步还是失败重试。一个无法完成握手的后台任务可能不断建立新连接，即使单次流量很小，也会频繁唤醒网络与 CPU。

如果连接数量在锁屏后仍不断增加，可以临时关闭最近安装或最近更新的应用做对照。也可以切换到 DIRECT 策略观察：若请求仍持续出现，说明流量由终端应用产生；若只在特定代理节点下重复，则应检查节点稳定性、协议兼容性和远端可达性。

配置层面的高频耗电来源

健康检查间隔过短

url-test、fallback 等策略组可以通过探测地址判断节点状态。健康检查本身有用途，但节点数量较多且间隔很短时，客户端会定期向每个候选节点发起请求。几十个节点按分钟级间隔持续测试，带来的不是一次延迟测试，而是一整天重复发生的网络唤醒。

移动端应根据使用需求适当拉长检查间隔，并减少实际不会使用的候选节点。若客户端支持按需或懒惰检测，可以让策略组在需要时再检查，但具体字段应以当前内核与客户端文档为准。不要从其他配置片段直接复制未知参数，因为不同版本对策略组字段的支持可能不同。

调试日志长期保持详细级别

详细日志适合在连接失败时观察 DNS、规则命中与代理握手，不适合长期作为日常设置。大量连接产生的日志需要格式化、写入内存或文件，还会让诊断页面持续刷新。问题复现完成后，可把日志级别恢复为客户端推荐的日常级别，并清理体积异常的历史日志。

如果只有打开日志页面时耗电和温度明显上升，原因可能是界面不断渲染新记录，而不一定是内核转发本身。退出日志页面、锁屏并再次测试，可以快速区分界面刷新与后台网络处理。

DNS 失败与循环查询

DNS 配置错误可能表现为网页打开缓慢、应用反复重试、相同域名频繁查询。尤其在网络切换、私有 DNS、系统加密 DNS与客户端 DNS 同时参与时，需要确认查询路径没有互相阻断。Mihomo 的 fake-ip 模式会把域名映射到保留地址，再由内核还原域名并执行规则；看到保留地址本身并不代表异常。

排查 DNS 时先选择一组当前网络可访问的解析器，确认普通域名可以稳定解析，再恢复复杂的分流解析。不要仅为了省电随意关闭 IPv6 或改动所有 DNS 服务器，这类修改可能掩盖真正的网络问题，也可能让部分应用等待超时后再回退到另一协议。

嗅探、进程匹配与大规则集

域名嗅探可以从连接中恢复域名信息，帮助没有直接域名上下文的流量进行规则匹配。进程匹配则需要客户端和系统提供相应能力。这些功能都有明确用途，但移动端不应把所有高级功能同时开启后再判断基础耗电。可以先保留域名和 IP 规则，确认稳定后再加入嗅探及进程规则。

远程规则集的更新频率同样值得检查。规则提供者通常不需要在短时间内反复拉取。若订阅或规则地址不可访问，客户端可能按内部机制重试；此时应修正地址、网络路径或更新周期，而不是让失败任务持续留在后台。

Android 后台限制与省电设置

Android 厂商对后台服务的管理差异较大。Clash 类客户端通常需要前台 VPN 服务维持虚拟网卡，通知栏中的持续通知是系统机制的一部分。若系统把客户端列为严格限制对象，锁屏后可能终止服务；客户端或系统随后尝试恢复 VPN，就会出现断线、重连和重复初始化。

建议检查的系统项目

• 电池使用策略：将客户端设为允许后台运行或不受严格限制。不同品牌可能称为“不限制”“允许后台活动”或“忽略电池优化”。
• 自启动与关联启动：如果系统提供单独开关，应确保设备重启或 VPN 被回收后，客户端能够按用户设定恢复。
• 后台数据：允许客户端使用后台数据。若只允许前台联网，锁屏后代理握手和 DNS 请求可能失败。
• 始终开启的 VPN：只有确实需要全时连接时才启用。启用后，系统会持续维护指定 VPN；若同时选择“阻止未使用 VPN 的连接”，客户端异常退出时其他应用也会断网。
• 通知权限：部分系统会把前台服务通知与服务管理关联。保留必要的 VPN 状态通知更便于判断服务是否被终止。

把客户端设为不受限制并不意味着它会持续高负载，而是避免系统在错误时机终止 VPN。稳定保持一个空闲连接，往往比每隔一段时间销毁并重建内核、虚拟网卡和代理连接更平稳。不过，如果客户端本身存在持续流量，不受限制也会让这类活动长期运行，所以仍需结合连接列表和流量统计判断。

TUN 模式与系统 VPN 的关系

在 Android 上，图形客户端所称的 TUN 模式通常建立在系统 VPN API 之上，用于接收更多类型的 IP 流量。它比单纯设置 HTTP 或 SOCKS 代理覆盖范围更广，因此更多应用的连接会出现在客户端统计中。覆盖范围扩大后，总流量与唤醒次数可能上升，但不能简单得出“TUN 必然耗电异常”的结论。

若只需要少数支持系统代理的应用，可以对照测试系统代理模式；若需要 UDP、非代理感知应用或完整规则分流，则 TUN 更合适。选择依据应是流量覆盖需求。出现异常时，应先查具体连接、DNS 与节点重试，而不是把关闭 TUN 作为唯一处理方式。

iOS 后台运行与低电量模式

iOS 上的 Clash 兼容客户端通过 Network Extension 提供 VPN 能力。用户离开客户端界面后，VPN 扩展仍可以处理网络流量，因此“应用不在前台”不等于代理已经停止。系统负责管理扩展的运行与资源，电池统计则可能把相关活动归入客户端或网络使用。

低电量模式会减少部分后台活动，但不会保证正在使用的 VPN 自动关闭。只要其他应用继续联网，VPN 扩展就需要处理相应连接。若照片同步、云盘上传、播客下载或应用更新集中发生，代理客户端的统计占比也可能随之提高。

检查按需连接与网络切换

部分客户端支持按需连接规则，例如在蜂窝网络、指定 Wi-Fi 或网络变化时自动启用 VPN。规则互相冲突时，可能出现连接状态频繁切换。可暂时关闭按需规则，手动连接并在稳定 Wi-Fi 下观察一段时间；若耗电与断线现象缓解，再逐项恢复网络条件。

从 Wi-Fi 走到蜂窝网络时，现有 TCP、UDP 或基于 QUIC 的连接可能需要重新建立。短时间出现网络活动属于正常现象，但如果设备静置后仍不断切换，应检查 Wi-Fi 信号、自动加入热点设置以及节点是否能从两个网络稳定访问。

不要反复清理后台应用

从多任务界面划掉客户端不一定会以预期方式关闭 VPN 扩展，具体行为取决于客户端实现和系统状态。若目标是做关闭代理的对照测试，应在客户端或系统 VPN 设置中明确断开连接。反复结束应用再重开，会触发配置读取、订阅状态检查和连接初始化，不利于获得稳定测试结果。

iOS 的电池统计适合观察数小时或一天的趋势，不适合用几分钟内的百分比做结论。建议同时查看屏幕关闭期间的活动、蜂窝数据用量与设备温度。若只有某个网络环境出现异常，可重置该网络连接或检查 DNS、路由器与节点可达性，而不是先删除全部配置。

按现象执行的排查流程

情况一：待机掉电快，但流量很少

1. 退出客户端的日志、连接监视和实时测速页面。
2. 暂停自动延迟测试与过密的策略组健康检查。
3. 确认系统没有频繁终止和重启 VPN 服务。
4. 更换一个稳定节点，观察握手失败与重连是否减少。
5. 使用精简配置测试一小时，再逐项恢复高级功能。

情况二：待机期间仍有大量流量

1. 在连接列表中按域名、目标地址或应用来源排序。
2. 暂停云盘、相册、媒体缓存和系统更新，进行对照。
3. 检查订阅与远程规则是否处于重复下载状态。
4. 确认 DNS 失败没有导致应用持续重试。
5. 分别在 DIRECT 与代理策略下观察请求是否继续出现。

情况三：只在移动网络下发热

1. 查看蜂窝信号强度，并在信号稳定位置重新测试。
2. 关闭非必要的后台同步，减少大文件上传与下载。
3. 选择从当前运营商网络可稳定访问的节点。
4. 避免策略组在多个节点间频繁自动切换。
5. 检查 IPv4、IPv6 与 DNS 路径是否存在长时间超时。

情况四：锁屏后断线，解锁后恢复

1. Android 检查电池优化、后台数据、自启动和前台服务通知。
2. iOS 检查按需连接规则及低电量模式下的实际行为。
3. 确认客户端没有设置仅在前台保持连接。
4. 查看系统是否在网络切换后撤销了 VPN 权限。
5. 保留一份可工作的精简配置，排除配置加载失败。

省电调整的合理边界

移动端省电的目标不是把所有后台功能都关闭，而是在保持所需分流能力的前提下减少无意义唤醒。日常配置可以遵循四个原则：只保留会实际使用的节点，健康检查间隔与使用频率匹配，调试日志在问题结束后恢复日常级别，远程规则与订阅按合理周期更新。

节点协议、加密运算和网络实现也会影响处理成本，但在真实使用中，屏幕、基带信号、传输数据量和应用行为通常占据更明显的位置。不要只根据协议名称判断耗电，也不要用单次测试比较两个节点。应在相同网络和相近流量下持续观察，并记录重连次数与设备温度。

如果更换配置后立刻出现异常，可恢复上一份正常配置，再比较新增的规则提供者、策略组、DNS 和嗅探设置。如果所有配置都在同一客户端版本上异常，则检查系统更新、客户端更新与 VPN 权限；如果只有一个网络环境异常，则把重点放在信号、路由器、DNS 和节点可达性。

完成排查后，建议保留一份简短记录：测试网络、客户端版本、内核类型、配置变更、起止电量和观察时长。下一次更新客户端或订阅后如果再次出现问题，就能快速判断变化来自系统、软件还是配置，而不必从头猜测。