Shadowrocket 后台耗电排查:On Demand 按需连接开还是不开

先分清 On Demand、隧道与实际流量

Shadowrocket（小火箭）的主界面退到后台后，系统 VPN 隧道仍可继续处理请求。返回 Home 屏幕、锁屏，或从多任务界面移走应用，都不能直接证明隧道已经停止。判断是否还在连接，应回到 Shadowrocket 的 Home 查看状态，并结合系统设置中的 VPN 状态核对。

On Demand 负责连接触发，Global Routing 负责流量如何处理。启用 On Demand 后，系统可在符合当前按需规则的情况下尝试建立连接；它不是“检测到流量就只运行一瞬间”的定时机制，也不保证空闲时一定断开。连接是否持续、是否再次建立，需要结合实际规则与网络环境判断。

电量消耗可能来自隧道内的数据处理、加密传输、DNS 查询、失败重试，也可能来自发起请求的后台应用及无线网络本身。即使没有打开网页，照片同步、邮件收取或其他应用的后台活动仍可能产生网络请求。因此，系统把部分活动显示在 Shadowrocket 名下，并不能单独证明问题出在 On Demand。

常驻自动连接与手动连接，按使用场景选择

这里的“常驻”指用户希望隧道保持可用、断开后能够按条件恢复的使用方式，不是 On Demand 中一个独立的省电档位。关闭 On Demand 只是取消相应的自动连接行为，已经建立的隧道不应被当作必然同时断开；需要停止连接时，还要在 Home 主动断开并确认状态。

自动连接不必然比手动连接更耗电。如果两种方式最终都维持同一条隧道、处理相同请求，单看开关不能推导电量差异。真正值得比较的是连接总时长、自动重连次数，以及是否把原本无需连接的空闲时段也纳入了处理范围。

从系统电池页面建立可比较的记录

在 iPhone 或 iPad 打开系统“设置 → 电池”，查看页面当前提供的时间范围、电量曲线和应用活动记录。系统版本不同，时间范围及展开项的名称可能有所变化，以设备实际显示为准。点选同一个时间段，再比较 Shadowrocket 与其他应用的活动，避免把全天数据与短时测试混在一起。

1. 记录起止条件。写下开始时间、电量、是否充电、使用 Wi-Fi 还是蜂窝网络，以及信号是否稳定。开启热点、导航、视频通话等明显改变负载的任务也要记录。
2. 查看电量与活动的对应关系。观察电量下降是否集中在屏幕使用期，还是在锁屏期间持续发生。若系统提供后台活动时长，一并记录，但不要把它直接解释为处理器始终满载。
3. 核对连接状态。在测试开始和结束时查看 Home，记录隧道是否连接。若中途切换网络或手动断开，记下时间，方便与系统电池曲线对照。
4. 重复同类场景。例如分别安排两个 60 分钟的观察窗口，保持同一网络、近似屏幕使用量和相同配置，只改变 On Demand 或连接方式。这里的 60 分钟是记录方案，不是产品续航指标。

电池页面中的应用百分比是所选时间范围内的耗电占比，不能直接读成“这款应用消耗了整块电池的相同比例”。其他应用活动减少时，Shadowrocket 的占比可能上升，但设备实际掉电未必增多。应同时看电量曲线、绝对掉电和活动时段；小幅差异需要重复观察，不能用单次记录下结论。

按顺序调整 Settings → On Demand

进入 Shadowrocket 的 Settings → On Demand，先核对当前是否启用，再查看页面实际提供的规则或网络匹配条件。不同应用界面与系统环境下，可见选项可能不同；不要为了照搬教程去寻找不存在的开关，也不要把某个 Wi-Fi 名称当作通用示例直接填入。

1. 先做手动基线。关闭 On Demand，返回 Home 主动断开。确认状态不再连接后，在无需连接的时段观察是否仍有同等程度的掉电。
2. 再测手动连接。保持 On Demand 关闭，在 Home 手动连接原有配置，进行与平时相同的任务。如果此时耗电也明显上升，应继续检查请求负载和网络，而不是只归因于自动连接。
3. 恢复自动触发。确有自动恢复需求时重新启用 On Demand；若页面提供 Wi-Fi、蜂窝网络或网络匹配条件，只保留实际需要的范围。修改后分别在对应网络下验证。
4. 验证断开与恢复。在可控条件下切换一次网络，观察 Home 是否按预期恢复。测试完成后不要持续反复切换网络，这种操作本身会增加连接建立次数。

“断开后立即又连接”首先是触发行为线索，不是耗电结论。若 On Demand 仍开启，且当前网络继续满足条件，系统可能再次建立连接。要观察真正未连接的状态，应先关闭按需连接，再主动断开；只反复点击 Home 的连接开关，可能一直在制造重复连接过程。

后台持续活动时，检查请求和失败重试

若相同任务下，手动连接与自动连接都出现较多后台活动，接下来应看“隧道里正在处理什么”。在应用当前提供的请求记录或日志页面中，按观察窗口核对时间、目标与失败信息。先记录少量相关条目，不需要长期打开高详细度日志；日志本身也会增加记录和存储工作。

• 固定间隔访问同一目标：检查是否有应用同步、状态检查或失败重试。短时间大量重复请求值得追踪，但不能仅凭请求次数判断电量消耗大小。
• 网络切换后连续失败：对照 Wi-Fi 信号、蜂窝信号及失败发生时间。网络不稳定可能导致重新握手和重传，先在稳定网络复测。
• Connectivity Test 被反复运行：测试会主动产生探测请求，适合检查可达性，不适合在续航观察期间持续触发。完成一次必要检查后停止重复操作。
• 用户已有订阅被更新：把更新操作与观察窗口分开。更新配置、重新选择连接和重新测试叠在一起，会让日志难以区分正常维护与异常重试。

上面的报错卡仅用于日志实际出现对应原文时的辨认，不表示所有失败都会使用同一句文案。如果 Home 显示 Not Connected，它首先是连接状态，不等于已经给出了失败原因；需要结合连接尝试的时间与日志判断，不能把状态文字当作具体报错。

区分路由姿态与协议，再决定最终设置

Home 中的 Global Routing 与 On Demand 是两类设置。Global Routing 下的 Proxy、Direct、Config、Scene应按应用内说明及当前配置核对；其中 Direct 不是关闭系统 VPN 隧道的同义词。排查耗电时，若想比较“连接”和“未连接”，应真正断开，而不是只改成 Direct。

使用 Config 时，应在 Config 中检查当前启用文件的 Rule。DOMAIN-SUFFIX、GEOIP、IP-CIDR 等规则按配置顺序参与匹配，末尾 FINAL 为前面未匹配的请求指定策略。流量被送往哪个策略，可能影响连接路径，但规则条目数量本身不足以推导续航。

• 先确认实际路径：核对当前 Global Routing、启用的 Config 和命中的策略，避免以为在测试按需连接，实际却同时改变了流量出口。
• 协议保持不变：Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 的连接特性不同，但不能脱离网络质量、参数和工作负载给出固定省电排名。
• 保留有效设置：如果只有自动触发覆盖过广造成不必要的连接时长，就调整触发范围；如果两种连接方式都出现相似问题，就继续排查请求来源、网络质量及连接失败。
• 恢复后复查：下一次正常使用时再次查看电池曲线与 Home 状态，确认减少了不需要的连接，同时没有破坏原本需要的自动恢复行为。