Shadowrocket（小火箭）电池用量占比高，不等于它消耗了同等比例的整机电量。先区分流量处理、后台连接和异常重试，再决定保持连接还是配置 On Demand。本文适用于已使用自己的服务商与订阅、需要排查 iPhone 或 iPad 待机耗电的用户；按步骤可建立对照记录，并判断按需连接是否适合当前网络。
一、先看电量变化，再看应用占比
在系统“设置 → 电池”中，先选择同一统计时段，查看电量曲线、屏幕使用情况和 Shadowrocket 的活动记录。应用列表中的百分比表示该统计范围内归属于应用的电池用量占比，不是它直接消耗了整块电池的百分之多少。整机耗电较少时，一个持续参与网络处理的项目也可能显示较高占比。
例如，电量从 80% 降到 70%，应用列表中 Shadowrocket 显示 30%，不能解释为它单独耗掉了 30 个电量百分点。电池页面是系统估算的归属统计，也不宜直接拿这两个数计算应用的精确耗电。更有用的判断是：相近条件下，整机掉电是否持续加快，是否伴随发热或连接失败。
以下涉及的数字是记录方法示例，不是实测结果或续航承诺。若某一时段正在同步照片、播放视频或下载大文件，先将这段活动单独标记，不要与另一段几乎没有流量的待机时段直接比较。
二、后台常驻的消耗来自哪些环节
Shadowrocket 的主界面不在前台时，系统仍可运行已连接的 VPN 网络扩展。它需要按配置处理进入隧道的流量；其中可能包括其他应用的后台请求。退出主界面不等于停止网络扩展，因此不能用“应用已经划走”作为停止连接的判断依据。
- 流量处理：视频、文件传输和后台同步会增加数据包处理、加解密及网络收发工作。应把实际流量大小与电池变化一起记录。
- 连接维持：部分连接需要保活。实际频率取决于协议、配置与远端要求，不能把所有协议归为同一种后台行为。
- 网络不稳定：弱信号、Wi-Fi 与蜂窝网络切换、远端不可达，可能触发连接重建或应用重试。蜂窝无线模块本身的耗电也会影响整机结果。
- 诊断与测试：持续进行连通性测试、反复测速或长时间查看详细日志，会增加额外活动。排查结束后应停止手动循环测试。
Shadowsocks、VMess、VLESS、Trojan、Hysteria2 与 WireGuard 的传输方式和连接机制并不完全相同，但协议名称本身不能给出固定的耗电排名。应在自己的服务商支持范围内，比较实际网络质量、成功率与重试情况；不要为了省电随意删除服务商要求的参数。
三、常驻连接与 On Demand 的区别
保持连接强调网络扩展持续可用；On Demand 则由系统根据按需规则和网络事件决定是否建立连接。它不是“只在打开 Shadowrocket 主界面时连接”，也不是承诺锁屏后自动断开。其他应用产生的请求，也可能在规则允许时触发连接。
| 设置或姿态 | 主要作用 | 耗电排查要点 |
|---|---|---|
| 保持连接 | 让现有 VPN 连接持续可用 | 看是否有持续流量、保活或异常重连 |
| On Demand | 按系统规则和网络条件触发连接 | 看规则是否过宽，导致频繁或持续触发 |
| Global Routing → Config | 依据当前 Config 的规则选择策略 | 核对实际命中规则，而非仅看模式名称 |
| Global Routing → Proxy | 采用全局代理姿态处理流量 | 可能扩大经代理处理的流量范围 |
| Global Routing → Direct | 采用全局直接连接姿态 | 不等于关闭 VPN 网络扩展 |
| Global Routing → Scene | 依据已配置的场景选择路由行为 | 先核对场景条件与实际生效结果 |
结论：先区分触发与分流
需要控制何时连接时检查 On Demand；需要控制请求走哪条策略时检查 Global Routing 与 Config。仅将 Proxy 改成 Direct，不能替代断开连接，也不能据此确认后台网络扩展已经停止。
四、按顺序建立 On Demand 对照测试
测试前确认当前配置能正常使用，并保存原有设置。一次只改一个变量：先比较连接方式，再考虑路由或协议。若同时更换网络、远端和规则，即使电量变化改善，也无法确认是哪项调整起作用。
-
记录基线
在系统“设置 → 电池”记录起止电量、时间和屏幕活动；在 Shadowrocket 的 Home 记录连接状态与 Global Routing。可选择 60 分钟为一个观察窗口，期间保持相近的使用方式。
-
检查按需规则
进入 Shadowrocket 的 Settings → On Demand，核对功能是否启用以及现有条件。菜单中的具体规则选项以当前界面为准；先记录原状，不要把来源不明的规则直接替换进去。
-
检查系统状态
进入系统“设置 → 通用 → VPN 与设备管理 → VPN”，查看 Shadowrocket 对应配置与连接状态。若系统提供“按需连接”开关，同时记录它的状态；不同系统版本的显示位置可能略有差异。
-
验证实际触发
回到 Home 观察连接，再执行一次日常请求。分别记录锁屏、解锁、Wi-Fi 切换后的结果。若断开后立即重新连接，先检查 On Demand 条件和后台请求，不要直接认定连接开关失效。
-
做单变量对照
记录当前状态后关闭 On Demand，再在 Home 断开连接，确认系统 VPN 状态已改变。选择相同长度、相近负载的窗口观察；测试结束后恢复所需连接，避免影响后续网络访问。
短窗口只能帮助定位明显异常，不能代表全天续航。若两次测试的信号强度、亮屏时长或后台同步差别很大，应重新测试。不要把关闭连接后某些请求无法完成、流量自然减少的结果，直接描述为客户端效率提升。
五、频繁重连时，先查失败原因
高耗电伴随访问卡顿时，应先检查连接是否稳定。日志中的单条失败不一定异常；只有同一目标在短时间内重复失败，并与请求重试或状态反复变化相对应，才适合作为排查线索。以下是可能出现的底层错误文本，不代表每种连接都会显示相同文案。
报错：Operation timed out
原因：连接在等待期限内未完成，可能与链路丢包、目标不可达或远端响应有关。
解法：先在稳定网络重试一次，再向自己的服务商核对当前地址与端口；避免用连续测速代替原因确认。
报错：Connection refused
原因：目标地址可达但连接被拒绝，可能是端口未监听、服务状态变化或访问策略限制。
解法：核对已有配置中的服务器与端口，按自己的服务商提供的有效参数修正，不要猜测并轮流尝试端口。
如果自己的服务商确认配置已经变更，可在 Home 对已有 Subscribe 项执行更新，再核对当前选中的配置项。订阅更新用于取得最新配置，不是修复所有连接错误的通用方法；不要为了排查耗电而高频重复更新。
- 只有蜂窝网络异常：先比较信号与网络覆盖，保留同一配置，观察稳定 Wi-Fi 下是否仍会重复失败。
- 切换网络后异常：检查是否发生短暂重建；若长时间不能恢复，再查看对应时间的日志。
- 只有某个远端异常：核对该项参数与服务状态，避免一次修改全部已有配置。
- 提交排查信息：保留错误原文、发生时间和网络类型；分享前遮盖订阅链接、凭据、服务器地址及个人请求记录。
六、按使用场景选择，而不是默认全开或全关
若工作期间持续需要同一连接，稳定保持连接通常比反复手动切换更便于排查。若只在特定网络条件下需要连接，可考虑 On Demand，但应验证条件是否真正限制了触发范围。把规则设为任何网络都连接，未必能减少连接时间。
| 使用场景 | 优先检查 | 判断依据 |
|---|---|---|
| 长时间连续使用 | 连接稳定性、Global Routing 与实际流量 | 减少失败重试比反复切换开关更有针对性 |
| 仅特定条件使用 | Settings → On Demand 中的条件 | 条件外是否仍持续连接，条件内能否正确触发 |
| 夜间待机掉电明显 | 后台同步、信号环境及按需触发 | 相近待机窗口的整机电量变化是否可重复 |
| 断开后立即连回 | 应用与系统中的按需连接状态 | 先关闭按需触发，再验证手动断开结果 |
使用 Config 时，DOMAIN-SUFFIX 按域名后缀匹配，IP-CIDR 按地址网段匹配，GEOIP 按 IP 地理归属匹配，FINAL 承接前面未命中的请求。规则顺序和目标策略决定实际路径；配置了规则不代表所有请求都会直接连接。不要单纯为降低电池列表占比，把 FINAL 或需要代理的请求全部改成 DIRECT。
结论：以可重复的掉电变化为准
保留能够满足访问需求、连接稳定且对照结果正常的设置。如果只有应用占比升高，而整机待机掉电、温度和访问表现没有明显变化，不必仅为降低这个百分比反复修改配置。