先判断是实际耗电，还是电池统计归因
先记录熄屏掉电，再调整保活。电池列表中 Clash 排名靠前，不一定代表代理内核异常：手机上的下载、视频播放和后台同步经过 VPN 隧道时，系统可能把部分网络处理开销计入 VPN 客户端。应同时看总掉电、后台时长、传输流量和手机是否发热，不能只凭一个百分比下结论。
安卓客户端通常通过 VpnService 接管流量，iOS 客户端则可能使用 Network Extension 的 Packet Tunnel 扩展。Clash、Clash Meta（mihomo）是相关内核与生态概念，不代表所有移动客户端都有相同设置。尤其在 iOS 上，要先确认具体应用及其内核，不能照搬安卓的电池白名单教程。
先留一份排查记录
- 记录手机型号、系统版本、客户端版本和内核版本。应用版本一般在「设置」→「关于」查看；内核版本可能需要在日志启动信息中查看。
- 记录开始与结束电量、测试时长、Wi-Fi 或移动数据、信号强弱，以及屏幕是否一直关闭。
- 记录当前代理模式、选中的策略组、订阅节点数量，以及是否开启自动测速、详细日志、自动重连。
- 保存现有配置。涉及订阅覆写的改动应放在客户端支持的覆写或合并配置中，避免下一次订阅更新覆盖修改。
用两轮熄屏测试缩小范围
选择信号稳定的地点，每轮观察 60 分钟。两轮尽量使用相同网络、相近起始电量，暂停大文件下载、系统更新和照片备份。刚充完电、系统升级后索引、手机温度明显升高时，先等状态稳定再测。下面的 60 分钟是排查窗口，不是续航承诺。
- 第一轮建立基线：暂时停止代理服务，确认系统 VPN 状态已断开，熄屏放置 60 分钟。记录总掉电和后台流量。需要持续联网的业务可改在空闲时间测试。
- 第二轮保持原配置：启动代理，使用平时的规则模式与节点，保持相同条件，再观察 60 分钟。记录是否出现断线、重连或持续发热。
- 只改一个变量：若第二轮明显更耗电，下一轮只关闭周期测速，或只更换一个稳定节点。不要同时改 DNS、路由、白名单和保活，否则无法定位原因。
- 复测而非一次定论：电量显示以整数跳变，短时间误差较大。差异不明显时延长到 2～3 小时，并在另一天重复。
如果停止代理后仍快速掉电，应先查看弱信号、其他应用后台活动和系统同步。如果只有开启代理时才出现异常，再查隧道流量、探测任务与重连。需要代理才能访问的应用可能在第一轮持续重试，这会影响基线；遇到这种情况，两轮都先关闭这些应用的后台任务。
安卓省电白名单：只放行需要常驻的客户端
省电白名单的作用是降低后台任务被系统限制的概率，不是降低内核本身的计算量。典型表现是：刚熄屏时正常，过一段时间连接中断，亮屏后恢复。这时才优先检查后台限制。若手机一直发热、流量持续增长，直接设为“不受限制”可能只是让异常任务运行得更久。
按系统查后台权限
- 接近原生的 Android 14：可从「设置」→「应用」→「查看所有应用」→所用客户端→「应用电池用量」检查后台使用权限。厂商界面可能显示为「电池」或「电池用量」，并提供“不受限制、优化、受限”等选项。
- 厂商定制系统：另外检查应用详情中的「自启动」「后台活动」或「省电策略」。若允许自启动，仍应继续检查是否存在单独的后台联网限制。
- 最近任务锁定：部分系统支持在最近任务界面锁定应用，它通常只影响清理行为，不能替代电池与后台权限设置。
先使用系统默认的优化策略。只有确认熄屏后被限制，才为代理客户端单独放行，不必把所有联网应用一起加入白名单。修改后熄屏观察 30～60 分钟，并测试从 Wi-Fi 切到移动数据后能否恢复连接。一次亮屏能联网，并不能证明整段后台连接都正常。
常驻通知与始终开启 VPN 不是同一开关
安卓前台服务通常需要常驻通知。通知的作用是让系统与用户知道服务正在运行，通知本身通常不是主要耗电来源。把通知隐藏掉也不等于停止代理；反过来，看到通知也不等于节点连接一定正常。
Android 13 及以上的通知权限与前台服务要求需要分开理解。拒绝通知权限，不代表前台服务不再受系统管理。排查时保留服务通知，直接观察其连接状态，比靠隐藏通知节电更有效。
系统「设置」→「网络和互联网」→「VPN」中，部分设备会提供「始终开启 VPN」及「阻止不使用 VPN 的连接」。前者用于维持所选 VPN，后者在隧道不可用时限制其他联网。后者可能导致断线时所有应用都无法访问网络，不应把它当作耗电优化选项。菜单名称和支持情况取决于系统与客户端。
健康检查与自动测速：先降低频率，再缩小范围
节点健康检查会主动发起请求。一次请求的数据量可能很小，但频繁唤醒网络、连接超时与加密握手会增加后台开销；在移动网络中，实际耗电也不与字节数简单成正比。订阅包含大量节点时，要分别检查代理提供者的健康检查、策略组探测和客户端自己的定时测速。
| 检查项目 | 具体含义 | 排查时怎么做 |
|---|---|---|
health-check.interval |
支持该配置的代理提供者健康检查间隔，单位为秒 | 若原为 300，可试 900，再观察切换速度是否可接受 |
策略组 interval |
url-test、fallback 等组的周期探测间隔 |
与提供者检查分别核对，避免多处都设为 60 秒 |
lazy |
在支持它的检查或策略组中，控制未使用时是否延后探测 | 按内核文档确认支持范围，再考虑使用 true |
| 客户端自动测速 | 界面层额外发起的延迟或下载测试 | 先关闭定时任务，保留需要时的手动测试 |
| 订阅更新周期 | 重新获取节点和配置，不等于节点测速 | 无频繁更新需求时，可按 12 或 24 小时设置 |
以 80 个节点、每 60 秒一轮为例，若每轮都探测全部节点，一小时会有约 4800 次节点探测；改为每 900 秒一轮，则约为 320 次。这里是调度数量示例，不是实测耗电结果，也未计入重试、懒检查或其他策略组任务。它说明应该先检查频率与范围，而不是只盯着某次测速消耗了几 KB。
手动选择单个节点可以作为对照，但不保证提供者的后台健康检查也会停止。若界面已切为手动选择，日志仍周期性出现成批探测，应继续检查提供者与客户端级的定时任务。
重连、DNS 与 TUN：查循环，不要盲目关功能
手机端通过 VPN 接管流量时，界面未必使用“TUN 模式”这个名称，也不一定暴露桌面端相同的开关。重点是识别异常工作循环：网络切换后不断重连、DNS 请求持续超时，或某个后台应用重复建立失败连接。正常的流量接管与规则匹配会产生开销，但不能仅凭开启 TUN 就判断它是异常来源。
- 先排除节点问题：固定使用一个已知可用的节点，观察 30 分钟。若重连明显减少，再检查原节点的稳定性与自动切换条件。
- 再看 DNS 超时：临时查看日志中是否重复出现解析超时、连接失败或同一域名的大量重试。DNS 请求超时可能引起上层应用继续重试，持续消耗网络与处理资源。
- 核对网络侧设置：若手动配置过 Android「私人 DNS」或其他 DNS 工具，先记录原值，再按客户端文档判断是否存在互相影响，不要同时随意修改多个解析入口。
- 检查后台流量来源：在客户端连接面板中按流量或连接数观察，找到云盘上传、照片备份、视频预加载等任务。代理只是传输路径，真正的持续负载可能来自这些应用。
规则模式适合日常分流，但“直连”不必然代表数据完全绕过本机 VPN 处理：若流量已被隧道接管，内核仍可能完成识别与转发。另一方面，全局模式也不会自动减少全部后台计算。不要把来回切模式当成节电方案，应结合实际连接与规则命中排查。
日志只需短时采集。将日志等级临时调为 debug，复现 2～5 分钟后恢复为 info 或客户端默认等级。长期保留详细日志、打开实时连接面板并高频刷新，都会增加额外工作。向他人提供日志前，删除订阅地址、令牌、节点凭据及其他敏感信息。
iOS 后台保活：区分应用界面与隧道扩展
iOS 没有与安卓“不受限制”完全对应的通用电池白名单。支持 Packet Tunnel 的客户端通常由扩展处理隧道，应用界面退到后台，不代表隧道一定停止；打开「后台 App 刷新」也不等于给 VPN 扩展无限保活。是否持续连接，应看系统 VPN 状态以及客户端的连接记录。
按这三个位置检查
- 电池统计：以 iOS 18 为例，进入「设置」→「电池」，选择「过去 24 小时」或「过去 10 天」，并查看对应时间段的活动。其他系统版本的统计周期和入口可能不同。
- VPN 配置：进入「设置」→「通用」→「VPN 与设备管理」→「VPN」，确认当前使用的是哪一份配置，避免误以为另一个应用的连接属于当前客户端。
- 按需连接：若客户端提供「按需连接」或自动连接规则，检查是否在 Wi-Fi、移动数据切换时反复触发。临时关闭后做一轮对照，再决定是否恢复。
低电量模式会调整部分系统后台行为，但不能据此断言 VPN 一定断开或一定更省电。对需要持续连接的使用场景，应在开启低电量模式后分别测试熄屏与切网。频繁强制退出应用也不是通用的保活办法；具体影响取决于客户端与系统的实现。
如果应用没有提供探测间隔、日志等级或分应用设置，就不要把其他平台的 YAML 片段硬套进去。先查看该客户端实际支持的配置项，再利用固定节点、减少定时测速、检查按需连接这几项可用手段做对照。
按使用场景决定保活强度
| 使用场景 | 建议起点 | 需要接受的取舍 |
|---|---|---|
| 偶尔打开网页 | 按需启停，先保留系统默认电池优化 | 使用前可能需要手动连接 |
| 全天消息与同步 | 按需放行安卓后台权限，保留适度健康检查 | 持续连接会有基础开销，需验证熄屏稳定性 |
| 经常在通勤途中切网 | 优先稳定节点，检查自动重连与按需规则 | 弱信号下的重试与网络切换可能增加耗电 |
| 只在特定网络使用 | 使用客户端支持的网络条件规则 | 网络条件改变时可能重新建立隧道 |
最终保留三项记录即可：相同条件下的熄屏掉电、熄屏期间是否断线、切网后能否恢复。先减少重复探测和失败重连，再按需提高保活权限。如果已经稳定，就不必为了电池列表排名反复更换 DNS 或重写规则。
仍无法定位时，提交手机型号、系统与客户端版本、内核版本、测试时段、网络类型，以及脱敏后的短时日志。描述“熄屏 40 分钟后连接停止，亮屏立即恢复”，比只说“很耗电”更容易区分后台限制、节点故障与隧道异常。