Shadowrocket（小火箭）的 On Demand 是按条件触发 VPN 连接的机制，不是省电开关。排查应先对齐 iOS 电池统计时段，再区分持续流量、网络切换和连接重试。本文适合已经持有自己的服务商与订阅、希望定位后台耗电的用户，给出开关取舍与单变量验证步骤，不预设某一种设置一定更省电。
一、先看 iOS 电池用量，不用占比直接判断耗电
在 iPhone 或 iPad 的系统设置中打开“电池”，选择问题发生的日期与时段，再查看应用耗电、屏幕活动及后台活动信息。统计入口与显示名称可能随系统变化；应以设备实际界面为准。先记下开始电量、结束电量、是否充电，以及当时连接的是 Wi-Fi 还是蜂窝网络。
电池列表中的百分比通常表示所选时段内的耗电份额，并不等于设备损失了相同比例的电量。例如设备在该时段总共下降 10 个百分点，某应用显示占比 20%，不能理解为该应用让整机下降了 20 个百分点。后台活动时间也不等于处理器一直满负荷工作。
- 对齐时段：选择出现异常掉电的小时，避免拿整天统计解释十几分钟的网络故障。
- 核对实际任务：记录照片同步、文件传输、视频播放等活动。流量经 VPN 网络扩展处理时，不能只凭一个应用的统计份额确定最初发起请求的应用。
- 排除明显干扰：记录弱信号、设备发热、充电和系统后台任务；这些因素会影响整机耗电。
- 保留基线：修改前记录 Home 的连接状态、Global Routing 当前选项及 Settings → On Demand 的设置。
二、On Demand 的触发条件与后台行为
进入 Shadowrocket 的 Settings → On Demand，检查总开关以及当前界面提供的网络条件。On Demand 将按需连接规则交给系统；在网络条件、规则动作与系统连接判断满足时，系统可以发起 VPN 连接。开启它不等于只要熄屏就断开，也不等于每个网络请求都重新建立一次隧道。
从 Wi-Fi 切换到蜂窝、重新接入无线网络，可能让系统重新评估规则；是否连接仍取决于实际配置与网络状态。已经建立的连接也可能在网络切换中恢复或重建，不能把所有恢复动作都归因于 On Demand。服务器不可达、认证错误和底层网络不稳定，应单独排查。
- 开启时：符合规则的条件下可以自动发起连接，减少手动操作；如果连接目标持续失败，反复尝试可能带来额外活动。
- 关闭时：停止使用这套按需触发机制，但不代表当前 VPN 会立即断开，也不会自动禁止其他应用产生后台请求。
- 需要暂停连接时：先关闭 On Demand，再回到 Home 关闭连接开关，并确认系统中的实际 VPN 状态。只关闭 Home 开关，可能仍被符合条件的按需规则重新触发。
不建议把从后台划掉 Shadowrocket 当作日常断开步骤。应用界面与系统管理的 VPN 网络扩展不是同一个生命周期，关闭界面不能替代检查连接开关和按需规则。
三、Wi-Fi 与蜂窝分别怎样取舍
选择依据是使用需求和网络稳定性，而不是“Wi-Fi 必开、蜂窝必关”。固定 Wi-Fi 下的长时间低流量连接，与通勤途中频繁切换基站、不断重试的连接，不具备相同的耗电条件。先让连接稳定，再判断自动触发是否值得保留。
| 场景 | 建议起点 | 验证重点 |
|---|---|---|
| 固定且稳定的 Wi-Fi | 有持续连接需求时保留 On Demand | 锁屏期间是否有大量同步流量，是否重复出现连接错误 |
| 蜂窝信号较弱 | 暂时关闭自动触发，按需手动连接作对照 | 先判断掉电是否与弱信号及连接重试同时出现 |
| Wi-Fi 与蜂窝频繁切换 | 先用单一稳定网络验证，再恢复切换场景 | 错误是否集中在切换时间，而非静止连接期间 |
| 仅短时使用连接 | 可关闭 On Demand，由 Home 手动管理 | 用完后确认连接已断开，后续任务是否仍需连接 |
| 需先认证的公共 Wi-Fi | 先完成网络登录，再测试 VPN | 底层网络能否正常访问，认证是否尚未完成 |
结论：先在稳定网络验证，再决定是否保留自动触发
如果固定 Wi-Fi 下连接稳定，而切换网络时才出现掉电和错误，应优先检查切换过程与可达性；不要同时修改协议、规则和 On Demand，否则无法识别改善来自哪一项。
如果实际界面提供针对网络类型或 SSID 的条件，可按需要逐项设置并测试；不要假设所有系统和界面都提供同一套选项。关闭某个网络条件，只改变对应的触发逻辑，不代表该网络上的所有请求都会自动改为 DIRECT。
四、出现连接错误时，先止住重复失败
在问题发生时检查连接记录中的时间、目标与错误内容。下面列出的是网络日志中可能出现的标准错误短语，并非保证每次都会显示的固定弹窗；具体文字可能附带系统或协议上下文。一次错误不能证明耗电异常，只有错误密集重复且时间与掉电吻合，才值得进一步关联。
报错：Connection refused
原因与解法：目标端口可能未监听，或连接被明确拒绝——核对用户已有服务器的地址与端口，并向自己的服务商确认服务状态，不用连续切换 Home 开关替代检查。
报错：Operation timed out
原因与解法：连接或读写未在规定时间内完成，可能涉及链路不可达、丢包或目标无响应——先在稳定 Wi-Fi 下复测同一服务器，再与蜂窝结果对照，避免仅凭超时认定认证信息有误。
- 记录错误发生时间，检查是否紧邻 Wi-Fi 断开或蜂窝切换。
- 核对 Home 中选中的服务器，使用 Connectivity Test 检查当时可达性；单次成功不能证明后台一直稳定。
- 若同一错误持续重复，临时关闭 On Demand 并断开连接，待网络或服务器问题解决后再测试。
- 确有地址、端口或认证信息变更时，再更新用户自己的订阅；更新后重新核对所选服务器，不将反复更新订阅当作通用省电操作。
协议也会影响排查方向。例如 Hysteria2 基于 QUIC，使用 UDP；如果当前网络限制 UDP，应先核对协议可达性。不能仅因为另一个协议使用 TCP，便推断它在所有设备和网络中都更省电。服务器端口以用户已有配置为准，不要随意改成 443 来尝试解决连接问题。
五、Global Routing 与 On Demand 分别控制什么
On Demand 负责按条件触发连接，Global Routing 决定连接中如何选择流量处理路径，两者不是同一个开关。Home → Global Routing 下的 Proxy、Direct、Config、Scene 应按当前用途选择；其中 Scene 的实际效果取决于对应场景配置，不能直接视为一种固定省电模式。
- Proxy：采用代理路由姿态，不表示会自动减少请求次数。
- Direct：采用直接连接姿态，但切到 Direct 不等于关闭 VPN 网络扩展。
- Config：依据当前配置分流，需检查 Config 中实际启用的配置，而不是只查看订阅中的服务器。
- Scene：先核对场景内容及其生效条件，再判断流量路径，避免测试期间自动切换引入变量。
使用 Config 时，DOMAIN-SUFFIX 按域名后缀匹配，IP-CIDR 按地址网段匹配，GEOIP 按地址地理数据库匹配，FINAL 承接前面未匹配的请求。DIRECT、PROXY 和 REJECT 是策略结果，不是电池档位。规则顺序会影响结果，不应为了降低电池列表占比而随意更改业务所需规则。
六、用单变量对照确认是否真的改善
以下是一套建议的记录方案，不是实测续航成绩。先在同一地点、同一网络和相近电量下做两组观察，保持所选服务器、Global Routing、屏幕状态和后台任务一致，只改变 On Demand。每组开始前都在 Home 建立同样的连接状态，以免把“是否连接”的差异误算成“是否按需触发”的差异。
- 第一组：开启 On Demand，连接后锁屏，记录起止电量、网络变化和错误时间。
- 第二组：关闭 On Demand，保持手动连接，按相同条件观察；若连接中途断开，应记录并说明两组状态已不再一致。
- 补充使用场景：若真正要比较“持续自动连接”与“用完手动断开”，另做一轮测试，并明确这次同时改变了连接持续时间。
- 复查：对照系统电池页和连接记录；短时差异只有一两个电量百分点时，应延长观察并重复测试，不直接下结论。
结论：保留可解释、可复现的设置
需要持续连接且网络稳定时，可保留 On Demand；只在固定时段使用时，可采用手动连接。若关闭后仍同样掉电，下一步应查持续传输、弱信号和连接错误，而不是继续围绕按需开关反复切换。
问题消失后，逐项恢复日常设置，每恢复一项都确认实际连接状态。向自己的服务商反馈时，可提供发生时间、网络类型和去除敏感信息的错误内容；不要公开订阅地址、认证信息或完整连接凭据。更多连接与规则操作可在本站教程和规则手册中核对。