Shadowrocket’s share of battery usage does not directly show how much extra power it consumes. This guide is for iPhone and iPad users who have imported their own configuration and noticed increased background activity. First, distinguish traffic handling and network reconnections from requests made by other apps. Then review Settings → On Demand and compare usage under the same network conditions to decide whether automatic connections are necessary.
1. Check iOS Battery usage before drawing conclusions from background activity
On your iPhone, go to Settings → Battery, choose a time range that shows app activity, and select the period when the issue occurred. Note Shadowrocket’s share of battery usage, activity while the screen was on or off, and whether video playback, photo syncing, or file transfers happened during the same period. Names and reporting periods can vary by iOS version; refer to what your device displays.
Battery usage percentages show an app’s relative share of consumption during the selected period, not the percentage points of battery it used on its own. For example, if your device drops from 80% to 70% and an app accounts for 20% in the list, that does not mean the app drained the battery from 80% to 60%. The figures also reflect system attribution and reporting methods, so they should not be used to estimate exact power consumption.
Shadowrocket handles connections through a system network extension. The tunnel may remain active after you leave the app, and requests from other apps may also pass through it. Background activity therefore does not, by itself, prove that the main app is continuously performing foreground tasks. Review battery data, actual traffic, and connection status on the same timeline.
Bottom line: Check whether total battery drain is actually abnormal
If the app’s share rises but total battery drain over the same period does not, keep your current settings for now. Investigate further only if you also see increased total drain, unusual traffic, or repeated connections.
2. On Demand controls connection triggers—it is not a timed battery-saving switch
On Demand lets the system establish connections based on specified conditions. Its role differs from Global Routing: On Demand determines when a connection is triggered, while Global Routing determines how traffic is routed once connected. Enabling On Demand does not mean all traffic goes through a proxy, and disabling it does not necessarily disconnect an existing connection.
| Setting | What it controls | What to check when troubleshooting |
|---|---|---|
| On Demand | The system starts a connection when the conditions are met. | After disabling it, check the actual connection status in Home. |
| Global Routing → Proxy | Uses a proxy routing mode. | More requests may pass through the proxy, so these results cannot be directly compared with traffic records in Config. |
| Global Routing → Direct | Uses a direct connection mode. | Changing routing to Direct does not mean the system tunnel is off. |
| Global Routing → Config | Traffic handling is determined by the rules in the current configuration. | Confirm that the intended configuration is active, not merely imported. |
| Global Routing → Scene | Uses the configured Scene. | Check which Scene is active to make sure routing conditions do not change during testing. |
A persistent connection uses power to maintain the tunnel and handle traffic, but repeatedly disconnecting and reconnecting may also involve DNS lookups, handshakes, and retries. Neither “always connected uses less power” nor “disconnecting after every use always saves power” is universally true. The result depends on network stability, request frequency, protocol settings, and server behavior.
3. Establish a battery baseline with a one-variable test
Run tests when they will not interrupt essential network tasks. Save your configuration beforehand and note your current On Demand settings so you can restore them. Do not change protocols, edit rules, update subscriptions, and adjust automatic connections at the same time; otherwise, you will not know which change caused the result. The durations below are for structuring observations, not power-consumption targets.
-
Record a baseline
In the same location and on the same Wi-Fi network, note the starting battery level, signal strength, and time. Keep conditions such as screen brightness and Low Power Mode consistent. Observe for 60 minutes, avoiding system updates and large file syncs.
-
Disable On Demand
Open Shadowrocket → Settings → On Demand. Note the current settings, then disable them. Return to Home, disconnect manually, and confirm that the connection does not restart automatically.
-
Observe while idle
Lock the screen and leave normal notifications enabled. Afterwards, check the corresponding period in Settings → Battery. Record the battery change and activity from other apps; do not attribute all drain from notifications or syncing to Shadowrocket.
-
Connect manually
On Home, manually connect using your existing configuration. Keep Global Routing and the server selection unchanged, then observe for the same length of time. Check for unusually high traffic or connection errors.
-
Restore On Demand
Return to Settings → On Demand and restore the conditions you intend to use. Observe again under a similar workload. If the issue occurs only in this round, first check condition matching and network changes rather than immediately changing protocols.
A one- or two-percentage-point difference in a single test is not enough to show that one setting is better: battery readings are rounded, and iOS schedules background tasks. Repeat the test under the same conditions and compare trends that appear consistently. If the device gets noticeably warm, stop high-load tasks and let it cool before testing again, since temperature can affect the results.
4. Configure Wi-Fi and cellular conditions separately to avoid conflicts
Go to Settings → On Demand and edit the rules using the network types and Wi-Fi conditions available in the current interface. Condition names and options may vary, so refer to what your app displays. The goal is to decide whether each network type needs an automatic connection, not to enable every condition. After saving, switch networks once to verify the result.
| Network scenario | Configuration approach | How to verify |
|---|---|---|
| Home Wi-Fi you use regularly | Decide whether to connect automatically based on your actual needs. If you do not need an automatic connection, consider excluding this Wi-Fi condition. | Reconnect to the same Wi-Fi network. Check that the connection behaves as expected and test the resources you need to access. |
| Public Wi-Fi that requires sign-in | Complete network sign-in before testing the tunnel. Do not mistake an incomplete sign-in for a protocol issue. | Confirm that the system sign-in page is complete, then connect manually once from Home and check access. |
| Reliable cellular service | Keep the relevant On Demand condition if you need a persistent connection. If not, use a manual connection as a comparison. | Turn off Wi-Fi and check the connection status. Note whether cellular data usage matches your actual activity. |
| Weak signal or frequent network switching | Check for network instability first. Temporarily disable On Demand for diagnosis instead of masking the issue with repeated reconnections. | Test again in an area with a stable signal and see whether the errors stop. Restore your original settings if needed. |
A Wi-Fi connection does not guarantee internet access. An upstream router issue, an expired sign-in, or movement between access points can all cause brief interruptions. Weak cellular signals can also increase radio power consumption, which cannot be fixed simply by changing Shadowrocket’s routing rules.
- Change one condition at a time. After saving, test connecting to Wi-Fi, leaving Wi-Fi, and locking and waking the screen.
- If you use a Wi-Fi name condition, check the exact network name so that similarly named guest networks are not treated as the same network.
- Do not disable a connection required for essential tasks just to improve the battery reading. During manual-disconnect testing, apps that rely on the connection may be affected.
5. If connections keep retrying, check errors instead of masking the issue with longer timeouts
If battery drain coincides with repeated connection failures, first note the network and time of each failure, then check the available connection logs. The English messages below may appear in network errors; logs may also include a domain, port, or system error domain. If none of these messages appear, do not infer that a specific error occurred based on battery drain alone.
Error: Network is unreachable
Cause: No usable network path is available for the request. This can happen during an outage or while switching networks.
Fix: First confirm that Wi-Fi sign-in is complete or cellular data is available, then connect manually from Home. If the error occurs only during network switches, note when they happen and review the On Demand conditions.
Error: Connection refused
Cause: The destination refused the connection on that port, often because the service is not listening or the port is incorrect.
Fix: Check the address, port, and protocol against your own service configuration. A port number of 443 alone does not mean that a working TLS service is available.
Error: Operation timed out
Cause: The operation did not complete in time. Possible causes include packet loss along the route, an unreachable destination, or an unresponsive handshake.
Fix: Try connecting manually again on a stable network and check your existing configuration parameters. Do not simply increase the timeout to keep a repeatedly failing connection alive.
For configurations using Trojan, VLESS, or other protocols, TLS, SNI, and related transport settings must match your own server’s requirements. Do not address battery drain by weakening certificate verification. If traffic continues to rise noticeably after normal use has ended, first identify which app is generating requests—for example, ongoing sync or media playback in the background—instead of attributing all traffic to reconnections.
6. Balance Background App Refresh, subscription updates, and routing rules
iOS Settings → General → Background App Refresh and Shadowrocket’s On Demand feature are separate mechanisms. The former affects an app’s opportunities to refresh in the background; the latter controls system-triggered VPN connections. Turning off Background App Refresh does not prove that the tunnel has stopped, nor does it guarantee that all background network requests will stop.
- Subscription updates: If you use a subscription you already have, check its update schedule. Updates generate requests, but confirm that they are actually happening frequently before changing the schedule. Keep subscription contents unchanged during testing so changes to the server list do not affect your comparison.
- Configuration rules: If Global Routing is set to Config, check that the current configuration suits your needs.
DOMAIN-SUFFIXmatches domain suffixes,IP-CIDRmatches IP ranges,GEOIPmatches based on an IP address’s geographic location, andFINALis the fallback policy. These rules do not replace On Demand connection triggers. - Diagnostic activity: Repeated latency tests, speed tests, and detailed logging add to the workload during diagnosis. Once you have identified the issue, stop running tests repeatedly and check battery usage again under normal conditions.
- Protocol choice: Do not rank Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard in a fixed battery-efficiency order. Packet loss, server settings, actual traffic, and device conditions can all change the results. First make sure your existing protocol connection is stable.
Bottom line: Keep On Demand if it provides a stable connection
If manual connections are stable but On Demand causes repeated reconnections, first correct the network-matching conditions. If both methods fail, check the network and configuration first. After fixing the issue, repeat the test under the same conditions before deciding whether to keep automatic connections enabled.
7. Checklist before restoring your everyday settings
When troubleshooting is complete, restore the connections and update schedule you need, and keep a brief record of the network type, current Global Routing setting, whether On Demand is enabled, observation times, and major errors. This information is more useful for further diagnosis than a screenshot showing only battery percentages. Before sharing logs, remove subscription URLs, passwords, tokens, and other personal information.
- Check the actual connection status in Home, not just whether the main app is in the foreground.
- In Config, confirm which configuration is in use; in Home, check Global Routing. Do not compare results from tests using different routing policies.
- Review the Wi-Fi and cellular conditions in Settings → On Demand, then test both joining and leaving Wi-Fi.
- Return to the system Battery screen and check whether total drain matches your actual workload. If the issue persists, investigate the network, configuration, and traffic sources in turn.
Shadowrocket is a closed-source commercial app for Apple platforms, primarily used on iPhone and iPad. The App Store is the only place to get it. A one-time app purchase does not include a service plan; this guide assumes you already have your own provider and configuration. Check the App Store listing for device compatibility, system requirements, and general purchase information.