On Demand 决定系统何时按条件建立连接，不是低电量开关。排查 Shadowrocket 后台耗电，应先区分电池占比、实际电量下降与连接反复重建，再用相同网络和相近负载比较设置。本文适合已经有自己的服务商与订阅、需要在手动连接和自动连接之间作取舍的 iPhone/iPad 用户。
先读系统电池用量，不以后台时长判定耗电
Shadowrocket（小火箭）连接后，网络扩展可以在主应用不处于前台时处理流量。把应用切到后台，并不等于断开 VPN；状态栏出现 VPN 标记，也不代表设备正在持续高速传输。后台活动时间、连接持续时间和实际能耗不是同一个指标。
在 iPhone/iPad 的系统设置 → 电池中，先选定统计时段，再查看电池电量曲线、屏幕活动以及 Shadowrocket 的用量。系统界面的具体名称可能随系统版本变化。应用旁的百分比通常表示选定时段内的用电占比，不能直接当作整块电池下降的百分点，也不能把后台小时数换算成耗电量。
例如，同样下降 5 个电量百分点的两段时间，其他应用使用越少，Shadowrocket 的占比就可能越突出。这只能提示继续检查，不能据此判断某项设置使耗电翻倍。流量处理相关的能耗还会受到系统归因方式影响，单个应用的数字不等于完整的网络能耗。
结论：先核对整机掉电，再调整连接条件
如果后台时长增加，但相似待机条件下整机电量下降没有明显变化，先保留当前配置；如果电量曲线持续变陡，再对照同一时段的流量、信号和重连记录。
On Demand 控制自动连接，不控制所有后台流量
Settings → On Demand 用于配置按条件触发的连接行为。符合已配置条件时，系统可以发起连接；它不是每次打开应用才连接的开关，也不能概括为“没有流量就立即断开”。实际行为需要结合 Wi-Fi、蜂窝网络和域名等已启用条件判断。
关闭 On Demand 后，已经建立的连接不应被理解为一定自动结束。做手动对照时，应回到 Home 确认连接开关及系统 VPN 状态。反过来，如果 On Demand 仍开启，手动断开后又遇到触发条件，系统可能再次连接，这通常是条件生效，不是单纯的开关失灵。
| 设置或姿态 | 主要控制内容 | 耗电排查中的含义 |
|---|---|---|
| On Demand | 系统何时按条件发起连接 | 检查是否因网络切换或条件匹配而反复连接 |
| Global Routing → Proxy | 将流量交由代理路径处理 | 处理的流量范围改变，不能直接与另一模式比较 |
| Global Routing → Direct | 使用直连路径 | 不等于关闭 VPN，也不是停止网络扩展的开关 |
| Global Routing → Config | 按当前配置中的规则处理流量 | 应保留相同配置，避免规则变化干扰对照 |
| Global Routing → Scene | 使用已设置的 Scene | 需要核对当前 Scene 的实际设置，不能只凭名称推断路径 |
因此，“开启 On Demand 比关闭更省电”没有统一答案。如果关闭后仍保持相同连接、承载相同流量，差异可能很小；如果自动条件减少了不需要的连接时间，可能降低消耗；如果条件过细导致不断重建连接，也可能增加开销。
按四步建立可重复的电池对照
测试应覆盖平时出现问题的场景，而不是一边持续运行延迟测试、一边观察待机电量。以下时长是便于记录的实验安排，不是续航承诺。测试期间保留原有配置，不要同时更换协议、节点和路由模式。
-
记录基线
在系统设置 → 电池记录起始电量、所选时段与屏幕活动；在 Home 记录当前连接项和 Global Routing。选用同一个 Wi-Fi，暂停大文件传输，先观察 60 分钟。
-
关闭自动连接
进入 Settings → On Demand 关闭按需连接，再回 Home 手动连接。保持相同负载观察 60 分钟。这一轮比较的是手动维持连接，不是完全断开后的待机。
-
启用所需条件
进入 Settings → On Demand，仅启用当前场景实际需要的条件。保持相同连接项、Global Routing 和网络，再观察 60 分钟，记录是否自动连接或反复重连。
-
复测异常时段
若两轮差异明显，另选相近时段重复一次。若需要增加完全断开的基线，先关闭 On Demand，再在 Home 断开，并确认系统 VPN 状态；只在业务允许断开时执行。
一小时内的整数电量变化可能受显示粒度、温度和后台任务影响，不能凭一次相差 1 个百分点下定论。不要在充电、系统集中同步、照片上传或弱信号移动途中，把两轮数字直接相减。出现发热时，也要同时核对屏幕亮度、蜂窝信号和前台应用负载。
后台耗电增加时，先查重连与网络质量
连接建立、加密处理、网络收发和重复请求都会产生开销。Wi-Fi 与蜂窝网络来回切换、信号较弱或服务端暂时不可达时，连接可能反复建立，其他应用也可能不断重试请求。需要结合故障发生时间看记录，而不是只看最后一次测试成功与否。
下列是网络诊断中可能出现的错误文本片段，不同协议及系统版本的完整日志可能不同。它们用于识别失败类别，不代表已经测出电池消耗，也不要求日志一定逐字一致。
报错：connection timed out
原因：连接在等待期限内未完成，可能涉及网络丢包、目标不可达或端口不匹配，不能仅凭这一条确定故障位置。
解法：在 Home 核对所选连接项，按用户已有资料检查服务器地址与端口，再分别在稳定 Wi-Fi 和蜂窝网络做一次连接测试，避免持续循环测试。
报错：certificate has expired
原因：TLS 证书有效期检查失败，可能是服务端证书到期，或设备时间偏离证书有效区间。
解法：先在系统设置 → 通用 → 日期与时间核对自动设置及实际时间，再向自己的服务商确认服务端证书状态，不以关闭证书校验作为修复方法。
- 只在蜂窝网络出现：先观察信号和移动状态。无线网络质量变化会增加重传及无线通信开销，不能直接归因为 On Demand。
- 在切换网络后密集出现：检查 Settings → On Demand 的网络条件是否符合预期，记录切换前后实际连接状态。
- 只在某个连接项出现：逐项核对用户已有的协议参数，不要连续切换多种协议后把最后一次结果当作电池结论。
- 没有错误但流量持续增长：检查照片同步、云备份、视频播放和应用后台刷新。有效传输同样可能增加用电，并非只有连接失败才需要排查。
检查协议与配置，避免把路由变化当作节电效果
Shadowsocks、VMess、VLESS、Trojan、Hysteria2 和 WireGuard 的连接机制、传输方式及参数不同，但协议名称不能直接换算成固定耗电排名。实际开销与设备、网络质量、流量规模、服务端设置及连接是否稳定共同有关。应先使现有配置稳定，再考虑有依据的单项调整。
在 Home 打开当前连接项的编辑界面，按原始资料核对协议、服务器、端口及认证信息。例如资料指定 TLS 端口为 443，就应核对是否一致；443 只是常见示例，并非所有协议和服务端的统一端口。涉及 TLS 时，还要按资料检查服务器名称与相关设置。
- Config：确认测试期间使用相同配置；在 Global Routing 为 Config 时，规则变化会改变流量去向。
- DOMAIN-SUFFIX / GEOIP / IP-CIDR：这些关键字用于不同类型的规则匹配，不是降低 CPU 占用的电池开关。
- FINAL：用于前面规则均未命中时的末尾处理。调整末尾处理可能改变大量流量的路径，因此不能与 On Demand 同时修改后直接比较。
- 订阅更新：只更新用户已有的订阅，并检查更新后当前连接项是否改变。对照期间若参数发生变化，应重新记录基线。
延迟测试、订阅刷新和主动诊断本身会产生网络请求。它们适合定位问题，但不应在整个待机对照期间持续运行。先完成一次必要检查，再留出不主动操作的观察时段。
按使用场景决定开启还是关闭
取舍应依据是否需要自动恢复连接，以及触发条件能否准确表达使用场景。如果用户需要某些网络请求始终遵循当前配置，不应仅为追求较低的电池数字而任意断开；如果只在明确时段使用，手动连接可以让连接边界更容易确认。
| 使用场景 | 可选策略 | 验收依据 |
|---|---|---|
| 仅在固定任务期间连接 | 关闭 On Demand，由 Home 手动连接和断开 | 任务结束后 VPN 状态符合预期，必要业务不受影响 |
| 经常切换 Wi-Fi 与蜂窝网络 | 按需要配置 On Demand 的网络条件 | 切换后能恢复所需连接，且没有短时间密集重连 |
| 仅特定请求需要触发连接 | 核对 On Demand 中相关域名条件 | 目标请求能触发预期行为；需注意缓存及已有连接可能影响观察 |
| 夜间待机掉电异常 | 先比较相同连接下的开关状态，再按需增加断开基线 | 结合整机电量曲线、后台传输和错误记录判断 |
结论：保留必要自动连接，减少无效反复触发
如果 On Demand 能稳定满足连接需求且没有异常重连，可以保留；如果关闭后只减少了不需要的连接时间，可改用手动控制；如果两种状态都耗电，继续检查实际流量、网络质量和连接参数，而不是反复切换开关。
Shadowrocket 是 Apple 平台的付费客户端，以 iPhone/iPad 为主；设备兼容性与系统要求以 App Store 页面标注为准。客户端采用一次性买断，客户端买断 ≠ 线路套餐。本文只说明用户已有配置的检查方法，不提供、不销售、不推荐节点或订阅。