Shadowrocket（小火箭）的后台活动时长不等于额外耗电量，On Demand 也不是定时休眠开关。本文适合需要核对 iPhone、iPad 待机耗电与自动重连行为的用户：先读取系统电池统计，再检查 Settings → On Demand，最后用同条件对照判断应保留自动连接，还是改为手动连接。
先看电池统计，不凭 VPN 标识判断耗电
VPN 连接可以在 Shadowrocket 不处于前台时继续工作，这是系统网络扩展的正常使用方式。状态栏出现 VPN 标识，表示存在 VPN 连接，不代表处理器持续高负载，也不能单独证明设备正在大量传输数据。后台同步、视频播放、网络信号和反复重连，都可能改变同一时段的电量消耗。
系统电池列表中的应用百分比，通常是所选时段内各项用电的相对占比，并非这款应用直接消耗了电池容量的同等百分点。其他应用使用减少时，Shadowrocket 的占比可能上升，即使整机掉电没有增加。网络扩展相关能耗的归属也受系统统计口径影响，不宜只看一行数据下结论。
-
打开电池页
进入系统设置 → 电池，查看电量曲线与应用用电列表。不同系统版本的统计区间和按钮名称可能不同，以设备实际显示为准。
-
选定时间段
选中需要核对的日期或时段，先确认当时是否充电、是否长时间亮屏，以及是否发生大文件传输。不要把充电中的时段与整晚离电待机直接比较。
-
查看活动
在应用列表中找到 Shadowrocket，读取系统提供的用电占比与活动时间；若页面可切换活动显示，再区分屏幕活动和后台活动。后台时间长只说明统计到活动，不能直接换算成耗电量。
-
记录环境
同时记录时段起止电量、Wi-Fi 或蜂窝网络、信号状况、屏幕使用时间与 VPN 状态。保留原始记录，后续只调整一个设置进行比较。
On Demand 管连接，Global Routing 管流量去向
On Demand 使用系统按需 VPN 机制，根据已经配置的条件决定是否发起连接。它不是“没有流量就一定断开”的空闲计时器，也不保证每次锁屏后都停止连接。满足条件后，系统可能重新建立隧道，因此出现“刚断开又连上”时，应先核对按需规则，而不是立即认定开关失效。
在 Home → Global Routing 中，Proxy、Direct、Config 与 Scene 属于路由选择，不是四种省电等级。Proxy 将流量交给代理策略处理；Direct 采用直连；Config 按当前配置中的规则处理；Scene 用于按场景选择路由行为。将 Global Routing 改为 Direct，不等于关闭系统 VPN 隧道。
同样，DOMAIN-SUFFIX、GEOIP、IP-CIDR、FINAL 是流量匹配规则关键字，不是 On Demand 的自动连接开关。排查耗电时先保持路由配置不变，否则同时改变连接方式与流量路径，很难判断哪一个变量影响了结果。
核对触发条件，再测试网络切换
系统按需规则可以依据网络环境或连接评估结果工作，实际可用条件取决于应用提供的设置与现有配置。检查时只记录当前页面确实存在的项目，不要把普通分流规则当作按需条件，也不要假定某个 Wi-Fi 名称天然属于可信网络。公共 Wi-Fi 的名称还可能重复，不能仅凭名称作安全判断。
-
保存当前项
记录 Home 的连接状态、Global Routing 当前选择，以及当前配置名称。本文以用户已有自己的服务商与订阅为前提，不需要为测试新增连接资源。
-
核对开关
进入 Shadowrocket 的 Settings → On Demand，查看开关状态和页面实际提供的条件。若配置包含网络限制，记录其匹配对象与处理方式，再保存变更。
-
切换网络
回到 Home，分别检查当前 Wi-Fi、另一可用 Wi-Fi，以及设备支持时的蜂窝网络。每次只切换一种网络，等待网络恢复可用，再观察 VPN 是否自动建立。
-
验证断开
在不影响必要业务时手动断开，观察是否再次连接；随后关闭 On Demand，再重复一次。若两次表现不同，说明按需设置参与了重连，但还需结合网络条件确认具体触发原因。
| 观察场景 | 需要核对 | 判断边界 |
|---|---|---|
| 加入 Wi-Fi 后连接 | 当前网络是否匹配已配置的按需条件 | 加入网络可能引发规则重新评估，不代表所有 Wi-Fi 都应连接。 |
| 切到蜂窝网络后连接 | 按需条件是否覆盖蜂窝环境、当前网络是否可用 | 网络变化与重连同时出现，仍需对照开关测试确认。 |
| 锁屏后仍保持连接 | 现有隧道状态、后台业务与按需规则 | 锁屏不是必然断开条件，保持连接不等于持续高流量。 |
| 手动断开后又连接 | On Demand 是否仍开启，系统 VPN 配置是否仍按需连接 | 条件继续满足时，系统可能再次建立连接。 |
常驻、按需与手动连接的取舍
这里的“常驻”指较长时间维持连接，“按需”指交由系统按规则发起连接，“手动”指由用户主动连接和断开。它们不是三个互斥的协议：开启 On Demand 后，连接仍可能持续很久。选择依据应是业务是否需要连续可达、网络是否稳定，以及能否接受首次请求前的连接等待。
常驻连接
减少主动连接操作，便于持续使用依赖当前网络路径的业务。但后台请求仍会经过相应处理，弱信号与反复重试可能增加消耗；连接保持本身不能说明耗电一定偏高。
适合：需要连续访问、长时间同步，且已验证网络稳定的场景。
On Demand
满足已配置条件时由系统发起连接，减少遗漏手动连接的情况。规则覆盖范围过宽时，可能表现得接近常驻；网络频繁变化时，还需要观察重建连接的次数与等待。
适合：需要随网络环境自动连接，并愿意逐项验证触发条件的场景。
手动连接基线
推荐排查期间先关闭 On Demand，按固定时间连接与断开，便于隔离自动重连这一变量。这是诊断起点，不是对所有用户的长期省电结论；断开期间的业务路径会随之改变。
适合：建立耗电对照、定位自动重连，以及只在明确时段使用的场景。
结论：先隔离自动重连
如果主要问题是“断开后又连接”，先关闭 On Demand 并验证状态；如果连接一直稳定而整机掉电增加，应继续检查流量、屏幕和信号，而不是反复切换按需开关。
用同条件对照判断，而不是套用省电比例
不存在适用于所有设备的 On Demand 省电百分比。连接协议、服务端响应、无线网络状态、应用请求频率和系统活动都会影响结果。为获得可解释的记录，可以安排两个长度相同的观察时段，例如各 60 分钟；这个时长只是便于操作的测试安排，不是应用性能指标。
- 固定设备条件：使用同一设备、相近的起始电量和相同网络，保持屏幕使用方式一致，避免一个时段亮屏播放视频、另一个时段全程待机。
- 固定连接参数：沿用同一已有连接、同一配置及同一 Global Routing 选择，不在两轮之间更换协议或更新订阅内容。
- 只改一个变量：第一轮关闭 On Demand 并手动建立连接，第二轮开启已核对的按需条件，记录实际连接持续情况；若两轮都全程连接，测试并未形成“连接时间减少”的对照。
- 同时看两类记录：记录整机电量变化，也记录系统电池列表中的活动信息。不要把应用占比下降直接等同于整机续航改善。
- 复测异常：若某轮遇到信号明显变弱、系统更新或大量后台同步，应标注干扰并另选时段复测，不把一次结果推广为固定结论。
如果目标是比较“连接”与“完全断开”，必须另设断开时段，并确认依赖该连接的业务是否仍能完成。业务请求失败、停止同步后掉电减少，不能证明同等工作量下效率提高。测试期间不要停止自己需要连续运行的业务。
后台耗电仍高时，按现象继续排查
按需连接解决的是何时建立连接，不负责修复服务端超时，也不会自动减少所有业务请求。若关闭 On Demand 后仍有明显耗电，应把连接稳定性与实际流量分开检查。Shadowrocket 的 Data 可辅助查看流量变化，但流量字节数与电池消耗之间不存在固定换算关系。
| 现象 | 下一步操作 | 避免误判 |
|---|---|---|
| Data 中流量持续增长 | 暂停可控制的视频、云同步或大文件任务，再观察变化。 | 先识别业务负载，不把全部传输都归因于 On Demand。 |
| 网络切换时反复失败 | 先在稳定 Wi-Fi 下复测，核对已有连接参数与服务可达性。 | 不要同时更换协议、路由和按需条件。 |
| 关闭开关后仍自动连接 | 核对系统设置 → 通用 → VPN 与设备管理 → VPN，确认实际连接的配置；系统路径以设备显示为准。 | 确认正在运行的是哪一个 VPN 配置，勿直接删除受管理的配置。 |
| 断开后整机仍明显掉电 | 继续检查系统电池曲线、其他应用活动及无线信号。 | 保留与 Shadowrocket 无关的系统耗电因素。 |
不建议把强制关闭应用当成正常的断开步骤：应用界面退出与系统网络扩展停止并不是同一件事。需要停止连接时，使用 Home 中的连接开关，并确认系统状态；需要停止自动建立连接时，再核对 On Demand。两步分别验证，才能得到可重复的结果。
结论：按需求保留设置
完成对照后，若自动连接符合使用需求且没有反复重连，可保留 On Demand；若只在固定时段使用，手动连接更便于控制。最终依据是同条件下的整机电量与业务可用性，而不是单一后台时长。