本文速览

Shadowrocket(小火箭)的 On Demand 用于按条件触发 VPN 连接,不是省电开关。本文面向已经有自己的服务商与订阅、希望判断后台耗电来源的 iPhone 与 iPad 用户:先区分自动触发和连接中的流量处理,再读取系统电池记录,最后以同一网络、同一配置做开关对照,决定保留自动连接还是改为手动连接。

On Demand 与后台连接不是同一件事

先给结论:不能仅凭 On Demand 已开启,就认定它是耗电原因;也不能仅凭关闭它,就认定 VPN 已断开。On Demand 决定系统何时按已有条件发起连接,VPN 建立后仍需处理符合路由设置的网络请求。实际耗电还受请求数量、网络信号、连接重试、服务器响应以及屏幕使用情况影响。

在 Shadowrocket 中进入 Settings → On Demand,先核对当前是否启用以及已有条件。系统根据适用的按需连接条件判断是否建立连接;条件可能涉及当前网络环境与网络访问。它不等于“只有打开某个网页才运行”,也不保证锁屏后立即停止。具体可设置项目以应用内实际显示为准,不要照搬与当前界面不一致的开关名称。

网络条件变化 按需条件判断 建立系统隧道 路由策略处理 请求完成或重试

这条流程区分了两个阶段:前半段是连接触发,后半段是已连接状态下的工作。即使 Shadowrocket 的前台页面已关闭,系统 VPN 隧道仍可能保持连接;反过来,前台页面没有停留很久,也不代表后台一定没有处理流量。退出前台页面不是可靠的断开或省电验证方法。

先从 iPhone 电池页面读取三个信息

打开系统“设置 → 电池”,选择页面提供的时间范围,再查看应用列表。不同系统的图表和时间范围名称可能不同,操作以设备实际界面为准。不要只截取一个应用的百分比:这个数字通常表示所选范围内的耗电占比,并不是该应用单独让电池下降了多少个百分点。

  1. 确认统计时段。选择能够覆盖问题发生时间的范围;如果图表支持选中小时或日期,就缩小到出现异常下降的那一段。记录是否充电、是否长时间亮屏,以及当时使用的是 Wi-Fi 还是蜂窝网络。
  2. 查看活动说明。点开 Shadowrocket 的条目,或使用页面的活动显示方式,核对是否有后台活动。系统对网络扩展的耗电归属有其统计口径,不能把列表中的单一条目当成整条网络链路的独立功耗测量。
  3. 核对同期其它应用。如果视频播放、照片同步、系统更新或大文件传输与电量下降同时发生,应把它们纳入判断。请求由其它应用发起,也可能经过 VPN;“后台活动较长”与“异常耗电”不是同义词。

举例说,某个时段 Shadowrocket 显示的占比比昨天高,可能是其它应用今天使用得更少,而不是 Shadowrocket 的绝对能耗增加。应同时看该时段整机电量曲线、活动情况和使用任务。下面的数字是建议的观察设计,不是产品性能或实测续航结论。

2 轮
分别观察 On Demand 开启与关闭,保持其余条件一致
30 分钟
每轮建议的初步观察时长;差异不明显时延长观察
3 项
共同记录电量变化、后台活动与连接重试现象

结论:用同一时间窗判断,不按占比排名直接关设置

先选中电量明显下降的时段,再核对网络任务与重连记录;如果只有占比升高、整机掉电并未加快,暂时没有必要为这个数字改变连接方式。

按固定步骤做开关对照

对照测试需要先确定问题:是“自动连接是否频繁触发”,还是“连接着是否比断开更耗电”。两者不能混在一次测试里。若两轮都手动保持相同 VPN 连接,On Demand 的开关差异主要体现在自动触发行为,不应期待它改变同一批流量的处理成本。

  1. 记录原状。在 Home 记录当前连接与 Global Routing 选择,在 Config 确认当前配置,再到 Settings → On Demand 记录原有状态。记录即可,不要在排查耗电时顺便修改规则、协议和订阅。
  2. 固定环境。两轮使用同一处 Wi-Fi、相近的屏幕亮度与相同任务,保持低电量模式状态一致。不要一轮在弱蜂窝信号下测试,另一轮改用稳定 Wi-Fi 后就把差异归因于 On Demand。
  3. 观察开启状态。维持现有按需条件,记录开始与结束电量、VPN 是否自行建立、是否出现多次断开重连,以及锁屏期间是否有实际同步任务。
  4. 观察关闭状态。关闭 On Demand。若测试目标是自动重连,先在 Home 断开,再观察是否仍有连接行为;若目标是连接中的处理开销,就手动连接,并保持与上一轮相同的任务。
  5. 复核与恢复。将结果与系统电池页面对照;差异很小、统计窗口不匹配或环境变化明显时,应重复观察。完成后恢复所需设置,不要为了测试长期中断必要连接。

