Shadowrocket（小火箭）的电量开销需要结合流量、信号和重连次数判断，不能只看 VPN 图标或电池榜排名。本文适合已经有自己的服务信息、希望调整日常连接方式的 iPhone 与 iPad 用户：先区分隧道与应用后台，再设置 On Demand，最后用相同使用条件对照电池记录。
后台常驻为什么会出现在电池用量里？
看到 Shadowrocket 的后台活动，是否说明它一直在高负载运行？不是。应用的前台界面与承载连接的系统网络扩展不是同一件事。离开 Home 后，VPN 隧道仍可继续处理其他应用的网络请求；界面不在屏幕上，不等于网络处理已经停止。
电量主要消耗在哪些环节？有流量时会涉及数据处理、加解密和网络收发；空闲时也可能存在保活、DNS 请求与重连。视频播放、照片同步或大文件传输产生的请求可以经过隧道，所以电池页里的相关活动不一定来自 Shadowrocket 前台操作。
电池占比能否直接当成额外耗电比例？不能。系统电池页显示的是所选时段的用量归因，占比还受其他应用活动影响。应进入设备“设置 → 电池”，对照同一时段的电量曲线、屏幕使用情况和后台活动，再判断是否出现了异常下降。
- 先看时段：选择包含问题的时间范围，不把整天记录与十分钟测试混在一起。
- 再看业务：确认当时是否在同步、下载、播放媒体或持续收取消息。
- 最后看网络：记录 Wi-Fi 或蜂窝网络、信号情况以及是否发生切换。
On Demand 能否在没有流量时自动省电？
On Demand 是空闲计时器吗？不是。它让系统根据配置的网络条件和连接规则处理按需连接，不能理解为“没有流量就自动断开，打开任何应用就自动恢复”。触发行为取决于实际规则，启用后也不保证电池用量必然下降。
On Demand 与 Global Routing 有什么区别？前者决定何时触发连接，后者决定连接中的请求如何处理。在 Home → Global Routing 中，Proxy、Direct、Config、Scene 属于不同处理方式；Config 按当前配置规则分流，Scene 按已设置的场景工作。切换这些选项并不等于关闭 On Demand。
结论：先确定连接条件，再调整流量策略
若目标是离开某个 Wi-Fi 后自动连接，先检查 Settings → On Demand；若目标是让部分请求直接连接，再检查 Home → Global Routing 与 Config。不要用 Direct 代替关闭隧道，也不要用 On Demand 代替分流规则。
Wi-Fi 与蜂窝网络应该怎样分别设置？
是否应该在所有网络上一律启用？应按实际需要区分。操作前先在 Home 手动连接，使用自己的服务信息确认访问正常，再进入 Settings → On Demand 查看可配置的网络条件。不同界面版本的具体选项以应用内显示为准，不能把网络名称条件、连接动作和总开关当成同一项。
- 确认已有连接可用。在稳定 Wi-Fi 下打开一个日常使用的页面，记录当前 Global Routing 与配置。若手动连接就失败，先修复连接，不叠加自动触发条件。
- 设定 Wi-Fi 范围。需要按网络名称区分时，核对实际 SSID。相近名称不是同一个网络；同名网络也不代表一定可信，应结合自身网络管理情况判断。
- 单独检查蜂窝网络。如果移动状态也需要连接，就核对蜂窝网络对应的条件；如果只在固定网络使用，则确认切换到蜂窝网络后的实际状态，不能只凭总开关推断。
- 做一次往返切换。从 Wi-Fi 切换到蜂窝网络，等待网络稳定后发起一次请求；再回到 Wi-Fi，检查系统 VPN 状态与 Home 中的连接状态。
- 锁屏后复查。记录锁屏前的网络与连接状态，稍后解锁发起同一请求，检查是否出现连接延迟或重复重连。
手动关掉连接后为什么又恢复？可能是 On Demand 条件仍然满足，系统随后重新触发连接。需要做完全断开测试时，先在 Settings → On Demand 暂停按需连接，再关闭 Home 中的连接；测试结束后恢复原设置。不要通过反复结束前台应用来代替这一步。
保持连接与按需连接，怎样选择？
哪种方式一定更省电？没有适用于所有网络的固定答案。稳定连接可以避免反复建立会话；按条件连接可以减少不需要时的隧道使用。但如果条件边界频繁变化，重新连接、握手和恢复业务也会带来开销，应把连接成功率和电量一起比较。
| 使用情境 | 设置取向 | 需要检查 |
|---|---|---|
| 同一网络内持续使用 | 先保持稳定连接作为基线 | 有无后台大流量与异常重连 |
| 只在特定网络需要连接 | 按网络条件设置 On Demand | 进入与离开该网络后的实际状态 |
| 通勤时网络反复切换 | 减少不必要的条件切换 | 恢复请求所需时间及失败次数 |
| 准备短时断开对照 | 暂停 On Demand 后手动断开 | 是否仍被系统重新触发连接 |
改为 Direct 是否就能测出“不开隧道”的耗电？不能。Direct 表示直接连接的处理策略，不等于系统 VPN 隧道已经停止。类似地，Config 中的 DOMAIN-SUFFIX、GEOIP、IP-CIDR 和 FINAL 负责匹配与选策略，不负责决定 On Demand 何时启动。
结论：频繁恢复失败时，先减少切换变量
若每次网络切换后都需要等待或重试，先在同一网络下保持连接验证稳定性。确认基础连接正常后，再逐项加入 On Demand 条件，不同时更改协议、DNS 与 Global Routing。
发热或重连频繁时，先查哪些记录？
设备发热能否直接归因于某一种协议？不能。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 的连接方式不同，但实际开销还与流量、服务器响应、传输配置和无线信号有关。协议选择必须与自己的服务信息一致，不能为测试随意改 Type 而保留另一种协议的字段。
日志中应先找什么？先对齐故障时间，再找是否连续出现超时、连接拒绝或握手失败。下面列的是可能出现的底层错误片段，不是所有版本都会使用的完整弹窗文案；应保留实际原文和发生时间，再按错误类别排查。
报错：connection refused
原因：目标连接被拒绝，常见于端口没有服务监听或被明确拒绝。
解法：在 Home 打开当前服务器配置，对照自己的服务信息核对地址与 Port，再向自己的服务商确认该端口是否可用；不要反复切换 On Demand 掩盖基础连接故障。
报错：TLS handshake timeout
原因：TLS 握手未在限时内完成，可能涉及链路不通、网络限制或服务端响应异常。
解法：先在稳定网络重试，再核对 TLS 相关配置与服务端要求；若只在某个 Wi-Fi 出现，先检查网页认证和网络连通性，不以关闭证书校验作为通用处理。
没有错误但仍持续耗电，接下来怎么办？先暂停正在进行的大流量业务，观察空闲时段是否仍有明显下降。再检查是否设置了过密的定时测试或其他周期任务，并区分订阅更新与隧道连接：更新自己的订阅是刷新配置来源，不是修复弱信号或自动降低电量的手段。
- 弱信号场景：先移到信号稳定的位置复测，避免把蜂窝网络反复搜索与传输重试全部归因于隧道。
- 持续大流量：先确认同步或媒体业务，记录业务停止后的变化。
- 重复失败：保留脱敏后的错误时间与原文；不要公开订阅链接、密码或完整连接凭据。
如何做一次能复核的电池对照？
怎样比较才不会被电池榜误导？使用同一台设备、相近电量区间和相同网络，分别记录持续连接与按需连接。下面的时间长度是测试安排，不是实测结果，也不代表任何固定耗电承诺。
- 建立记录。记下起始电量、屏幕亮度、网络类型、Global Routing 和后台同步状态，测试期间不要充电。
- 观察持续连接。先做 30 分钟屏幕关闭观察，再做 30 分钟固定操作，例如重复阅读同类网页；分别记下结束电量。
- 观察按需连接。恢复相近初始条件，使用已验证的 On Demand 条件重复相同安排，并记下网络切换与重新连接次数。
- 补做断开基线。暂停 On Demand 并断开连接，以能直接完成的相同业务复测；若业务无法直接访问，就不把这组结果当作等价对照。
- 重复核对。至少重复一轮。若差异接近系统电量显示粒度，延长观察时间，不据此宣称某项设置节省了固定百分比。
最终应该保留哪套设置？优先保留能稳定完成业务、切换后恢复正常的方案，再比较重复测试中的电量变化。若 On Demand 减少了不需要的连接且没有增加失败，就保留对应条件；若频繁重连影响使用，则先简化条件并排除网络问题。稳定与省电需要共同验证，不能只以 VPN 图标是否出现为标准。