Distinguish battery usage percentage from actual device drain and network reconnects before deciding whether to enable On Demand. This guide is for iPhone and iPad users who already have their own configuration and are seeing high background usage for Shadowrocket. Start by recording observations under consistent conditions, check connection stability, then choose between a stable always-on connection, condition-based triggers, or connecting manually. On Demand lets the system establish a connection based on conditions; it is not a fixed battery-saving switch.
Read battery usage without mistaking percentages for actual drain
Sending Shadowrocket to the background does not mean the system VPN tunnel has disconnected. The tunnel may still handle requests from other apps, so background activity on the Battery page is not, by itself, evidence of a problem. To decide whether to investigate, consider overall battery drain, screen usage, actual network activity, and whether the issue recurs under the same conditions.
Open Battery in iOS Settings, select an available date or time range, then review Shadowrocket’s usage and activity. Chart labels and available ranges can vary by iOS version; refer to what your device displays. The app’s battery usage percentage shows its share of usage within the selected range. It does not mean the app directly used the same percentage of your battery capacity.
-
Choose a time period
In Settings → Battery, select the period when the issue occurred. Check whether video playback, photo syncing, a system update, or Personal Hotspot use was also happening. This helps avoid attributing the device’s overall workload to a single app.
-
Record the conditions
Note the starting and ending battery levels, observation period, whether the screen was on, Wi-Fi or cellular network, whether the device was charging, and the connection status in Home. Start with a 60-minute observation window for easier comparison; this is a useful interval, not a battery-drain threshold.
-
Check activity
Review background activity for the selected period and consider whether other apps were transferring data continuously. Background activity time cannot be directly converted into time at full CPU load or additional battery drain.
-
Repeat the observation
Repeat the test in the same location, with similar signal strength and the same screen conditions. Do not compare one observation while charging with another in a weak-signal area to decide which connection setting uses less power.
Always-on connections and repeated reconnects use power in different ways
A stable always-on connection may use power for tunnel processing, encryption, and protocol maintenance, but a long connection duration does not mean large amounts of data are constantly being transferred. By contrast, repeatedly disconnecting and reconnecting may repeat DNS lookups, transport connection setup, authentication, and application request retries. On weak cellular signals or frequently changing networks, this activity can add to the power used by the wireless connection itself.
This sequence illustrates one observable pattern: a device works normally on a fixed Wi-Fi network, becomes briefly unavailable after leaving its coverage area, then apps retry requests in bursts once the connection returns. If log timestamps line up with network changes, check connection stability before switching protocols or adding automatic trigger rules. The VPN icon in the status bar alone cannot tell you whether this cycle occurred.
- Stable and idle: The screen is off, there are few requests, and the connection status does not keep changing. Compare with a manual disconnect under the same workload before drawing conclusions from connection duration.
- Ongoing transfers: Video, backups, or file syncing pass through the tunnel, so processing varies with actual traffic. Pause transfers and observe the idle state to distinguish workload from connection maintenance.
- Repeated failures: Connections fail, apps retry, or connections are established repeatedly over a short period. First check the server address, port, authentication fields, and network reachability in your existing configuration.
- Frequent network switching: The device repeatedly switches between the edge of Wi-Fi coverage and cellular service. Retest on one stable network before deciding whether On Demand conditions are involved.
On Demand controls when connections start, not how traffic is routed
In Shadowrocket, go to Settings → On Demand and review the current toggle and rules. On Demand lets the system determine connection behavior based on configured conditions. It does not mean “disconnect as soon as the screen turns off” or “connect only when Shadowrocket is open.” Network requests from background apps may also keep a connection active when its conditions are met. Verify the behavior against your rules and the system’s current state.
Connection triggers and traffic routing are separate settings. In Home → Global Routing, Proxy, Direct, Config, and Scene determine the routing mode. Settings → On Demand controls the conditions for connecting on demand. Choosing Direct does not turn off the system VPN tunnel, and choosing Config does not mean the tunnel is established only when a proxy rule matches. Keep these two sets of variables separate when testing battery use.
| Settings area | What it controls | How to handle it during troubleshooting |
|---|---|---|
| Home connection toggle | Manually starts or stops the current connection. | Use this to establish a manual connection baseline. If you need to stay disconnected, check On Demand first. |
| Settings → On Demand | Lets the system trigger connection behavior based on configured conditions. | Start by testing one clearly defined condition, then add conditions one at a time. |
| Home → Global Routing | Selects Proxy, Direct, Config, or Scene. | Keep the same mode during comparison tests; do not change routing at the same time. |
| Config | Manages configuration files and their routing rules. | Confirm that you are using the intended configuration to avoid unexpected high-volume traffic going through a proxy. |
For example, DOMAIN-SUFFIX,example.com,DIRECT in Config is a domain routing rule, not an On Demand connection trigger. Changing traffic to DIRECT may leave the tunnel active. To test whether disconnecting improves battery life, control On Demand and actually stop the connection rather than simply switching to Direct.
Compare three connection modes by changing one variable at a time
Make sure your existing configuration connects successfully before comparing battery use. Do not refresh subscriptions, change servers, edit DNS, switch protocols, and adjust On Demand all at once during a test. If battery behavior changes, you will not know which factor caused it. Pause manual batch speed tests during the observation period; speed tests themselves generate connections and network traffic.
-
Save the current settings
Record the current configuration in Home, the Global Routing mode, and the existing settings under Settings → On Demand. Keep records limited to information needed locally; do not include complete subscription URLs or authentication fields in public troubleshooting notes.
-
Observe with the connection off
Turn off On Demand, then stop the connection in Home. Under the same light workload that does not depend on the connection, record battery use for 60 minutes and confirm that it did not reconnect automatically. Skip this test and note why if disconnecting would interrupt an essential task.
-
Observe with an always-on connection
Leave On Demand off and manually connect the existing configuration in Home. Use the same network and a similar workload for the same amount of time, recording the overall battery change and whether the connection reconnects.
-
Observe On Demand
Go to Settings → On Demand and enable the condition you want to test. Record whether the condition actually triggers, whether the connection is repeatedly established, and whether background app requests continue when you are not using apps in the foreground.
-
Recheck the differences
Repeat any test that shows a clear difference. Battery readings are rounded, so a small short-term change is not enough to prove one setting is better. Also check for heat, weak signal, or system background tasks.
If the always-on test is stable but the On Demand test repeatedly reconnects, simplify the trigger conditions first. If both tests repeatedly fail on the same network, investigate the network and existing configuration. If battery drain is similar even with the connection off, check other app activity on the system Battery page, signal strength, and device conditions rather than focusing only on Shadowrocket.
Troubleshoot connection issues before looking for ways to save power
Review the connection records or logs available for your configuration. Look for when failures occurred, the destination address, and whether the same failure recurs. The examples below are raw error snippets that may appear in network logs; investigate along the corresponding lines only if the actual log contains that text. Wording can vary by protocol and log detail, and the absence of a particular error does not guarantee that the network is working normally.
Error: connection refused
Cause and fix: The destination actively refused the connection, often because no service is listening on the port or access was denied. Check that the server address and port in your own configuration match, and ask your existing service provider to confirm the service status. Do not repeatedly toggle On Demand to retry.
Error: i/o timeout
Cause and fix: A network read or write operation exceeded its wait time. This message alone does not identify the server as the cause. Test the same configuration on stable Wi-Fi and cellular networks, compare when failures occur, then check address resolution, network reachability, and the status of the existing service.
If errors cluster around switching between Wi-Fi and cellular, test on a fixed network first. If failures continue on a fixed network, check the configuration fields. The port must match your existing configuration; do not change it to 443 just because that port is common. A shorter connection interval will not fix mismatched authentication or transport parameters.
- Match events by time: Compare failure timestamps with the battery chart and when the device left Wi-Fi coverage. Do not infer battery use for an entire period from a single historical log entry.
- Separate updates from connections: A failed subscription update means the configuration list could not be retrieved; it does not necessarily mean the currently saved connection is broken. Check refresh history and actual connection behavior separately.
- Reduce test activity: Once you have identified the issue, stop continuous speed tests and any detailed diagnostics you no longer need. This keeps diagnostic activity out of later comparisons of everyday battery use.
- Protect your configuration: When reporting an issue, include the error text and timestamp, but redact complete subscription URLs, authentication fields, and server details that do not need to be public.
Choose based on how you use it, and keep results you can verify
If you need a continuous connection and your network is stable, you can keep a stable always-on connection and focus on background data use and unexpected reconnects. If you only need a connection under specific network conditions or for particular tasks, test On Demand and verify that its conditions actually narrow when the connection is active. If you use it infrequently and can manage it yourself, manual connections may make the status easier to confirm. None of these is a universal battery-saving solution.
Why does the Battery page still show background activity after I close the main screen?
The main screen and the system VPN tunnel do not share the same lifecycle. Return to Home to check the connection status, then review Settings → On Demand. Closing the app screen does not stop the connection. For a disconnect comparison, turn off On Demand first, then stop the connection.
Will enabling On Demand always reduce battery drain?
Not necessarily. If the conditions remain true for a long time or background requests continue, the connection may stay active. Unstable condition boundaries can also lead to repeated connections. Record always-on and On Demand behavior on the same network, then decide based on reconnect frequency and overall battery drain.
Should I disconnect my phone overnight when I’m not using it?
First check whether overnight syncing or other tasks depend on the connection. If not, turn off On Demand and stop the connection in Home, then record the battery level at the start and end of the night. Keep charging, network, and sync conditions the same for the comparison night.
Does cellular use more power because I chose the wrong protocol?
First rule out weak signal, movement, and repeated network switching. From a fixed location, observe Wi-Fi and cellular using the same existing configuration. Compare protocol settings only when network conditions and workload are similar; do not rank power use by protocol name alone.
Keep a conclusion you can reproduce: note the network, which existing configuration you used, the Global Routing mode, whether On Demand was enabled, and overall battery drain and reconnect behavior over the same period. Fix connection failures and repeated retries first, then choose a trigger method. Do not use a one-time battery ranking in place of a complete observation.