判断 Shadowrocket 是否增加耗电，应同时看设备总掉电、系统电池归因和连接是否反复重建。本文适合已经拥有自己的连接服务与订阅、需要在持续连接和 On Demand 之间选择的用户：先建立可比较的记录，再调整触发条件，最后核对网络切换与锁屏后的行为，不凭 VPN 图标或单次用量占比下结论。
先区分后台界面、VPN 隧道与实际流量
Shadowrocket（小火箭）是通过 App Store 发行的 Apple 平台付费客户端，采用一次性买断。正版核对包括官方图标、开发者 Shadow Launch Technology Limited 和应用 ID 932747118；系统要求与兼容范围以 App Store 页面标注为准。客户端购买与用户已有连接服务是不同事项，购买本身不包含线路套餐。
回到主屏幕后，应用界面不在前台，不代表系统 VPN 隧道已经停止。连接期间，相关网络扩展仍需处理经过隧道的流量。反过来，状态栏出现 VPN 标识，也不能证明设备正在持续高速传输。空闲连接、视频播放和弱信号下反复重连的能耗条件并不相同。
耗电可能来自加密处理、数据收发、连接维护、DNS 查询，以及失败后的重试。屏幕亮度、后台同步和蜂窝信号也会影响设备总耗电。因此，“后台运行了多久”只能说明活动持续时间，不能直接换算成多消耗了多少电量。
常驻连接与 On Demand：改变的是连接时机
持续连接适合需要较稳定网络路径的使用方式。连接已经建立时，后续请求通常不必重新等待隧道启动，但空闲阶段仍可能存在连接维护和系统网络活动。On Demand 则由系统按照配置条件决定连接行为，不是“屏幕熄灭就断开”，也不是只识别当前正在操作的应用。
| 设置方式 | 连接行为 | 应核对的代价 |
|---|---|---|
| 持续连接 | 保持隧道，实际传输量由应用活动决定。 | 空闲维护、弱信号下重试，以及持续后台传输。 |
| On Demand | 按网络或域名等已配置条件触发系统连接行为。 | 首次连接等待、条件反复变化，以及过于宽泛的触发。 |
| 手动连接 | 由用户在 Home 主动连接和断开。 | 容易忘记开启或关闭，需要明确操作习惯。 |
如果通知、同步或其他后台请求经常满足触发条件，On Demand 仍可能使连接长时间保持。若 Wi-Fi 与 Cellular 频繁切换，或者已配置的 SSID 条件相互冲突，反复启动隧道还会增加连接开销。不能仅凭开启了按需连接，就认定电池续航一定改善。
结论：先减少无效重连
在网络稳定、配置相同的前提下比较两种方式；如果日志显示不断连接、断开，应先修正触发条件或网络问题，再评估 On Demand 的电量收益。
用系统 Battery 页面建立可比较记录
在 iPhone 或 iPad 的系统 Settings → Battery 中查看电池用量；中文系统对应“设置 → 电池”。不同系统的时间范围与图表入口可能不同，应选择能覆盖本次测试的时段，同时记录屏幕活动和后台活动。系统显示的应用占比是该统计范围内的用电归因比例，不是电池容量下降了相同的百分点。
-
固定环境
使用同一设备、同一 Wi-Fi、同一连接配置与相近屏幕亮度。测试期间不充电，避开系统更新、照片集中同步和大文件传输。
-
记录起点
打开系统 Settings → Battery，记下起始时间、电量和网络类型。另记 Shadowrocket 是否连接，以及 Settings → On Demand 是否启用。
-
保持连接
先观察持续连接的 30 分钟：按预先确定的使用方式操作，或保持锁屏静置。结束后记录电量与异常重连，不把亮屏使用和锁屏静置混成一组。
-
测试按需
改用已核对的 On Demand 条件，再观察同样的 30 分钟。保持应用活动尽量一致，并记录实际是否触发连接，而不是只记开关状态。
-
重复核对
换一个相近时段重复，交替测试顺序。结合系统电池图表和每次总掉电判断；短窗口电量没有变化，不能据此认定没有能耗。
这里的 30 分钟是便于执行的观察窗口，不是续航测试结果。电量百分比存在取整，后台任务也有波动；若两次差异很小，应延长记录并重复观察，而不是给出固定的“节省百分比”。设备发热时，还应同时排查信号、屏幕与其他应用活动。
Settings → On Demand 的配置核对顺序
在 Shadowrocket 的 Settings → On Demand 检查当前按需设置。先记录原有条件，再一次只改一项。具体条件名称与可选动作以当前界面为准；SSID 要按设备实际连接的 Wi-Fi 名称填写，域名条件也不能当作通用的网址过滤器使用。
- 先看默认行为：确认未命中指定条件时会如何处理，避免只配置了例外，却遗漏其余网络的连接行为。
- 再看 Wi-Fi：核对 SSID 的拼写、空格与大小写。家中不同频段若使用不同名称，应分别验证，不能只看路由器设备名。
- 单独看 Cellular：离开 Wi-Fi 后观察是否按预期连接。信号差造成的超时不能通过增加触发条件解决。
- 最后看域名：有域名触发条件时，应实际访问目标并确认行为。缓存与已有连接会影响观察，单次打开页面不足以证明规则始终有效。
- 测试锁屏：分别检查锁屏后、解锁后、网络切换后的状态，记录是否反复重建连接。
例如，计划在家中 Wi-Fi 不保持连接、在 Cellular 使用连接时，应先确认家庭网络确实满足日常访问需求，再设置对应条件。之后完成“家庭 Wi-Fi、关闭 Wi-Fi、重新加入家庭 Wi-Fi”三个场景的检查。切换时出现短暂等待可以来自连接建立；持续转圈则应进入连接排错，不能一概视为按需连接的正常现象。
Global Routing 与协议设置不能代替耗电诊断
On Demand 决定何时触发连接，Global Routing 决定连接后的路由处理，两者属于不同层次。Home → Global Routing 下的 Proxy、Direct、Config、Scene 不应被理解为四个电量档位。尤其是 Direct，不能简单等同于系统 VPN 隧道已经关闭。
| 姿态 | 核对重点 |
|---|---|
Proxy | 主要按代理方式处理流量，检查实际传输量与连接质量。 |
Direct | 主要直接连接目标，不代表网络扩展一定停止工作。 |
Config | 按当前配置规则分流，检查命中规则与最终策略。 |
Scene | 核对当前场景配置及其实际采用的路由行为。 |
使用 Config 时，DOMAIN-SUFFIX、GEOIP、IP-CIDR 与 FINAL 等规则决定请求去向，不是电量控制指令。若某个应用反复请求失败，应先确认它命中了哪条规则、最终使用什么策略，再判断是否需要调整，而不是为了减少后台活动直接改成全部 Direct。
Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 的连接维护方式与传输特性不同，但不能脱离设备、信号和服务端参数给出统一的省电排名。先保持用户已有服务所要求的协议与参数正确，再做单变量比较；随意修改端口、传输方式或保活参数，可能把稳定连接变成持续重试。
- 比较路由姿态时，保持 On Demand 条件不变。
- 比较协议时，确认服务端确实支持对应配置，不只改客户端名称。
- 完成诊断后关闭临时开启的详细调试记录，避免长期保留不必要的诊断活动。
出现超时与重连时，先处理连接故障
电量上升同时伴随反复失败时，应把连接错误与系统 Battery 时间段对照。下面是连接日志中可能遇到的错误原文片段，完整格式取决于协议与日志来源；它们说明网络故障方向，不直接证明电池损耗来自哪个组件。
报错：i/o timeout
原因：读写操作在限定时间内未完成，可能与当前网络不可达、信号不稳或远端无响应有关。
解法：保留原配置，分别在稳定 Wi-Fi 与 Cellular 测试同一连接，核对失败是否只发生于某一网络；不要让无效连接持续重试。
报错：connection refused
原因：连接目标主动拒绝请求，常见于端口不正确或对应服务没有监听。
解法：核对用户已有服务的地址、端口与协议；必要时向自己的服务商确认状态，修正后再恢复按需触发。
若错误在订阅更新后开始，先核对当前选中的连接项目是否改变，以及原先的地址和协议参数是否仍然适用。不要通过连续刷新订阅来处理所有超时；订阅更新只能取得配置内容，不能修复弱信号或远端服务故障。诊断截图与日志发送前，应隐藏订阅链接、认证信息及其他敏感内容。
结论：按使用需求保留连接
需要连续访问时优先验证稳定性；有清晰网络边界和较长空闲时段时，再测试 On Demand。只有总掉电、实际连接状态和使用活动能相互印证，才把某种设置保留为日常方案。