Shadowrocket（小火箭）在电池页出现后台活动，并不等于存在异常耗电。先核对统计时段、整机掉电和网络活动，再比较 On Demand 与手动连接。本文适合已经有自己的服务商与订阅、希望减少不必要连接的 iPhone 与 iPad 用户；排查完成后，可以根据实际使用时段决定是否保留自动连接。
先读电池页：占比不是整机掉电量
先打开系统“设置 → 电池”，选择页面提供的统计时段，再查看 Shadowrocket 的电池用量与活动记录。系统版本不同，图表、时间范围和活动明细的呈现可能不同；比较时应保持所选范围一致，不要拿一天的累计占比与一小时的掉电量直接比较。
应用旁的百分比是所选时段内的用电归因占比，不是应用单独消耗了多少电池容量。例如，某段时间电量从 80% 下降到 70%，而应用列表显示 Shadowrocket 为 20%，不能据此说它让整机掉了 20 个百分点。这个例子仅说明统计口径，不能用简单相乘代替系统的实际能耗测量。
后台活动说明应用或相关网络扩展在后台执行了工作，不能单凭持续时间判断 CPU 一直高负载。其他应用产生的网络请求可能经过 VPN 隧道，电池页的归因也不等于某个应用独占了全部网络成本。只有后台活动增加、整机掉电明显增加，并且能在可比条件下重复出现，才值得继续追踪。
- 先确认该时段是否充电，充电前后的电量不能直接拼成连续放电样本。
- 核对是否播放视频、进行通话、同步照片或更新应用；这些活动会改变网络负载。
- 记录屏幕使用时间、亮度与 Wi-Fi 或蜂窝网络，避免只盯着应用排名。
- 留意弱信号与频繁切换网络；无线连接本身的成本也会影响整机掉电。
On Demand 控制连接触发，不等于一直传输
在 Shadowrocket 中打开 Settings → On Demand，核对当前开关和已经配置的触发条件。On Demand 用于让系统按条件处理 VPN 连接；是否建立连接，取决于当前条件与设置。它不是“开启后所有时刻都在大量传输”的同义词，也不能仅凭这个开关推算固定的耗电增幅。
连接建立后，实际成本与流量、协议处理、重连和网络环境有关。空闲连接与持续视频传输并不是同一种负载；网络不稳定时反复建立连接，也与稳定 Wi-Fi 下的空闲连接不同。因此，排查应区分“自动连接触发得太频繁”和“连接后某项业务持续传输”。
Global Routing 与 On Demand 解决的是两件事。前者决定连接状态下怎样处理请求，后者决定何时按条件发起连接。Global Routing 中的 Config 按配置规则处理，Proxy 与 Direct 用于相应的整体路由姿态，Scene 按已设场景使用。把 Global Routing 切到 Direct，并不等于关闭 VPN 隧道，也不是手动断开的替代步骤。
- 进入 Settings → On Demand，先记录原有条件，避免调整后无法恢复。
- 检查常用 Wi-Fi、蜂窝网络及域名相关条件是否符合当前使用目标。
- 一次只调整一个条件，回到 Home 检查连接状态，再切换网络验证行为。
- 需要测试彻底手动控制时，先关闭 On Demand，再在 Home 关闭连接开关。
用相同条件比较：不要一次改完所有设置
要判断 On Demand 是否与自己的耗电变化有关，应安排两个可比较的观察窗口，而不是凭一次夜间掉电下结论。可以先用 60 分钟作为记录窗口：第一轮保留当前 On Demand 设置，第二轮关闭 On Demand 并按需要手动连接。60 分钟只是方便记录的起点，不是测量标准；掉电太少、系统图表不够细时，应延长观察。
| 记录项 | On Demand 轮次 | 手动连接轮次 |
|---|---|---|
| 连接方式 | 保留原触发条件，记录自动连接情况 | 关闭 On Demand，需要时在 Home 连接 |
| 网络环境 | 固定地点与同一 Wi-Fi，或相近蜂窝信号 | 尽量保持相同，不同时切换接入环境 |
| 业务与路由 | 记录使用的应用、配置和 Global Routing | 保留同一配置与路由姿态，重复相近任务 |
| 结果记录 | 起止电量、屏幕活动、后台活动、连接异常 | 记录相同项目，同时记录实际连接时长 |
如果第二轮在大部分时间断开，而第一轮一直满足连接条件，两轮比较反映的是整套使用方式的差别，不能把所有差异都归因于 On Demand 开关本身。若要专门检查自动触发机制，则应尽量让两轮连接时长与业务负载接近，另外观察网络切换时是否出现反复连接。
结论：先确认差异能重复，再决定长期模式
若手动断开的空闲时段反复出现更低的整机掉电，可以保留按时段手动连接；若两轮差别不稳定，先排除信号与后台同步，不必仅为降低电池页排名关闭 On Demand。
异常掉电时，按连接、重试、配置顺序排查
耗电突然增加时，先看使用环境有没有变化，再检查连接是否稳定。不要先更换协议或重建全部配置。用户已有的服务参数应以自己的服务商提供的信息为准；本篇只检查现有连接，不提供或推荐任何服务入口。
- 确认自动重连来源。若刚在 Home 断开就再次连接，先回到 Settings → On Demand 检查条件。不要反复点连接开关，把符合条件的自动连接误认为开关失效。
- 区分 Wi-Fi 与蜂窝网络。在同一位置分别观察连接稳定性。只在蜂窝弱信号时出现问题，应先记录信号与网络切换，不急着调整规则。
- 停止重复测试。完成一次必要的延迟或连接测试后，返回正常使用状态。连续执行测试会主动产生请求，不适合用于空闲耗电对照。
- 核对已有参数。如果日志出现 TLS 或连接失败，检查地址、端口、认证信息与系统时间。端口必须与服务端一致，不能因为常见 HTTPS 使用 443 就统一改成 443。
- 检查配置变化。若问题紧随已有订阅更新或 Config 切换出现，先核对当前所选连接与配置。保留副本后再逐项调整，不要同时修改路由、协议和自动连接条件。
报错：NSURLErrorDomain Code=-1001
原因与解法：这是 Apple 网络请求超时的错误代码；若实际日志包含该代码，表示对应请求未在期限内完成，不能单凭它定位到协议参数。先确认是哪次请求超时，在稳定网络下重试一次，并检查目标地址与端口；若持续失败，再结合日志上下文核对已有服务信息，避免连续重试干扰耗电观察。
错误字符串可能随系统和请求类型不同而变化，未出现上述代码时不必刻意寻找。记录实际错误原文、发生时间和当时网络类型，比仅记录“后台很多”更利于定位。分享日志前，应遮去订阅地址、访问凭据、完整服务地址及其他个人信息。
按使用场景取舍：保留自动化还是手动断开
没有适用于所有人的固定省电模式。选择依据应是连接需求是否连续、网络条件是否稳定，以及能否接受手动操作。关闭 On Demand 后忘记连接，应用请求会按当时的系统网络状态处理；如果使用流程依赖 VPN，手动模式需要额外确认连接状态。
- 每天只有少量固定任务：可选择手动连接，任务结束后在 Home 断开；同时关闭 On Demand，避免条件再次触发连接。
- 全天频繁使用相关业务：可保留 On Demand，重点核对触发条件与稳定性，避免为每次短任务重复操作。
- 经常往返不同 Wi-Fi 与蜂窝网络：先验证切换前后的实际行为。若只在特定网络需要连接，按需求收窄条件，而不是无差别扩大触发范围。
- 夜间主要待机：在确认没有依赖 VPN 的后台任务后，可安排一次手动断开的对照；保持照片同步、充电状态和网络环境尽量一致。
不要用不必要的规则改动替代连接管理。DOMAIN-SUFFIX、IP-CIDR、GEOIP 和 FINAL 用于匹配与分流，不是省电开关。若当前 Config 已满足业务需要，先保持规则不变，优先减少不需要的连接时段和失败重试；也不要仅凭协议名称推定哪一种必然更省电。
常见问题：后台活动与断开后的检查
锁屏后还有后台活动，是不是一直在跑满？
不是。先在系统“设置 → 电池”选择对应时段，核对整机电量变化与其他应用活动。锁屏后仍可能存在同步或网络请求，后台时长本身不表示持续高负载；应结合相同网络下的重复观察判断。
我已经手动断开，为什么过一会儿又连上了？
先进入 Settings → On Demand 检查是否仍启用自动连接及其条件。进行手动断开测试时，先关闭 On Demand，再回到 Home 断开；切换一次 Wi-Fi 或蜂窝网络后，再确认没有自动恢复连接。
切到 Direct 就能当作关闭连接吗？
不能。Global Routing 的 Direct 改变路由姿态，不等于移除当前 VPN 连接。要观察断开状态，应检查 Home 的连接开关，同时排除 On Demand 再次触发；测试完毕后恢复原来的路由设置。
关闭后电池页还是排在前面，要不要马上重装？
先不要重装。电池页保留所选时段的历史统计，关闭连接不会清除先前用量。选择关闭后的观察范围，或等新的完整时段形成，再比较整机掉电；先保存配置和排查记录，避免重装丢失线索。
最终应保留一套能复核的记录：系统电池页所选范围、起止电量、网络类型、On Demand 状态、Global Routing 姿态以及异常日志。先处理可重复的连接问题，再决定长期使用自动还是手动模式，不以某一次占比高低作为唯一依据。