Shadowrocket（小火箭）的 On Demand 决定何时自动建立连接，不是自动省电开关。后台耗电排查应先区分持续传输、反复重连与正常待机，再选择网络条件。本文适合已经使用自己已有连接信息的 iPhone、iPad 用户：先记录基线，再设置 Wi‑Fi 或蜂窝网络条件，最后用同等时长的对照测试确认取舍。
先判断：后台活动不等于异常耗电
系统「设置」→「电池」中的应用用量占比，是所选时间范围内的相对耗电分配，不是这款应用直接消耗了多少电池百分点。其他应用使用减少时，Shadowrocket 的占比可能升高，即使设备的总耗电没有增加。先看整机电量曲线、屏幕活动和对应时段，再判断是否需要调整。
连接建立后，网络扩展可以在主界面不显示时继续处理请求。后台同步、消息刷新、照片传输以及连接维护都可能产生工作量。把应用从最近使用列表划走，也不能作为隧道已停止的证据；需要核对 Home 的连接状态与系统 VPN 状态。
如果电量下降主要出现在蜂窝信号弱、网络频繁切换或大量上传期间，应先处理这些条件。信号质量和实际传输量可能比连接开关的姿态更影响结果。不要仅凭一次占比截图，就把全部耗电归因于 On Demand。
理解区别：连接时机与流量去向分开设置
On Demand 使用系统按需连接机制，根据配置的条件决定是否发起连接。条件持续满足时，连接可以一直存在；它不保证每个请求结束后马上断开，也不意味着锁屏后自动停止。若规则相当于“当前网络始终连接”，实际效果就可能接近持续连接。
Global Routing 处理的是连接内的流量去向：Proxy 让受接管流量使用代理，Direct 使用直连，Config 根据当前配置中的规则处理，Scene 则用于按场景选择相应策略。Direct 不是关闭 VPN；选择 Config 也不是启用 On Demand。两处设置不能相互替代。
手动基线
推荐排查阶段先关闭 On Demand，以 Home 开关控制连接。保持原有 Global Routing 和配置不变，观察同一网络下的待机表现，减少自动重连对判断的干扰。
适合：首次定位耗电、验证连接是否反复恢复
持续连接
在需要的时段保持连接，减少临时发起连接的等待。代价是连接维护与后台请求仍可能发生；实际耗电取决于传输量、协议行为和网络稳定性。
适合：连续工作、依赖连接的后台任务
按条件连接
通过 On Demand 限定自动连接的网络条件。条件收窄可能减少不必要的连接时段，但频繁切换网络也可能增加重连，必须实机验证。
适合：网络使用规律明确、能够维护条件规则
操作步骤：先建立可恢复的测试基线
本节不要求更换服务器或协议，也不要求重置所有设置。先记录现状，一轮只改一个变量；否则即使电量表现改善，也无法确定是哪项调整起了作用。On Demand 内的可用条件与编辑项以当前界面为准，不要把配置文件中的分流规则当成这里的开关。
-
记录现状
在 Home 记录所选服务器与 Global Routing；在 Config 记录当前使用的配置。保留原设置记录，暂时不更新配置、不更换协议。
-
关闭按需
进入 Settings → On Demand，关闭按需连接，再回到 Home 手动关闭连接。等待片刻核对连接是否保持关闭，排除已有系统自动连接设置仍在生效的情况。
-
测量基线
选定稳定 Wi‑Fi，暂停大文件传输，记录起始电量、时间与信号情况。先测手动连接状态下的待机，再在可接受任务中断的时段测断开状态。
-
加入条件
返回 Settings → On Demand，按当前编辑器提供的网络条件设置自动连接。先测试一种网络，不同时叠加多个 Wi‑Fi 例外与域名条件。
-
验证切换
分别测试锁屏后唤醒、Wi‑Fi 切换蜂窝网络、回到原 Wi‑Fi。每次查看 Home 状态，并用同一业务请求验证可用性；异常时先恢复刚记录的基线。
条件取舍：Wi‑Fi、蜂窝网络与域名
Wi‑Fi：按实际任务决定是否连接
若某个 Wi‑Fi 环境下的任务不依赖连接，可以在当前界面支持的条件中将该网络排除出自动连接范围。若后台任务仍需要访问相同资源，就应保留连接或改为手动控制。Wi‑Fi 名称只用于条件匹配，不能单独证明网络可信，也不能保证业务一定可直连。
蜂窝网络：先观察信号和切换次数
移动途中，信号变化、网络切换以及连接恢复可能同时出现。可以选择仅在确有需要时手动连接，也可以保留蜂窝网络下的自动连接，以满足后台业务。二者的取舍是连接可用性与维护开销，不是固定的省电排序；不要在测试中同时修改系统蜂窝数据策略。
域名：区分触发连接与分流匹配
系统按需机制可涉及域名解析条件，但能否在 Shadowrocket 中直接编辑相关条件，应以 Settings → On Demand 的实际选项为准。解析条件不是“打开某个 App 就连接”，已有 DNS 缓存、已经建立的连接以及直接访问 IP 的请求，都可能让结果不同于预期。若当前界面没有域名条件编辑入口，不要用 Config 规则代替。
- 触发连接：由 On Demand 的条件和系统评估决定，关注“什么时候建立连接”。
- 规则分流：在 Global Routing 选择 Config 后，由配置规则决定受接管请求的处理方式。
- 语法示例：
DOMAIN-SUFFIX,example.com,PROXY表示该域名后缀使用 PROXY；它不会单独启用系统按需连接。 - 兜底规则：
FINAL,DIRECT是前面的规则未匹配时使用的处理方式；它不是“空闲后断开”的指令。
使用域名条件前，先确认需要的是自动建连还是域名分流。如果目的只是减少代理路径上的请求，应检查 Config 中的规则命中；如果目的是在某些网络不建立连接，才应调整 On Demand。把两层问题混在一起，容易得到“规则已经改了，VPN 却还在”的误判。
对照记录：不要把试验方案写成省电结论
下面是可执行的记录方案，不是预先测得的耗电数据。每组建议持续 60 分钟，条件允许时重复两轮。电量显示有取整误差，温度、信号和后台任务也会变化；一组只相差一个百分点时，不足以判断某种设置稳定更省电。
| 测试组 | 保持条件 | 记录内容 |
|---|---|---|
| 手动连接待机 | On Demand 关闭；固定 Wi‑Fi；Home 连接开启 | 起止电量、屏幕活动、是否持续传输 |
| 手动断开待机 | On Demand 关闭；相同 Wi‑Fi；Home 连接关闭 | 起止电量、任务是否中断、是否自动恢复连接 |
| 按需连接待机 | 启用单一网络条件；其余配置与首组相同 | 起止电量、连接状态变化、请求是否需要等待 |
| 网络切换验证 | 保持同一业务请求；Wi‑Fi 与蜂窝网络往返一次 | 切换时间、连接能否恢复、有无连续失败 |
若“手动连接待机”稳定，而“按需连接待机”反复恢复连接，应先检查条件是否冲突、网络是否频繁变化。若两组都在持续传输，应先定位后台任务。若只有蜂窝网络明显增加耗电，先在稳定信号位置复测，再考虑其他设置，避免把无线网络开销误算成协议问题。
常见问题：锁屏、通知与后台设置
锁屏后还显示 VPN，设置没生效吗？
不一定。On Demand 的条件可能在锁屏后仍满足。先到 Settings → On Demand 检查条件，再对照 Home 的连接状态。VPN 标识只能辅助判断连接状态，不能显示实时耗电；需要完全断开测试时，先停用 On Demand。
关闭后台 App 刷新就能停连接吗？
系统的后台 App 刷新和 VPN 网络扩展不是同一机制，不能用前者代替断开操作。保留其他设置不变，先关闭 On Demand，再在 Home 断开，观察系统 VPN 状态是否同步变化。
按需连接后通知变慢，怎么查？
先恢复原先可正常接收通知的连接状态，确认现象能否消失。再分别测试 Wi‑Fi 与蜂窝网络，记录通知延迟是否只发生在自动连接尚未建立时；同时核对系统通知权限、专注模式及目标应用自己的后台条件。
换成 Direct 会更省电吗？
Direct 改变受接管流量的处理路径，不等于停止网络扩展。要测试断开后的待机表现，应先关闭 On Demand，再关闭 Home 连接。不要用 Global Routing 的 Direct 组代替断开组。
设置完需要每天重新测试吗？
不需要。保留两轮条件接近的记录后，日常观察连接是否稳定即可。更换网络环境、修改 On Demand 条件或出现持续异常耗电时，再按同一流程复测；每轮只调整一个变量。
最终应保留能满足实际任务、切换后表现可预期的设置，而不是追求后台记录归零。Shadowrocket 是闭源商业应用，主要用于 iPhone、iPad，唯一获取入口为 App Store；系统要求与购买适用范围以 App Store 页面标注为准。客户端购买与用户已有的连接服务是两件事，本文只讨论本地设置和验证方法。