Shadowrocket（小火箭）出现在电池用量前列，不等于连接异常。先核对统计时段、实际流量和网络稳定性，再决定是否调整 Settings → On Demand。本文适合已有自己服务商与订阅、需要排查待机耗电的 iPhone / iPad 用户；按步骤可建立对照记录，区分持续传输、失败重试与连接策略带来的影响。
一、先读懂 iOS 电池统计，再判断耗电是否异常
先打开 iPhone / iPad 的系统“设置”→“电池”，选择页面提供的统计时段，再查看 Shadowrocket 对应的电池用量和活动记录。不同系统的图表与筛选入口可能不同，应以设备实际显示为准。先确认看到的是整段时间的数据，还是点选某个小时、某一天后的局部数据。
应用旁的百分比表示所选时段内的电池用量占比，不是电池容量直接减少的百分点。例如，某时段设备电量从 80% 降到 70%，Shadowrocket 的用量占比显示 30%，不能据此说它消耗了整块电池的 30%。充电、其他应用活动和系统统计归因都会影响解读，也不宜将这两个数字简单相乘当作精确测量。
- 看绝对掉电：记录开始与结束电量、观察时长以及是否充电；仅看应用排名无法判断待机是否异常。
- 看使用内容：视频、云同步、大文件传输即使发生在其他应用，也可能让 VPN 隧道持续处理数据。
- 看屏幕状态：区分亮屏使用与锁屏待机；两种状态混在一起，不适合比较连接策略。
- 看网络条件：记录 Wi-Fi、蜂窝网络及是否频繁切换。弱信号下无线通信本身也会增加耗电。
二、后台连接为什么会耗电
连接开启后，系统将相关网络流量交给 VPN 隧道处理。Shadowrocket 根据当前 Global Routing 姿态及配置决定后续路径，过程中可能涉及规则判断、DNS 查询、加解密和连接维护。主应用退出到后台，不代表系统已经关闭隧道。
持续下载会增加传输量；连接不稳定则可能增加握手、超时等待和重试。锁屏以后，云端同步或其他被系统允许的后台任务仍可能发出请求。因此，排查时要同时看“有多少数据经过”和“连接是否反复失败”，不能只看 VPN 标志是否存在。
- 持续传输：先暂停大文件下载、视频播放和同步任务，再观察待机，避免把正常业务流量当作连接空耗。
- 频繁重连：在 Home 查看连接状态，并结合可用的连接记录核对失败时间是否与 Wi-Fi、蜂窝网络切换重合。
- 额外诊断：停止不再需要的抓包或详细记录任务，避免把诊断期间的数据与日常使用混在一起。
- 重复测试：不要连续对全部已有连接执行测试后，立即拿这一时段作为待机样本。
协议名称不能直接推导电池表现。Shadowsocks、VMess、VLESS、Trojan、Hysteria2 和 WireGuard 的实际开销还受服务端参数、传输量和网络质量影响。为排查耗电，不应同时更换协议与连接策略；应先保持用户已有的可用配置不变。
三、On Demand 与持续连接分别解决什么问题
Settings → On Demand 用于配置按需连接行为，由系统结合配置条件触发 VPN 连接。它不是识别“当前有没有人在看屏幕”的省电开关，也不等于只在打开 Shadowrocket 时连接。具体可用条件以应用内页面为准，启用前应逐项核对已有设置。
| 设置姿态 | 行为与适用场景 | 需要核对 |
|---|---|---|
| 保持连接 | 在持续需要既定路由时保留隧道，减少主动断开造成的连接中断。 | 业务是否持续传输，网络是否稳定，是否出现反复重连。 |
| On Demand | 让系统按配置条件发起连接，适合能明确描述网络使用条件的情况。 | 条件是否过宽，切换网络后是否符合预期，是否仍有请求触发连接。 |
| 手动断开 | 适合明确不需要隧道的时段；断开后后续请求不再沿原有隧道路由。 | On Demand 是否可能重新触发连接，以及业务是否允许改变网络路径。 |
结论：先验证连接条件，再比较耗电
如果启用 On Demand 后隧道仍一直存在，先检查触发条件和后台请求，不要立即认定设置无效。只有两组样本的网络、业务与时长相近，电池变化才有参考意义。
On Demand 与 Global Routing 是两件事：前者关系到连接如何被触发，后者关系到连接建立后的流量处理。Global Routing 中的 Proxy、Direct、Config、Scene 不是四档省电等级。尤其 Direct 不等于关闭 VPN；不要用切到 Direct 代替一次真正的断开测试。
四、用五步建立可回退的耗电对照
先保存当前配置，并记下 Home → Global Routing 的选择以及 Settings → On Demand 的原始状态。测试不需要删除已有订阅，也不需要重新导入配置。以下时长仅用于安排观察，不是承诺任何设备都能测出固定差值。
-
记录基线
在系统“设置”→“电池”记录起始电量与时间；记下当前网络、屏幕状态及是否充电。选择例如 60 分钟的锁屏观察窗，期间暂停主动下载。
-
核对连接
打开 Home，确认现有连接和 Global Routing 姿态。保留当前可用配置，不同时切换服务端、协议或 Config，先完成一次原设置下的观察。
-
调整按需
进入 Settings → On Demand，核对并记录当前条件，再只调整这一项。不要仅凭开关状态判断结果，返回 Home 查看实际连接，并进行一次必要的业务访问。
-
重复观察
在相同 Wi-Fi、相近起始电量和相同时长下再观察一次。记录结束电量、是否自动连接、是否发生网络切换，以及访问是否符合预期。
-
判断并回退
若差异只有 1 个电量百分点，不急于下结论，改日重复。若出现访问中断或意外重连，先恢复 Settings → On Demand 的原设置，再排查具体条件。
不要在一组样本中全程亮屏、另一组样本中全程锁屏，也不要一组使用蜂窝网络、另一组使用 Wi-Fi。设备温度、信号、云同步和充电状态都可能掩盖设置差异。这里采用手动记录，不提供未经测量的“省电百分比”。
五、反复连接与超时：按实际错误处理
如果待机时连接反复失败，先处理网络可达性，再比较 On Demand。以下是连接诊断中可能出现的英文错误片段，不代表每个界面都会用相同文案；只有实际记录出现对应内容时，才按该分支检查。没有报错时，不必为凑齐检查项目主动制造故障。
报错：connection timed out
原因：目标连接在等待时间内未完成，可能与当前网络、目标地址可达性或服务端状态有关。
解法：先确认普通网络访问正常，再核对用户已有连接的地址与端口；换到稳定网络复查，持续失败时向自己的服务商确认状态，不要连续重复测试。
报错：connection refused
原因：目标端口的连接被拒绝，可能是端口填写不符、服务未监听或访问被明确拒绝，并非 On Demand 自身的省电问题。
解法：对照已有服务参数核对地址和端口，不要自行猜测改成 443；端口一致仍失败时，保留错误时间交由自己的服务商核查。
报错：network is unreachable
原因：当前环境缺少到目标的可用网络路径，网络切换或基础网络不可用时可能出现。
解法：先完成 Wi-Fi 联网或确认蜂窝数据可用，待网络稳定后再连接；若只在切换网络时出现，记录切换前后的状态，不要同时修改规则。
订阅更新与隧道维持也应分开排查。只有更新失败时才检查 Subscribe 对应的更新操作，不要为了耗电问题频繁刷新订阅。更新请求本身会产生网络活动，但一次失败并不能证明它解释了整段时间的后台电池用量。
六、常见疑问与保留设置的判断标准
划掉后台里的 Shadowrocket，就能停止耗电吗？
不要把关闭主应用界面当作关闭隧道。返回 Home 检查连接开关，并核对 Settings → On Demand 是否会再次触发连接。需要做断开对照时，应确认系统的 VPN 状态确实已变化。
开了 On Demand，为什么锁屏后还连接着？
锁屏不是 On Demand 必然断开的条件。先检查 Settings → On Demand 内的实际条件，再确认同步等后台任务是否仍有网络请求。不要为了让 VPN 标志消失而随意删除连接条件。
把所有流量改成 DIRECT 会更省电吗？
DIRECT 是出站策略，不是关闭隧道的操作。Home → Global Routing 选择 Config 时，还需要结合 Config 中的规则判断请求路径。不要为一次耗电测试批量改写 DOMAIN-SUFFIX、GEOIP 或 FINAL；先保留规则，只对连接状态做单变量测试。
电池排名很高，但一小时只掉一点电，要处理吗？
先记录完整时段的实际掉电与业务量。如果设备待机符合预期、连接稳定，仅凭排名不足以认定异常。再做至少两次相近条件的观察，确认是否存在持续、可复现的额外掉电。
换一种协议就能解决吗？
先排除弱信号、连续传输和失败重试。确有必要比较时，仅使用自己已有服务支持的参数，保持网络与业务一致，每次只更换一个变量；不能依据协议名称预设耗电结果。
最终保留哪种设置，应同时满足两点：所需业务能按预期访问，重复观察没有显示明显异常耗电。需要持续采用既定路由时，可以保留连接；只在明确条件下需要连接时，再使用核对过的 On Demand。任何调整导致访问异常，都先恢复原设置，而不是继续叠加更多修改。