Shadowrocket’s On Demand feature triggers VPN connections based on conditions; it is not a battery-saving switch. Start troubleshooting by matching the iOS battery report to the time of the issue, then distinguish ongoing traffic from network changes and connection retries. This guide is for users with their own service and subscription who want to investigate background battery use. It explains the trade-offs and a single-variable test without assuming any one setting will save power.
1. Check iOS Battery Usage—Don’t Judge by Percentage Alone
On your iPhone or iPad, open Battery in Settings, select the date and time when the issue occurred, and review app battery usage, screen activity, and background activity. The location and labels may vary by iOS version; follow what appears on your device. Note the starting and ending battery levels, whether the device was charging, and whether it was connected to Wi-Fi or cellular.
The percentages in the Battery list usually show each app’s share of usage during the selected period; they don’t represent the same percentage-point drop in the device’s battery level. For example, if the battery level drops by 10 percentage points and an app accounts for 20% of usage, that does not mean the app caused a 20-point drop. Background activity time also doesn’t mean the processor was running at full load the whole time.
- Match the time period: Select the hours when the battery drained unusually fast. Don’t use an all-day report to explain a network issue that lasted only a few minutes.
- Check what was happening: Note activities such as photo syncing, file transfers, and video playback. When traffic is handled by the VPN network extension, an app’s usage share alone may not identify which app originally initiated the request.
- Rule out obvious factors: Note weak signal, device heat, charging, and system background tasks; each can affect total battery usage.
- Record a baseline: Before changing anything, note the connection status in Home, the selected Global Routing option, and the Settings → On Demand configuration.
2. When On Demand Triggers and What Happens in the Background
Go to Shadowrocket’s Settings → On Demand and check the main switch and the network conditions available in the current interface. On Demand hands connection rules to the system, which can initiate a VPN connection when the network conditions, rule actions, and system connection checks are met. Turning it on doesn’t mean the VPN disconnects as soon as the screen locks, nor does it mean a new tunnel is created for every network request.
Switching from Wi-Fi to cellular or reconnecting to a wireless network may prompt the system to reevaluate the rules; whether a connection starts depends on the configuration and network state. An existing connection may also recover or be re-established after a network change, so not every reconnection is caused by On Demand. Investigate server unavailability, authentication errors, and an unstable underlying network separately.
- When enabled: A connection can start automatically when the rules match, reducing manual steps. Repeated attempts to reach an unavailable destination may cause additional activity.
- When disabled: The On Demand trigger mechanism is no longer used. This doesn’t necessarily disconnect the current VPN immediately or prevent other apps from making background requests.
- To pause the connection: Turn off On Demand first, then return to Home and switch off the connection. Confirm the actual VPN status in iOS. If you only turn off the switch in Home, a matching On Demand rule may start the connection again.
Don’t make force-quitting Shadowrocket from the app switcher your routine way to disconnect. The app interface and the VPN network extension managed by iOS have separate lifecycles; closing the interface doesn’t replace checking the connection switch and On Demand rules.
3. Choosing Settings for Wi-Fi and Cellular
Base your choice on how you use the connection and how stable the network is—not on rules like “always on for Wi-Fi, always off for cellular.” A low-traffic connection on stable home Wi-Fi has different battery demands from one that repeatedly reconnects while switching between cellular towers on the move. Stabilize the connection first, then decide whether automatic triggering is useful.
| Scenario | Suggested starting point | What to check |
|---|---|---|
| Stable, fixed Wi-Fi | Keep On Demand enabled if you need a persistent connection | Check for heavy syncing while the screen is locked and recurring connection errors |
| Weak cellular signal | Temporarily disable automatic triggering and compare with manual connections | First check whether battery drain coincides with weak signal and connection retries |
| Frequent switching between Wi-Fi and cellular | Test on one stable network first, then repeat while switching networks | Check whether errors cluster around network changes rather than occurring during a stable connection |
| Connection needed only briefly | Turn off On Demand and manage connections manually from Home | After use, confirm the connection is disconnected and check whether later tasks still need it |
| Public Wi-Fi that requires sign-in | Sign in to the network before testing the VPN | Check whether the underlying network is reachable and sign-in is complete |
Takeaway: Test on a stable network first, then decide whether to keep automatic triggering enabled
If the connection is stable on fixed Wi-Fi but battery drain and errors appear only when networks change, investigate the handoff and network reachability first. Don’t change the protocol, rules, and On Demand settings at the same time, or you won’t know which change helped.
If the interface offers conditions for network types or SSIDs, configure and test them individually as needed. Don’t assume every iOS version or interface provides the same options. Disabling a network condition changes only its trigger logic; it does not automatically route all requests on that network through DIRECT.
4. Stop Repeated Failures When Connection Errors Occur
When the issue occurs, check the connection log for the time, destination, and error details. The phrases below are standard errors that may appear in network logs, not fixed alerts guaranteed to show every time; the exact wording may include system or protocol context. A single error doesn’t prove abnormal battery drain. Look for repeated errors clustered in time with the battery drop before drawing a connection.
Error: Connection refused
Cause and fix: The destination port may not be listening, or the connection may have been explicitly rejected. Check the address and port of your existing server and ask your service provider to confirm its status. Repeatedly toggling the connection in Home is no substitute for checking.
Error: Operation timed out
Cause and fix: The connection or read/write operation didn’t complete in time. The cause may be an unreachable link, packet loss, or an unresponsive destination. Retest the same server on stable Wi-Fi, then compare it with cellular results. A timeout alone doesn’t mean the authentication details are wrong.
- Note when each error occurs and whether it follows a Wi-Fi disconnection or a switch to cellular.
- Check which server is selected in Home, then use Connectivity Test to check whether it is reachable at that time. A single successful test doesn’t prove the connection is stable in the background.
- If the same error keeps recurring, temporarily turn off On Demand and disconnect. Test again after the network or server issue is resolved.
- Update your own subscription only if the address, port, or authentication details have actually changed. Afterward, check the selected server again; repeatedly refreshing a subscription is not a general battery-saving measure.
The protocol can also guide troubleshooting. Hysteria2 is based on QUIC and uses UDP; if the current network restricts UDP, check whether the protocol is reachable. Don’t assume another protocol will use less power on every device and network just because it uses TCP. Use the server port in your existing configuration; don’t change it to 443 at random to troubleshoot connection problems.
5. What Global Routing and On Demand Control
On Demand triggers connections based on conditions; Global Routing determines how traffic is handled while connected. They are separate controls. Choose Proxy, Direct, Config, or Scene under Home → Global Routing for your current needs. Scene’s behavior depends on its configuration, so it isn’t a fixed battery-saving mode.
- Proxy: Uses proxy routing; it doesn’t automatically reduce the number of requests.
- Direct: Uses direct routing, but switching to Direct does not turn off the VPN network extension.
- Config: Routes traffic according to the current configuration. Check what is enabled in Config rather than looking only at the servers in your subscription.
- Scene: Check the scene’s contents and activation conditions before assessing traffic routing. Avoid automatic scene changes during testing, as they introduce another variable.
In Config, DOMAIN-SUFFIX matches domain suffixes, IP-CIDR matches address ranges, and GEOIP matches against an IP geolocation database. FINAL handles requests that did not match earlier rules. DIRECT, PROXY, and REJECT are policy outcomes, not battery modes. Rule order affects the result; don’t change rules your workflow depends on just to lower the percentage in the Battery list.
6. Test One Variable at a Time to Confirm an Improvement
The following is a suggested test log, not a measured battery-life result. Run two observation periods in the same location, on the same network, and at a similar battery level. Keep the selected server, Global Routing, screen state, and background tasks consistent; change only On Demand. Before each period, establish the same connection state in Home so you don’t confuse the effect of being connected with the effect of automatic triggering.
- Test 1: Enable On Demand, connect, then lock the screen. Record the starting and ending battery levels, network changes, and error times.
- Test 2: Disable On Demand and connect manually under the same conditions. If the connection drops during the test, record it and note that the two runs no longer have matching conditions.
- Additional scenario: If you want to compare “stay connected automatically” with “disconnect manually after use,” run a separate test and note that connection duration also changed.
- Review: Compare the iOS Battery page with the connection log. If the short-term difference is only one or two percentage points, extend the observation period and repeat the test before drawing a conclusion.
Conclusion: Keep settings you can explain and reproduce
If you need a persistent connection and the network is stable, you can keep On Demand enabled. For occasional use at set times, connect manually. If battery drain continues after disabling it, investigate ongoing traffic, weak signal, and connection errors rather than repeatedly toggling On Demand.
After the issue is resolved, restore your usual settings one at a time and confirm the actual connection status after each change. When contacting your service provider, include the time of the issue, network type, and error details with sensitive information removed. Don’t share subscription URLs, authentication details, or full connection credentials publicly. See this site’s tutorials and rule guides for more on connections and routing.