Shadowrocket（小火箭）在后台维持 VPN 隧道，并不等于持续高速传输。本文适合已经使用自己的服务商与订阅、希望排查待机掉电的用户：先读懂系统电池统计，再区分 On Demand 的自动连接与手动常驻，最后用固定时段对照测试，选择适合 Wi-Fi 和蜂窝网络的连接方式。
先读电池统计：耗电占比不等于掉电百分点
在 iPhone 或 iPad 的系统设置中打开“电池”，查看可用的用量时段，并选中怀疑耗电异常的时间范围。系统界面会随系统版本调整，重点记录四项：该时段电量变化、屏幕使用情况、Shadowrocket 的用量占比，以及是否出现后台活动。不要把一天的汇总比例与十分钟的连接测试直接比较。
电池页中的应用耗电百分比通常表示所选时段已消耗电量的分配比例，不是应用单独消耗了多少电池容量。例如，设备从 80% 降到 70%，同时某应用显示 20%，不能据此认定该应用让设备掉了 20 个百分点。VPN 网络扩展参与其他应用的通信处理，相关系统归因也不等于只有用户打开 Shadowrocket 时才产生的工作量。
以上时间与电量是测试方法示例，不是续航承诺。若所选时段同时包含视频播放、照片同步、应用更新或弱信号通勤，应先另选较稳定的时段。后台活动时间长只能说明相关任务持续存在，不能单独证明持续高功耗。
On Demand 控制连接条件，不是空闲断线计时器
进入 Shadowrocket 的 Settings → On Demand，核对当前按需连接设置。On Demand 使用系统的按需连接机制，在符合已配置网络条件、发生相应网络活动时建立或恢复连接。它不等于“每次点开应用才连接”，也不能简单理解为“没有流量就立即断开”。具体可选项目和规则呈现以当前界面为准。
本文的“手动常驻”指关闭自动按需触发后，在 Home 手动开启连接并保持开启，而不是让应用界面一直停留在前台。隧道保持连接时，是否有实际数据传输取决于业务请求、协议行为及连接维护；状态栏中的 VPN 标记不能作为瞬时功耗表。
- 自动连接：减少忘记开启的情况，但后台应用请求也可能在满足条件时触发连接。
- 手动常驻：连接状态较容易连续观察，但不会自动消除后台同步、弱信号或失败重试的成本。
- 手动断开：适合明确不需要隧道的时段；若仍启用 On Demand，符合条件后可能再次连接，应先核对按需设置。
Wi-Fi 与蜂窝网络：先选使用范围，再判断续航
Wi-Fi 并不天然代表稳定，蜂窝网络也不必然比所有 Wi-Fi 场景耗电更多。距离接入点过远、网络需要额外认证、蜂窝信号弱、频繁跨基站移动，都可能增加连接建立和重试。比较 On Demand 与常驻时，必须尽量固定网络环境，否则测到的差异可能来自无线链路。
| 使用场景 | 可选连接方式 | 必须核对的行为 |
|---|---|---|
| 固定地点，稳定 Wi-Fi | 按 Wi-Fi 条件启用 On Demand，或手动常驻 | 锁屏后业务是否可用，是否反复重建连接 |
| 蜂窝网络，偶尔使用 | 如不需要自动连接，可不配置蜂窝触发，按需手动开启 | 断开期间的请求不再由该隧道处理 |
| 蜂窝网络，持续使用 | 按蜂窝条件自动连接，或手动保持连接 | 信号稳定性、切网后的恢复与应用请求是否成功 |
| Wi-Fi 与蜂窝频繁切换 | 先用一种连接方式完成对照测试 | 切换时间是否与失败日志、发热或掉电加快重合 |
结论：按业务需要缩小自动连接范围
若只有固定 Wi-Fi 下需要自动连接，先在 Settings → On Demand 核对对应网络条件；蜂窝网络保留手动控制。若业务在两类网络都必须经隧道处理，则应保留相应连接条件，优先排查重试，不能只为降低电池页占比而关闭连接。
保持相同 Config：避免把分流变化误当作省电
On Demand 决定何时连接，Global Routing 决定连接后的流量处理姿态，两者不是同一层设置。对照测试前，在 Home 核对 Global Routing，记录当前是 Proxy、Direct、Config 还是 Scene。若使用 Scene，还要核对该场景实际应用的设置；不要在切换 On Demand 的同时更换场景。
使用 Config 时，按当前配置检查规则顺序和目标策略。DOMAIN-SUFFIX 匹配域名后缀，IP-CIDR 匹配地址网段，GEOIP 按地址地域数据库判断，FINAL 用作最终兜底。它们是分流条件，不是省电开关。Direct 也不等于关闭 VPN 隧道，把流量改成直接连接不能代替连接状态测试。
- 在 Home 记录当前选中的服务器与 Global Routing，再到 Config 确认正在使用的配置。
- 两轮测试使用相同规则顺序、相同策略目标；不要临时把 FINAL 从代理策略改成 DIRECT。
- 测试期间不批量执行延迟测试，不手动刷新已有订阅，避免额外请求混入观察窗口。
- 若已有订阅确实需要更新，先完成更新并确认服务器参数，再开始新一组对照。
Shadowsocks、VMess、VLESS、Trojan、Hysteria2 与 WireGuard 的传输和连接维护方式不同，但不能仅凭协议名称给出固定耗电排名。服务器位置、丢包、应用流量和实际参数会改变结果。第一轮排查应保留用户已有配置，不同时切换协议。
先处理失败重试：连接错误不是续航设置问题
如果出现“锁屏仍发热、业务却打不开”，先查看对应时段是否有重复连接失败。下面列出的是网络日志中可能出现的错误片段，并非每个版本都会显示完全相同的完整句子；只有实际记录出现时才按对应方向处理，不要为了排查主动制造错误。
报错：connection refused
原因与解法：目标地址或中间设备拒绝连接，常见于端口未提供对应服务；对照自己服务商提供的地址和端口，确认服务状态，再做一次连接验证，避免反复执行批量测试。
报错：i/o timeout
原因与解法：一次网络读写未在期限内完成，可能与链路不可达、丢包或远端无响应有关；先在稳定 Wi-Fi 下使用相同配置复测，再判断是否仅蜂窝网络失败，不能直接认定为 On Demand 本身耗电。
例如，已有配置指定 TLS 服务端口为 443，应以自己的服务商实际参数核对，而不是看到超时就改成其他常见端口。若只有 Wi-Fi 切到蜂窝后的首次请求失败，记录切换时间、错误片段与之后能否恢复；若在两种网络都持续失败，应先解决服务可达性，再进行续航比较。
- 检查 iPhone 或 iPad 的系统日期与时间是否准确，避免加密连接校验受影响。
- 核对协议参数与已有订阅一致，不为消除报错随意关闭证书校验。
- 向自己的服务商反馈时，保留错误时间与必要的错误片段；遮盖订阅链接、密码、token 和个人信息。
两轮对照：固定网络、屏幕与后台任务
建议先在信号稳定的 Wi-Fi 中完成基础测试，再单独测试蜂窝网络。电量读数存在取整，短时间下降一格不足以证明某种方式更省电。两轮差异很小时，应换序重复，而不是给出百分比节能结论。
- 准备：记录开始时间、电量、网络名称、信号情况、服务器和 Config。保持相近环境温度，不边充电边比较。
- A 轮：关闭 On Demand 的自动触发，在 Home 手动开启连接；确认同一测试页面可访问，然后锁屏观察 30 分钟。
- B 轮：在 Settings → On Demand 启用待测网络条件，确认连接行为符合预期；使用同一页面后，再锁屏观察 30 分钟。
- 保持一致：两轮都不播放媒体、不主动同步大文件、不运行测速；尽量保持其他应用后台活动一致。
- 记录：写下结束电量、是否发热、是否发生切网和失败重试，再查看系统“电池”对应时间段。
- 复核：另选相近条件，把 B 轮放在 A 轮之前重复一次；如果结果方向不一致，暂不归因于连接方式。
区分两个问题：上述 A/B 测试比较的是两种连接管理方式。如果还要了解“启用隧道与完全断开”的差异，需要另做一轮：先关闭 On Demand，再在 Home 断开。此轮的流量路径已经改变，不能与前两轮混为同一种业务条件。
稳妥设置组合与回退顺序
不存在适合所有设备的统一省电组合。若稳定网络中连接正常、锁屏温度正常，只是 Shadowrocket 在电池列表中的占比靠前，不必立刻更换协议或配置。优先根据业务是否需要自动连接作选择，再用重复测试确认设备的实际电量变化。
- 固定 Wi-Fi 为主：使用 Config 保持既有分流，按需要配置 Wi-Fi 的 On Demand 条件；蜂窝是否自动连接单独决定。
- 全天都需要隧道：保持相应网络的自动连接条件，或手动常驻；重点观察网络切换后的恢复和错误重试，不追求频繁断开。
- 偶尔使用：关闭不需要的自动触发条件，使用前在 Home 手动连接，结束后手动断开，同时确认业务对断开期间流量路径的要求。
- 异常掉电：先排除后台大流量和弱信号，再核对日志与参数，最后才逐项调整连接设置。每次只改一项，并保存原设置以便回退。
结论：保留能稳定完成业务的最小自动化范围
如果 On Demand 与常驻的重复测试没有稳定差异，就按是否需要自动恢复来选择；如果某种方式反复伴随失败和发热，先修复对应网络或参数问题，再重测，不把减少后台记录当作修复完成。