Shadowrocket maintaining a VPN tunnel in the background does not mean it is continuously transferring data at high speeds. This guide is for users who already have their own service provider and subscription and want to investigate standby battery drain. First, understand the system battery statistics; then distinguish automatic On Demand connections from manually maintaining a connection; finally, compare them over fixed time intervals to choose the right connection settings for Wi-Fi and cellular.
Read battery statistics first: usage share is not percentage points of battery drain
On your iPhone or iPad, open Battery in Settings, review the available usage periods, and select the time range where you suspect unusually high battery use. The system interface may vary by OS version. Record four things: the battery level change during that period, screen activity, Shadowrocket’s share of usage, and whether background activity appears. Don’t compare a full day’s usage percentages directly with a 10-minute connection test.
The app battery percentage shown on the Battery screen usually represents its share of the energy used during the selected period, not the amount of battery capacity the app used on its own. For example, if your device drops from 80% to 70% and an app shows 20%, that does not mean the app drained 20 percentage points. The VPN network extension also handles traffic for other apps, and system attribution does not mean work occurs only while Shadowrocket is open.
These times and battery levels illustrate a test method; they are not a battery-life guarantee. If the selected period includes video playback, photo syncing, app updates, or a commute with weak signal, choose a more stable time instead. Extended background activity only shows that related tasks continued; by itself, it does not prove high, continuous power use.
On Demand controls connection conditions; it is not an idle disconnect timer
Open Settings → On Demand in Shadowrocket and check your current On Demand settings. On Demand uses the system’s on-demand connection mechanism to establish or resume a connection when configured network conditions are met and relevant network activity occurs. It does not mean “connect only when I open the app,” nor can it be reduced to “disconnect immediately when there’s no traffic.” Available options and how rules are displayed depend on the current interface.
Here, “manually maintained” means turning off automatic On Demand triggers, then manually enabling the connection from Home and leaving it on. It does not mean keeping the app open in the foreground. While the tunnel is connected, actual data transfer depends on app requests, protocol behavior, and connection maintenance. The VPN indicator in the status bar is not a real-time power meter.
- Automatic connection: Makes it less likely you’ll forget to connect, but background app requests may also trigger a connection when conditions are met.
- Manually maintained connection: Makes it easier to observe the connection continuously, but does not eliminate the costs of background syncing, weak signal, or repeated retries.
- Manual disconnect: Useful when you know you don’t need the tunnel. If On Demand is still enabled, the connection may resume when conditions are met, so check your On Demand settings first.
Wi-Fi and cellular: choose where you need a connection before assessing battery life
Wi-Fi is not automatically stable, and cellular does not necessarily use more power than every Wi-Fi setup. Being too far from an access point, needing extra network authentication, a weak cellular signal, or frequent movement between cell sites can all increase connection attempts and retries. To compare On Demand with a continuously maintained connection, keep the network environment as consistent as possible; otherwise, differences may come from the wireless connection itself.
| Use case | Connection options | What to check |
|---|---|---|
| At a fixed location with stable Wi-Fi | Enable On Demand for Wi-Fi, or maintain the connection manually | Whether apps work after the screen locks and whether the connection keeps rebuilding |
| Occasional cellular use | If automatic connections aren’t needed, leave cellular triggers unconfigured and connect manually when needed | While disconnected, traffic is no longer handled by this tunnel |
| Frequent cellular use | Enable automatic connections for cellular, or maintain the connection manually | Signal stability, recovery after switching networks, and whether app requests succeed |
| Frequent switching between Wi-Fi and cellular | Start by comparing one connection method at a time | Whether network switches coincide with error logs, heat, or faster battery drain |
Takeaway: limit automatic connections to the networks you need
If you need automatic connections only on a fixed Wi-Fi network, first check the corresponding network conditions in Settings → On Demand; keep cellular under manual control. If your work requires the tunnel on both network types, keep the relevant connection conditions enabled and investigate retries first. Don’t disable the connection just to lower its share on the Battery screen.
Keep the same Config: don’t mistake routing changes for battery savings
On Demand controls when to connect; Global Routing controls how traffic is handled after connection. They are separate settings. Before testing, check Global Routing on Home and note whether it is set to Proxy, Direct, Config, or Scene. If you use Scene, also check the settings applied by that scene. Don’t change scenes while switching On Demand settings.
When using Config, check the rule order and target policies in your current configuration. DOMAIN-SUFFIX matches domain suffixes, IP-CIDR matches address ranges, GEOIP checks an IP address against a geographic database, and FINAL provides a final fallback. These are routing conditions, not battery-saving switches. Direct does not turn off the VPN tunnel; changing traffic to a direct connection is no substitute for testing the connection state.
- On Home, note the selected server and Global Routing setting, then open Config and confirm which configuration is active.
- Use the same rule order and target policies in both rounds; don’t temporarily change FINAL from a proxy policy to DIRECT.
- During the test, don’t run latency tests in bulk or manually refresh an existing subscription; these add extra requests to the observation period.
- If you need to update an existing subscription, do so first and confirm the server settings before starting a new comparison.
Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard differ in how they transmit data and maintain connections, but protocol names alone don’t establish a fixed battery-use ranking. Server location, packet loss, app traffic, and actual settings all affect the result. For an initial investigation, keep your existing configuration and don’t switch protocols at the same time.
Address repeated retries first: connection errors are not a battery setting problem
If the device gets hot while locked but apps won’t load, first check whether repeated connection failures occurred during that period. The examples below are error snippets that may appear in network logs; the full wording can vary by version. Act on a particular cause only if it appears in your logs. Don’t deliberately create errors as part of troubleshooting.
Error: connection refused
Cause and fix: The destination or an intermediate device is refusing the connection, often because the port does not have the expected service. Check the address and port provided by your service provider, confirm that the service is available, then test the connection once. Avoid repeatedly running bulk tests.
Error: i/o timeout
Cause and fix: A network read or write did not complete before the timeout. The link may be unreachable, packets may be lost, or the remote endpoint may not be responding. First retest the same configuration on stable Wi-Fi, then check whether the failure occurs only on cellular. Don’t assume On Demand itself is causing battery drain.
For example, if your existing configuration specifies port 443 for a TLS server, verify it against the actual settings from your service provider instead of changing it to another commonly used port just because a timeout occurred. If only the first request fails when switching from Wi-Fi to cellular, record when the switch happened, the error snippet, and whether the connection recovered afterward. If failures continue on both networks, resolve reachability first, then compare battery use.
- Check that the date and time on your iPhone or iPad are accurate, as incorrect settings can affect encrypted connection checks.
- Make sure the protocol settings match your existing subscription; don’t disable certificate verification just to clear an error.
- When contacting your service provider, include the error time and relevant error snippet. Redact subscription links, passwords, tokens, and personal information.
Compare two rounds with the same network, screen, and background activity
Start with a basic test on stable Wi-Fi, then test cellular separately. Battery readings are rounded, so a one-point drop over a short period does not prove one method is more efficient. If the difference between rounds is small, repeat them in the opposite order rather than claiming a percentage saving.
- Before you start: Record the start time, battery level, network name, signal strength, server, and Config. Keep the ambient temperature similar, and don’t compare while charging.
- Round A: Turn off automatic On Demand triggers and manually connect from Home. Confirm that the same test page loads, then lock the screen and wait 30 minutes.
- Round B: Enable the network conditions you’re testing in Settings → On Demand and confirm that the connection behaves as expected. Open the same page, then lock the screen and wait 30 minutes.
- Keep conditions consistent: Don’t play media, actively sync large files, or run speed tests in either round. Keep background activity from other apps as similar as possible.
- Record: Note the ending battery level, whether the device got warm, any network switches, and any failed retries. Then check the corresponding period in the system Battery settings.
- Repeat: Choose similar conditions and run the rounds again in reverse order, with Round B before Round A. If the results point in different directions, don’t attribute the difference to the connection method yet.
Keep two questions separate: The A/B test above compares two ways of managing the connection. To compare “tunnel enabled” with “fully disconnected,” run a separate test: turn off On Demand first, then disconnect from Home. Traffic takes a different path in this test, so it is not the same usage condition as the first two rounds.
Practical settings and a safe rollback order
There is no single battery-saving setup that works for every device. If the connection works normally on a stable network and the device stays at a normal temperature while locked, a high position for Shadowrocket in the Battery list alone is no reason to change protocols or configurations. Choose settings based on whether you need automatic connections, then repeat the test to confirm the effect on your device.
- Mostly on fixed Wi-Fi: Keep your existing routing in Config and set On Demand conditions for Wi-Fi as needed. Decide separately whether to connect automatically on cellular.
- Tunnel needed all day: Keep automatic connection conditions enabled for the relevant networks, or maintain the connection manually. Focus on recovery after network switches and repeated errors rather than disconnecting frequently.
- Occasional use: Turn off automatic triggers you don’t need, connect manually from Home when needed, and disconnect manually afterward. Also consider how traffic should be handled while disconnected.
- Unusual battery drain: First rule out heavy background traffic and weak signal, then check logs and settings, and only then adjust connection options one at a time. Save the original settings so you can revert.
Takeaway: keep automatic connections limited to what your work requires
If repeated tests show no consistent difference between On Demand and maintaining the connection, choose based on whether you need automatic reconnection. If one method repeatedly coincides with failures and heat, fix the relevant network or settings issue and test again. Fewer background entries alone do not mean the problem is solved.