先区分电池用量占比、整机实际掉电与网络重连，再决定是否启用 On Demand。本文适合已经使用自己配置、发现 Shadowrocket 后台用量偏高的 iPhone 与 iPad 用户：先用相同条件建立观察记录，再检查连接稳定性，最后在稳定常驻、条件触发和手动连接之间取舍。On Demand 是系统按条件建立连接的机制，不是固定的省电开关。
先读电池用量，不把占比当成掉电量
Shadowrocket（小火箭）的主界面退到后台，不代表系统 VPN 隧道已经断开。隧道仍可能处理其他应用的请求，因此电池页出现后台活动，本身不能证明存在异常。判断是否需要排查，应同时看整机掉电、屏幕使用情况、实际网络活动，以及异常是否能在相同条件下重复出现。
进入 iOS 系统设置的“电池”页面，选择可用的日期或时间范围，再查看 Shadowrocket 的用量及活动信息。不同系统版本的图表名称与可选范围可能变化，以当前设备显示为准。这里的应用电池用量百分比，表示所选范围内的用量分配，不等于该应用直接消耗了同等百分点的电池容量。
-
选定时段
在系统设置 → 电池中，选中出现异常的时段。先查看该时段是否同时有视频播放、相册同步、系统更新或热点使用，避免把整机负载归到一个应用。
-
记录条件
记下起止电量、观察时长、屏幕是否点亮、Wi-Fi 或蜂窝网络、是否充电，以及 Home 中的连接状态。建议先采用 60 分钟观察窗口；这是便于比较的时长，不是耗电合格线。
-
核对活动
查看当前时段的后台活动，并回想是否有其他应用持续传输。后台活动时长不能直接换算为 CPU 满负荷运行时长，也不能直接换算成额外掉电。
-
重复观察
在相同地点、相近信号强度和相同屏幕条件下重复记录。不要用一次充电中的观察与一次低信号下的观察，直接判断哪个连接设置更省电。
常驻连接与频繁重连，耗电路径不同
稳定常驻连接可能产生隧道处理、加密与协议维护流量，但连接时间长并不意味着一直有大量数据传输。另一方面，反复断开再建立连接，可能重复执行域名解析、传输连接建立、认证以及应用请求重试。在蜂窝信号较弱或网络切换频繁时，这些过程还会与无线网络自身的能耗叠加。
这条流程用于解释一种可观察的现象：设备在固定 Wi-Fi 下工作正常，离开覆盖范围后出现短时不可用，连接恢复后应用集中重试。如果日志时间点与网络切换一致，应先查连接稳定性，而不是立即更换协议或增加自动触发规则。单纯看到状态栏 VPN 标识，无法判断是否发生过这样的循环。
- 稳定空闲：屏幕关闭，业务请求少，连接状态没有反复变化。应先与相同负载下的手动断开记录比较，而不是根据连接时长下结论。
- 持续传输：视频、备份或文件同步经过隧道，处理量随实际流量变化。先暂停业务传输，再观察空闲状态，才能分开业务用量和连接维护。
- 周期性失败：短时间内重复连接失败、应用重试或连接建立。先检查已有配置的服务器地址、端口、认证字段和当前网络可达性。
- 频繁切网：在 Wi-Fi 边缘与蜂窝网络之间反复切换。先在单一、稳定网络里复测，再判断是否与 On Demand 的条件有关。
On Demand 控制连接时机，不替代分流规则
在 Shadowrocket 中进入 Settings → On Demand，检查当前开关与规则。On Demand 用于让系统依据所配置的条件决定连接行为；它不等于“屏幕关闭立即断开”，也不等于“只有打开 Shadowrocket 才连接”。后台应用的网络请求同样可能使满足条件的连接继续工作，具体行为需要结合规则及系统状态验证。
连接触发与流量去向是两层设置。Home → Global Routing 下，Proxy、Direct、Config、Scene 决定路由姿态；Settings → On Demand 决定按需连接条件。选择 Direct 不等于关闭系统 VPN 隧道，选择 Config 也不意味着只在匹配代理规则时才建立隧道。测试耗电时不要把这两组变量一起修改。
| 设置层 | 负责的事情 | 排查时怎么处理 |
|---|---|---|
| Home 连接开关 | 手动发起或停止当前连接。 | 建立手动连接基线；若要保持断开，先核对 On Demand。 |
| Settings → On Demand | 按配置条件交由系统触发连接行为。 | 先保留一项明确条件验证，再逐项增加条件。 |
| Home → Global Routing | 选择 Proxy、Direct、Config 或 Scene。 | 对照测试中保持同一姿态，不同时改变路由方式。 |
| Config | 管理配置文件及其分流规则。 | 确认使用的是预期配置，避免后台大流量意外经过代理出站。 |
例如，Config 中的 DOMAIN-SUFFIX,example.com,DIRECT 是域名分流规则，不是 On Demand 的连接触发规则。将业务流量改为 DIRECT 后，隧道仍可能存在。要测试“断开后是否改善掉电”，应控制 On Demand 并实际停止连接，而不是只切换到 Direct。
用单变量记录比较三种连接方式
先确认已有配置可以正常连接，再做耗电比较。不要在测试中同时刷新订阅、更换服务器、修改 DNS、切换协议和调整 On Demand，否则即使电池表现变化，也无法判断是哪一个因素造成。测试过程中暂停手动批量测速；测速本身会产生连接和网络流量。
-
保存现状
记录 Home 当前配置、Global Routing 姿态以及 Settings → On Demand 的原有设置。只记录本地必要信息，订阅完整链接与认证字段不要放进公开排查记录。
-
观察断开
关闭 On Demand 后，在 Home 停止连接。在不依赖该连接的相同轻负载下记录 60 分钟，确认期间没有自动重连。若断开会中断必要业务，跳过此组并注明原因。
-
观察常驻
保持 On Demand 关闭，在 Home 手动连接已有配置。使用相同网络、相近负载和同样时长，记录整机电量变化及是否发生重连。
-
观察按需
进入 Settings → On Demand，启用要验证的条件。记录条件是否实际命中、连接是否反复建立，以及在不使用前台应用时是否仍有后台业务请求。
-
复核差异
对出现明显差异的一组再重复一次。电量显示有取整，短时小幅变化不足以证明设置优劣；同时检查是否有发热、低信号或系统后台任务。
如果稳定常驻组正常、按需组反复连接，优先简化触发条件。如果两组都在同一网络下反复失败，先排查网络和已有配置。如果断开组也出现相近掉电，应继续检查系统电池页中的其他应用活动、信号和设备状态，避免只围绕 Shadowrocket 调整。
连接异常先排错，再讨论省电
查看当前配置可用的连接记录或日志，重点找失败发生的时间、目标地址和是否重复出现。下面列出的是网络日志中可能出现的原始错误片段；只有实际记录包含相应文本时，才按对应方向排查。不同协议和日志详细程度可能使用不同措辞，没有某条错误不代表网络一定正常。
报错: connection refused
原因与解法:目标连接被主动拒绝，常见于端口未监听或访问被拒绝——核对自己配置中的服务器地址与端口是否一致，并向已有服务商确认对应服务状态；不要只开关 On Demand 反复重试。
报错: i/o timeout
原因与解法:某个网络读写阶段超过等待时间，单凭该文本不能定位到服务器——先在稳定 Wi-Fi 与蜂窝网络分别复测同一配置，比较失败时间，再检查地址解析、网络可达性及已有服务的状态。
若错误只在 Wi-Fi 与蜂窝网络切换时集中出现，先固定网络复测；若固定网络下仍持续失败，核对配置字段。端口必须与已有配置一致，不能因为某个端口常见就随意改成 443。认证或传输参数不匹配，也不能靠缩短连接间隔解决。
- 按时间对齐：将失败时间与电池图表、离开 Wi-Fi 的时间对照，不根据单独一条历史日志推断整段耗电。
- 区分更新与连接：订阅更新失败表示配置列表获取出了问题，不等于当前已保存的连接一定失效。分别检查刷新记录与实际连接表现。
- 减少测试负载：完成定位后停止连续测速及不再需要的详细诊断记录，避免把诊断活动混入后续的日常耗电比较。
- 保护配置：反馈问题时保留错误文本与时间，遮去完整订阅链接、认证字段和不需公开的服务器信息。
按使用场景取舍，保留可验证的结果
持续需要连接、网络稳定的场景，可以先保留稳定常驻，重点检查后台大流量与异常重连。只在明确网络条件或特定需求下使用的场景，可以测试 On Demand，但要验证条件是否真正缩小了连接范围。使用时间少且能够自行控制的场景，手动连接通常更容易确认状态；这仍不构成统一的省电结论。
关掉主界面后，为什么电池页还有后台活动？
主界面与系统 VPN 隧道不是同一生命周期。先回到 Home 查看连接状态，再检查 Settings → On Demand；不要把关闭界面当成停止连接。需要做断开对照时，先关闭按需触发，再停止连接。
开了 On Demand，耗电一定会下降吗？
不一定。如果条件长期满足，或后台请求持续存在，连接仍可能长期保持；条件边界不稳定还可能伴随反复连接。先用相同网络完成常驻与按需两组记录，再依据连接次数和整机掉电决定。
晚上不用手机，要不要直接断开？
先确认夜间是否有依赖该连接的同步或其他业务。若不需要，可关闭 On Demand 并在 Home 停止连接，记录一晚的起止电量；对照晚间要保持相同的充电、网络和同步条件。
蜂窝网络更费电，是协议选错了吗？
先排除低信号、移动过程和反复切网。固定地点后，用同一已有配置分别观察 Wi-Fi 与蜂窝网络。只有网络条件和业务量可比时，才继续比较协议参数，不按协议名称直接作耗电排名。
最终保留一份能够复现的结论：在哪个网络、使用哪份已有配置、哪种 Global Routing 姿态、On Demand 是否启用，以及相同时长下的整机掉电与重连表现。优先修复连接失败和反复重试，再选择触发方式；不要用单次电池排名代替完整观察。