Shadowrocket（小火箭）在电池列表中占比高，不足以证明隧道本身持续高负载。先核对统计时段、整机掉电和后台流量，再用相同网络与使用时长比较常驻连接和 On Demand。本文适合遇到待机掉电、后台活动时间长或网络切换后反复连接的用户；排查目标是区分实际传输、连接重试与触发条件，而不是仅让电池列表中的数字变小。
先读电池占比，再判断是否异常
在 iPhone 打开系统“设置 → 电池”，选择页面提供的日期或时间范围，并查看对应时段的应用耗电与活动信息。不同系统版本的统计入口和展示方式可能不同，应以设备当前页面为准。点击图表中的某一时段后，先确认下方列表是否也已切换到相同范围，避免把整天耗电与一小时的活动混在一起比较。
应用旁边的百分比表示所选统计范围内的耗电归属占比，不是它单独消耗了多少电池百分点。例如，若一个未充电的观察时段内整机电量从 80% 降到 70%，列表中的 30% 不能读成“该应用让电池下降了 30 个百分点”。电池估算与归属统计也不是精密电表，不宜据此反推出准确功耗。
“后台活动”表示相关工作发生在应用不处于前台的情况下，并不等于屏幕关闭期间处理器始终满负载。Shadowrocket 使用系统网络扩展处理隧道流量；即使没有停留在 Home，其他应用的请求仍可能经过隧道。判断异常应结合相同条件下的整机掉电、发热和连接稳定性，不能只按列表排名下结论。
常驻连接消耗在哪些环节
“连接开关保持开启”与“持续传输大量数据”是两件事。隧道建立后，实际负载受流量大小、规则处理、加密、连接维护及网络质量共同影响。视频、照片同步和文件传输会增加工作量；弱信号环境下的重传和反复重连，也可能让蜂窝通信与隧道处理的成本同时增加。
Home 中的 Global Routing 决定请求采用什么路由姿态，不是省电档位。Proxy、Direct、Config、Scene 不应按“耗电从高到低”排序：Config 需要按配置规则判断，Scene 的结果取决于所设场景；最终功耗还受实际出站与网络情况影响。Direct 也不能直接等同于关闭系统隧道。
- 大量传输：先暂停已知的后台同步或下载，再比较整机掉电；仅切到应用外不能停止其他应用发起请求。
- 连接维护：部分协议与连接配置包含保活机制，具体频率取决于实际配置，不能给所有连接套用统一间隔。
- 网络不稳定：若发热同时伴随请求超时，优先检查信号、网络切换及服务器可达性，不要先堆叠更多自动化条件。
设置 On Demand 前，先做一轮对照
On Demand 是系统按条件触发 VPN 连接的机制，不是“屏幕一关就停止工作”。若条件在大多数时间都成立，它的表现可能接近常驻连接；若条件反复变化，则可能频繁建立隧道。先确定哪些网络确实需要连接，再进入 Settings → On Demand 检查现有配置。
-
记录基线
选择一个可重复的观察时段，例如同一 Wi-Fi 下锁屏 60 分钟。记录起止电量、是否充电、网络类型与已知后台任务；60 分钟是测试安排，不是产品功耗指标。
-
检查当前状态
在 Home 记录当前连接与 Global Routing，在 Config 记录正在使用的配置，再到 Settings → On Demand 记录触发条件。测试过程中不要同时更换服务器、规则和连接姿态。
-
收窄触发范围
按页面提供的网络条件配置 On Demand。若需要按 Wi-Fi 区分，逐字核对 SSID，并确认该条件对应连接还是断开；同一地点的不同频段可能使用不同名称。
-
验证网络切换
在可控环境下分别检查目标 Wi-Fi 与蜂窝网络中的连接状态。若已启用自动触发，手动关闭后可能再次连接，应先核对命中的条件，而不是认定开关失效。
-
复测并保留记录
用相同观察时长复测，记录整机掉电和联网是否符合预期。只在不影响必要联网任务的时段测试断开状态；重复数轮后再决定保留哪一种方式。
按日常场景选择连接方式
没有适用于所有设备的“最省电配置”。常驻连接减少了使用前等待建立隧道的步骤；On Demand 则适合连接需求与网络条件存在明确边界的情况。选择依据是实际使用是否连续、网络是否稳定，以及漏掉触发是否会影响必要任务。
| 使用场景 | 优先尝试 | 核对重点 |
|---|---|---|
| 同一稳定网络中连续使用 | 常驻连接 | 后台是否有持续传输，是否出现超时重试 |
| 仅在特定网络需要隧道 | On Demand | SSID 与连接动作是否准确匹配 |
| 通勤中反复切换网络 | 先简化条件再对照 | 是否短时间内重复建立连接，蜂窝信号是否稳定 |
| 夜间锁屏仍需后台业务 | 先验证业务再决定 | 后台任务能否完成，整机待机掉电是否可重复 |
如果用户已有自己的服务商与订阅，测试期间应固定所用连接，避免把服务端变化误判为 On Demand 的效果。协议名称也不能直接作为省电结论：Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 的具体表现取决于配置、传输环境与业务负载，不能脱离这些条件给出统一排名。
遇到超时与反复连接，先排除重试
如果掉电变快同时出现请求失败，应先解决连接异常，再比较连接方式。下面列出网络日志中可能出现的错误原文；仅在实际记录出现相应文字时按此排查，不要把这些字符串当作每个版本都固定弹出的提示，也不要通过错误本身推算耗电量。
报错: Operation timed out
原因：连接或操作在限定时间内没有完成，可能涉及网络不可达、丢包或服务端无响应。
解法：先核对当前网络和用户已有服务的可用性，再在相同连接下重试一次；若持续失败，停止反复测试并向自己的服务商确认状态。
报错: Connection refused
原因：连接请求被拒绝，常见于目标端口未提供服务或访问策略拒绝。
解法：核对 Home 中所选连接的地址与 Port 是否和服务商提供的信息一致，不要凭经验将端口统一改成 443。
规则问题也应单独验证。在 Config 检查当前配置时，先确认具体规则是否位于宽泛规则之前，以及 FINAL 最终选择了什么策略。下面仅展示直连测试域名的规则语法，不是完整配置，也不是通用省电方案；不要为了减少列表占比而把全部请求改成 DIRECT。
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,PROXY这两行表示 example.com 及其子域名选择 DIRECT，未被前面规则命中的请求交给 PROXY。实际使用前仍需核对配置中的策略定义。DOMAIN-SUFFIX、GEOIP、IP-CIDR 判断的是不同类型的目标信息，On Demand 判断的是何时建立连接，两者解决的问题不同。
后台耗电常见问题
后台活动时间很长，是不是一直在耗电？
后台时长不代表持续高功耗。先到系统“设置 → 电池”选择相同时间范围，再核对整机掉电和屏幕活动。若锁屏时有同步或消息连接，隧道仍可能参与处理；以重复对照结果判断，不以单个时长下结论。
把 Shadowrocket 从后台划掉能省电吗？
划掉前台应用不能作为系统 VPN 已断开的依据。应在 Home 检查连接状态，并在 Settings → On Demand 核对是否存在自动重连条件；需要测试断开状态时，也要确认触发条件不会马上重新建立连接。
开启 On Demand 后反而更耗电怎么办？
先观察是否集中发生在 Wi-Fi 与蜂窝网络切换期间，再检查 Settings → On Demand 中是否有范围过宽或相互冲突的条件。每次只调整一条条件，保持相同连接和测试时长；若条件始终成立，按需连接并不会自动带来明显空闲时段。
把 Global Routing 改成 Direct 就算断开了吗？
不算。Direct 是请求的路由姿态，连接开关与 On Demand 才涉及隧道是否建立。测试“连接”和“断开”的差异时，应核对实际 VPN 状态，不能只改 Global Routing 后比较电池数字。
应该每天更新订阅来解决耗电吗？
订阅更新用于同步用户已有服务商提供的连接信息，不是电池维护操作。只有地址、端口或服务信息变化时，更新才可能间接解决连接失败。先确认失败原因，避免在不通的网络中反复刷新，也不要同时更改多个设置。
最终保留的方案，应同时满足三个条件：需要的业务可用、连接切换符合预期、相同场景下整机掉电可以接受。如果两种方式差别很小，优先保留更容易理解和复核的配置。后续再次出现异常时，沿用同一套记录方法，先找流量与网络变化，再调整 On Demand。