Shadowrocket（小火箭）的 On Demand 用于按条件自动建立 VPN 连接，不是统一降低耗电的开关。本文适合遇到锁屏掉电、断开后自动重连或网络切换时反复连接的用户：先查看 iPhone 电池记录，再设置触发条件，最后通过同条件对照区分连接维护、真实流量与失败重试的影响。连接测试以用户已有自己的服务器配置或订阅为前提。
一、先区分后台连接、流量与自动触发
退出 Shadowrocket 的前台界面，不等于系统 VPN 隧道已经停止。隧道可由系统中的网络扩展继续处理流量，因此仅凭应用不在屏幕上，不能判断它是否仍在工作。反过来，状态栏出现 VPN 标识，也不代表设备一直在高负载传输；空闲连接和持续下载的能耗不能放在一起比较。
On Demand 的作用是让系统根据配置条件决定是否自动建立连接。它不等于“只有打开某个应用时才连接”，也不保证每次锁屏都会断开。后台同步、网络变化或匹配的网络访问，都可能与连接活动同时发生，具体触发取决于当前规则与系统行为。
常驻连接可能需要维持会话，重新连接则可能涉及 DNS 查询、传输连接与加密握手。若 On Demand 使短时间内的重复连接增多，节省的空闲维护开销未必能抵消重建开销。因此应先检查“连接是否稳定”，再讨论“是否应该自动连接”。
二、在 iPhone 电池记录里建立排查基线
打开 iPhone 的“设置 → 电池”，查看系统提供的时间范围与活动明细，再选择出现异常掉电的时段。不同系统的图表和筛选入口可能不同，以设备实际显示为准。关注电量下降是否伴随屏幕使用、后台活动以及其他应用的大量网络访问，不要只看应用列表中的一个百分比。
- 记录起点。记下时间、电量、Wi-Fi 或蜂窝网络、信号情况，以及是否正在充电。测试期间避免充电和运行系统更新等高负载任务。
- 固定使用方式。锁屏测试就保持锁屏；网页测试就保持相近的浏览内容。不要拿一次视频播放和一次待机的结果比较。
- 查看所选时段。在电池图表中核对活动发生的时间，区分屏幕打开与后台活动。应用用量百分比通常反映所选时段的耗电占比，并不直接等于电池掉了多少个百分点。
- 重复观察。短时电量显示存在粒度限制。一次一两个百分点的差异不足以证明设置有效，应在相似条件下重复测试并结合连接记录判断。
结论：先对齐时间段，再判断归因
只有电池异常时段与反复连接、请求失败或持续传输的时间相互对应，才值得沿这条线继续排查。单独一个后台用量排名，不能证明 On Demand 就是耗电来源。
三、Settings → On Demand 的设置与验证步骤
修改前先在 Home 确认当前使用的服务器，并在 Config 记录当前启用的配置。这样可以避免排查过程中同时换了服务器、路由模式与自动连接条件，最终无法知道是哪项变化影响了结果。订阅内容或连接参数如有疑问，应向自己的服务商核对。
- 进入设置。打开 Shadowrocket，进入
Settings → On Demand，检查当前是否启用以及已有条件。记录原状态，方便恢复。 - 先做关闭对照。暂时关闭 On Demand，再回到 Home 手动断开连接。在不需要通过隧道访问网络的测试时段，观察是否仍然出现自动连接。
- 明确目标网络。若希望按网络环境自动连接，再启用 On Demand，并按页面实际提供的网络类型或网络匹配条件配置。若当前界面提供 SSID 条件，填写设备实际连接的 Wi-Fi 名称，注意空格和大小写。
- 从单一条件开始。先验证一条条件，不要一次加入多条可能重叠的匹配。不要把“未填写限制”直接理解成“不触发”，应根据界面说明和实际连接结果确认。
- 测试进入与离开。分别测试进入目标网络、离开目标网络、锁屏后恢复使用。每次检查 Home 的连接状态；若使用 iPhone 的“设置 → 通用 → VPN 与设备管理 → VPN”查看系统配置，注意不要误改其他用途的配置。
- 确认退出方法。需要保持断开时，先关闭 On Demand，再在 Home 断开。只操作 Home 的连接开关，可能在下一次满足条件时再次连接。
四、按使用场景选择常驻、按需或手动连接
配置目标应是减少不必要的连接变化，同时满足实际访问需求。对每天长时间需要隧道的用户，稳定保持连接可能比不断重建更合适；对偶尔使用的用户，手动连接往往更容易控制。On Demand 适合触发条件明确的情形，而不是用来替代对连接用途的判断。
| 使用场景 | 可测试的设置 | 优先观察 |
|---|---|---|
| 一天中持续访问需要隧道的资源 | 保持稳定连接，与当前 On Demand 设置做对照 | 是否有持续流量、失败重试或频繁重建 |
| 每天仅短时使用 | 关闭 On Demand，需要时在 Home 手动连接 | 用完断开后是否保持断开 |
| 只在特定网络环境使用 | 使用 On Demand 中实际支持的网络条件 | 进入、离开该环境时是否符合预期 |
| 经常在 Wi-Fi 与蜂窝网络间切换 | 先减少条件重叠，保持服务器不变 | 网络切换时间与连接失败是否重合 |
弱信号、门户认证尚未完成的 Wi-Fi、网络切换都可能导致连接建立失败。比如刚连接公共 Wi-Fi 时，应先完成网络要求的认证，再验证隧道，不要靠持续切换开关解决底层网络尚不可用的问题。蜂窝信号较弱时的耗电也可能来自无线通信本身，并非单纯来自 Shadowrocket。
五、反复连接时，先读错误再改参数
如果连接记录里重复出现失败，先记下错误时间、所用网络与目标服务器，再与电池图表对照。下面列出网络诊断中常见的英文错误；实际大小写、前缀和附带信息可能不同，应保留设备上的完整原文。它们是定位方向，不是仅凭一条记录就能下结论的依据。
报错：Connection refused
原因：通常表示目标地址的端口拒绝连接，可能是服务未监听、端口填写不符或网络设备主动拒绝。
解法：按已有配置核对服务器地址、端口和协议，再向自己的服务商确认服务状态；不要为了消除报错随意把端口改为 443。
报错：Operation timed out
原因：操作在限定时间内未完成，可能涉及网络不可达、丢包、目标无响应或连接路径受限。
解法：保持配置不变，换到另一种自己可用的网络复测；若只在某个网络失败，先检查该网络，再检查服务器。
报错：Network is unreachable
原因：当前连接路径不可用，常见于网络接口切换或底层网络尚未恢复的时段。
解法：先确认设备基础联网正常，等待网络稳定后重试，并检查 On Demand 是否在网络切换期间反复触发。
一次失败后的恢复不一定异常；需要关注的是失败与重连是否密集重复，并且在没有有效传输时仍持续发生。不要同时修改 DNS、服务器、协议与 On Demand，否则即使现象消失，也无法确定真正原因。涉及身份凭据或订阅链接的记录，分享前应遮去敏感信息。
六、Global Routing 与规则能改变流量路径，不能替代断开
在 Home 查看 Global Routing 时，要区分路由策略与隧道开关。选择 Direct 是改变请求的出站方式，不等于关闭系统 VPN；选择 Config 则按当前配置处理请求。On Demand 解决的是自动连接条件，两者属于不同层面，不能用“已经选 Direct”来证明后台隧道停止。
如果目标是只让明确的网站走代理，可以在备份后检查 Config 中的规则与顺序。下面仅说明语法，example.com 是演示域名，PROXY 必须在实际配置中有可用的策略含义。示例不是通用节电配置，也不应直接覆盖正在使用的完整配置。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECTDOMAIN-SUFFIX匹配指定域名及其子域名；更具体的匹配应放在兜底规则之前。FINAL,DIRECT为未被前面规则命中的请求指定 DIRECT；它不负责关闭隧道。- 规则精简后仍需检查实际请求是否命中预期策略。必要的代理流量、DNS 查询和失败重试不会因为存在一条 FINAL 规则就自动消失。
同样，不应为了省电盲目替换 Shadowsocks、VMess、VLESS、Trojan、Hysteria2 或 WireGuard。协议、传输方式、服务器质量与当前网络都会影响结果，已有服务端必须支持相应配置。仅凭协议名称，无法预测一部 iPhone 在具体网络下的耗电。
七、用可复现的对照结果完成排查
建议把排查收束成三轮：完全断开、手动稳定连接、启用明确条件的 On Demand。每轮采用相似时长和使用内容，并保持同一网络、服务器与路由配置。这里的轮次是测试方案，不是要求日常使用时不断切换连接。
- 完全断开轮。关闭 On Demand 并断开，记录设备在该场景的基础耗电。若此时仍有明显异常，继续检查屏幕活动、其他应用、信号与系统任务。
- 稳定连接轮。保持 On Demand 关闭，手动建立连接。观察相同流量下是否出现异常发热、反复错误或大量后台请求。
- 自动连接轮。启用已验证的单一条件，检查连接次数是否明显增多，以及这些变化是否与电量下降集中时段重合。
- 保留记录。保存各轮起止电量、起止时间、连接状态与错误原文。若需进一步排查，这组信息比“后台很耗电”的描述更有用。
结论：只保留符合实际使用需求的自动条件
若自动连接轮频繁重建，而手动稳定连接轮正常，先修正 On Demand 条件；若两种连接轮都异常，优先检查网络、服务器和持续请求。不要把每次耗电变化都归因于同一个开关。
最终设置应同时满足可用性与可验证性：需要连接时能建立，不需要连接时能保持断开，网络切换后不会持续失败。完成这一轮后，再决定保留常驻连接、按需连接还是手动连接，而不是仅凭一次电池百分比选择。