排查 Shadowrocket（小火箭）耗电，先比较相同使用条件下的整机掉电，再查看后台活动和连接日志；不能只凭电池列表中的占比判断。本文面向已经有自己的服务商、订阅和可用配置的用户，依次说明如何建立基线、区分常驻隧道与持续传输、测试 On Demand（按需连接），最后按实际使用习惯选择连接方式。
一、先看整机掉电，再读电池占比
在 iPhone 或 iPad 的系统“设置 → 电池”中，选择与异常发生时间重合的统计时段，再查看 Shadowrocket 的电量使用和活动情况。系统版本不同，时间范围和详情名称可能不同，以设备实际显示为准。电池列表中的应用百分比是所选时段内的耗电归因占比，不是应用直接消耗了同等数值的电池电量。
例如，看到“30%”不能直接写成“Shadowrocket 掉了 30 格电”。如果这段时间整机用电很少，某个后台项目仍可能占较大比例。相反，整机掉电明显、设备发热且后台活动持续，才值得进一步核对网络请求、信号状况及重连情况。VPN 图标存在也不能单独证明正在大量传输数据。
-
核对时段
进入系统“设置 → 电池”，选中异常时段，记录起止电量、屏幕使用情况，以及这段时间是否充电。不要把白天导航与夜间待机直接比较。
-
记录连接
回到 Shadowrocket 的 Home（主页），记录连接开关、当前选择的已有节点和 Global Routing（全局路由）状态；再到 Config（配置）确认当前启用的配置文件。
-
检查触发
进入 Shadowrocket 的 Settings → On Demand，记录按需连接是否启用，以及已有规则涉及哪些网络条件。先保留原设置记录，再进行对照修改。
-
建立基线
选择一个不充电、信号稳定的时段，记录亮度、Wi-Fi 或蜂窝网络、主要使用任务和开始电量。每轮使用同样的观察时长，例如 60 分钟。
二、后台常驻不等于后台一直满负荷运行
Shadowrocket 的应用界面与系统承载的 VPN 隧道不是同一个观察对象。离开 Home 后，连接仍可继续处理符合条件的网络流量；应用不在前台，也不意味着网络处理已经停止。反过来，隧道处于连接状态时，如果没有持续请求，也不能把整段连接时间都视为高负载时间。
实际电量还受传输量、加密处理、无线信号、网络切换和连接重建影响。照片同步、视频播放或其他应用持续请求时，即使 Shadowrocket 的界面一直关闭，隧道仍可能处理流量。弱蜂窝信号下的无线通信也可能增加整机耗电，不能只把变化归因于代理协议。
- 连接常驻：描述隧道保持可用，不代表每秒都在大量收发。
- 持续传输：应结合使用任务和可用的流量记录判断，重点查后台同步与长时间播放。
- 反复重连：常发生在网络不稳定、切换网络或触发条件变化时，需要核对失败时间与网络状态。
- 反复划掉应用：不能替代检查 On Demand，也不是可靠的隧道状态管理方式；需要停止时，应核对连接开关与系统 VPN 状态。
三、区分 Global Routing 与 On Demand 的职责
Global Routing 决定流量采用何种路由方式，On Demand 决定系统在什么条件下建立或管理连接。两者不是同一个省电开关。特别是把 Global Routing 切换到 Direct（直连），并不等于关闭 VPN 隧道；如果要对照“未连接”状态，需要另外核对连接开关与 On Demand。
| 设置 | 主要职责 | 排查时的注意点 |
|---|---|---|
| Proxy（代理） | 采用代理路由方式 | 可能改变经过代理的流量范围，不应直接当作省电模式。 |
| Direct（直连） | 采用直连路由方式 | 直连不等于隧道已断开。 |
| Config（配置） | 按当前配置中的规则分流 | 先确认启用的是哪份配置，以及规则最终命中的去向。 |
| Scene（场景） | 采用已设置的场景逻辑 | 需要同时核对场景条件，不宜与固定路由状态混作同一组测试。 |
| On Demand | 按条件管理连接 | 核对网络条件及规则顺序，避免预期断开后又被条件触发连接。 |
在 Config 中，DOMAIN-SUFFIX 表示域名后缀匹配，GEOIP 表示按 IP 地理归属匹配，IP-CIDR 表示按 IP 网段匹配，FINAL 是前面规则均未命中时的最终去向。这些规则解决流量去向，不直接规定连接保持多久。为节电盲目删除规则，可能改变访问路径，却不一定减少后台请求。
四、用三轮对照判断 On Demand 是否适合
On Demand 只有在触发条件与使用场景相符时，才可能减少不需要的连接时间。它不是自动识别所有应用需求的通用节电功能。如果条件过于宽泛，连接可能长时间保持；如果网络条件频繁变化，则可能增加连接建立次数。按域名评估的条件也不等于“打开任意应用才连接”。
建议先用单一网络条件验证，例如先只验证某个 Wi-Fi 环境，不要一开始同时叠加 Wi-Fi 名称、蜂窝网络与域名条件。涉及规则动作和顺序时，以 Settings → On Demand 内实际提供的字段为准，逐条核对，不照搬未知来源的整组规则。
-
保存原状
记录 Settings → On Demand 的启用状态与现有规则顺序，同时记录 Home 的 Global Routing。测试期间不更新订阅、不切换节点、不替换 Config。
-
测断开组
暂时关闭 On Demand，再关闭连接，核对系统 VPN 状态。执行预先选定的本地或可直连任务，记录 60 分钟起止电量；无法完成相同任务时，该组只作待机基线。
-
测常驻组
保持 On Demand 关闭，手动连接同一个已有节点，采用原来的路由方式。在相近电量与相同网络下重复同一任务，记录掉电与异常重连情况。
-
测按需组
进入 Settings → On Demand，启用已经核对过的单一网络条件。先验证符合条件时的连接行为，再验证离开条件后的行为；每次都检查系统 VPN 状态，不只看开关设置。
-
重复比较
每组再观察一个相同长度的时段。若电量差异很小或波动方向不一致，先记为无法区分，不给出固定省电百分比；同时比较连接等待是否影响使用。
以上 60 分钟是测试安排，不是产品续航结论。应尽量固定屏幕亮度、信号、任务和环境温度，避开充电、系统集中同步等干扰。短时结果不稳定时，可以延长观察时段，但仍要保持各组条件可比。
五、反复重连时，先处理网络错误
若异常耗电与连接失败同时发生，先核对日志的时间顺序：是网络断开后开始重试，还是已有节点持续无法连接。以下为可能出现在连接日志中的系统网络错误文本示例，并非电池告警；实际大小写、附加信息和显示位置以应用中的记录为准。单条错误不能直接证明它造成了多少耗电。
报错：Connection refused
原因：目标地址或端口的连接被拒绝，可能是服务未监听或连接被主动拒绝。
解法：在 Home 核对用户已有节点的地址、端口与协议；若订阅管理的条目有变更，按自己的服务商说明更新后再试，不反复手动改写猜测值。
报错：Operation timed out
原因：连接或相关操作未在规定时间内完成，可能涉及网络丢包、目标不可达或响应过慢。
解法：固定同一节点，在稳定 Wi-Fi 下重试一次，再用已有的另一条可用连接做对照；不要连续运行整组延迟测试来代替故障定位。
报错：Network is unreachable
原因：当前网络路径不可达，可能与网络切换或设备当时没有可用连接有关。
解法：先核对系统网络能否正常访问，再检查 Settings → On Demand 中涉及当前网络的条件，避免在网络尚未恢复时反复切换连接。
- 记录发生时间、网络类型和错误原文，分享日志前移除订阅地址、认证信息与私人域名。
- 排障时只做必要的单次测试；持续测试多个节点本身也会产生网络活动，影响电量对照。
- 若启用了额外的详细日志记录，完成定位后恢复日常设置，不把排障负载混入长期观察。
- 若断开 Shadowrocket 后仍有相近的掉电与发热，继续检查系统电池列表中的其他活动及信号状况。
六、按使用习惯选择常驻或按需
常驻与按需的取舍应结合连接频率，而不是预设其中一种一定省电。一天内频繁使用同一连接时，稳定常驻可能减少等待与反复建立连接；仅在特定网络或少数时段需要连接时，经过验证的 On Demand 条件更便于减少无关时段的连接。两种选择都应通过自己的电池记录验证。
| 使用习惯 | 先尝试的方式 | 需要验证的现象 |
|---|---|---|
| 一天内频繁访问相同资源 | 固定节点与 Config，先观察稳定常驻 | 有无持续传输、失败重连，以及等待时间是否减少。 |
| 只在特定 Wi-Fi 环境需要连接 | 在 On Demand 中设置并验证网络条件 | 进入及离开该网络时，行为是否符合预期。 |
| 经常往返 Wi-Fi 与蜂窝网络 | 先减少条件复杂度，分别测试两种网络 | 切换时是否反复重建连接，弱信号是否伴随发热。 |
| 仅偶尔使用且时间明确 | 先采用手动连接与断开作为对照 | 断开后是否被 On Demand 再次触发，结束任务后是否仍有后台活动。 |
协议名称也不能替代测量。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 的连接方式和参数不同，但设备、链路、实际吞吐及服务端条件同样影响结果。只在已有服务支持的范围内测试，不为追求未经验证的节电效果随意更换协议或套用不匹配的参数。
七、耗电与按需连接常见问题
锁屏后 VPN 图标还在，是不是一直耗很多电？
图标说明连接状态，不能说明吞吐量。先看系统“设置 → 电池”中对应时段的整机掉电和后台活动，再核对是否有同步任务或失败重连。需要确认断开时，暂时关闭 Settings → On Demand 并核对系统 VPN 状态。
开启 On Demand 后，为什么没有明显省电？
先检查条件是否让连接几乎始终保持，以及网络切换是否增加了重连。到 Settings → On Demand 记录条件和顺序，先只保留一个已验证的测试条件，再与手动常驻组做相同时长的对照。
改成 Direct 后，为什么电池里还有活动？
Home → Global Routing → Direct 改变的是路由方式，不等于停止隧道。需要做断开基线时，应另行关闭按需触发与连接，并确认系统 VPN 状态；同时注意电池页面仍可能包含更早时段的统计。
订阅更新和延迟测试要一直运行吗？
不需要把重复测试当作保持连接的必要步骤。先完成必要的订阅更新，再固定节点进行电量对照；记录期间避免反复在 Home 刷新订阅或测试整组节点，以免额外请求干扰判断。
最后保留一份可复现的记录：设备、网络类型、测试时长、起止电量、Global Routing、On Demand 状态，以及异常时间。调整一次只改变一个变量；若效果无法重复，就恢复原配置并继续观察，比同时关闭多项功能更容易找到原因。