Global Routing 影响流量路径,不代替连接开关

Global Routing 和 On Demand 负责不同层面。前者决定请求的路由方式,后者负责按条件触发连接。把 Global Routing 改为 Direct,不等于系统 VPN 隧道已经退出;把它改为 Config,也不意味着没有匹配代理策略的请求会产生。

界面项核对重点排查时的边界
Proxy采用代理路由方式,确认当前选中的出站可用。不能仅凭该选择推断耗电大小;仍需核对流量与连接质量。
Direct采用直接连接方式。不是 VPN 断开按钮,不适合作为“隧道已停止”的判断依据。
Config按照当前配置中的规则和策略处理请求。保持同一配置对照,避免同时改变规则导致流量路径不同。
Scene核对已有场景设置及其实际应用结果。场景设置可能改变对照条件,应记录实际生效的路由行为。

使用 Config 时,DOMAIN-SUFFIX、IP-CIDR、GEOIP 与 FINAL 等规则会影响请求匹配结果,但不应把“修改更多规则”当作通用省电步骤。先确认具体请求命中的策略是否符合预期,再判断是否存在重复访问或失败重试;没有证据时,保留现有配置更便于对照。

反复重连时,先处理网络错误

弱信号、网络切换、服务器不可达和参数不匹配,都可能让连接尝试反复发生。若关闭 On Demand 后重连现象减少,只能说明自动触发参与了这个过程,不能据此排除底层连接故障。应先在稳定网络下测试用户已有的连接,并核对地址、端口与协议参数,不要先靠更换协议来掩盖错误。

以下是网络日志可能出现的错误片段,不是每次故障都会出现的固定提示。只有实际记录包含相应原文时才按该方向检查;不同连接阶段可能产生相同片段,仍需结合前后日志判断。

报错:i/o timeout

原因与解法:某次网络读写未在规定时间内完成,可能涉及当前网络、解析或远端响应。先换到稳定网络复测,再核对自己的服务商提供的地址与端口,确认错误出现于连接建立还是传输阶段。

报错:connection refused

原因与解法:连接尝试被拒绝,常见检查方向是目标端口没有对应服务或访问被明确拒绝。逐字核对地址、端口和服务状态,向自己的服务商确认后再测试;反复切换 On Demand 不能修复远端监听问题。

按使用场景决定开与不开

取舍的重点是是否需要自动恢复连接,以及用户能否在需要时记得手动连接。On Demand 没有适用于所有人的省电答案。关闭后的直接影响是自动触发行为发生变化,而不是保证电池曲线改善;开启后的价值是减少符合条件时的手动操作,而不是保证所有网络切换都无需排查。

结论:需要自动恢复就保留,不需要就采用可验证的手动流程

以“能否稳定完成所需任务”为前提选择连接方式;只有重复对照显示关闭后减少了无效连接,且没有影响正常使用,才把关闭 On Demand 作为个人场景下的调整。

修改后,用一次完整检查收尾

排查结束后,回到 Home 确认连接状态,到 Global Routing 核对实际采用的方式,再检查 Config 中启用的配置。需要自动连接时,恢复 Settings → On Demand 中合适的设置;选择手动方式时,应确认断开后不会因其它已有 VPN 自动连接设置而再次建立连接。

  1. 打开一个自己平时使用的目标服务,确认能否按预期访问,并核对请求路由;不要只以 VPN 状态标识判断所有请求都已成功。
  2. 在下一段相近使用时长后复查系统“设置 → 电池”,判断整机电量下降是否持续改善,而不是只看 Shadowrocket 的列表排名。
  3. 保留最终开关状态、测试网络和错误记录;若没有可重复差异,恢复适合日常使用的设置,避免持续改变多个参数。

本文不为 Shadowsocks、VMess、VLESS、Trojan、Hysteria2 或 WireGuard 排定统一的耗电顺序。协议参数、链路质量和业务负载不同,单凭协议名称不足以预测设备续航。更完整的操作入口可参阅入门指南,术语含义可对照术语表。

App Store 正版核对与连接设置

Shadowrocket 是 Apple 平台的闭源商业应用,通过 App Store 一次性买断。购买前核对开发者 Shadow Launch Technology Limited 与应用 ID 932747118,系统要求以 App Store 页面标注为准。客户端买断 ≠ 线路套餐;本文以用户已有自己的服务商与订阅为前提,不提供、不销售、不推荐节点或订阅。

前往正版核验页 看教程