A high share of battery usage attributed to Shadowrocket in the battery list does not prove that the tunnel is under continuous heavy load. First check the reporting period, overall battery loss, and background traffic, then compare always-on and On Demand connections on the same network and for the same duration. This guide is for users seeing standby drain, long background activity, or repeated reconnects after switching networks. The goal is to distinguish actual data transfer from connection retries and trigger conditions—not simply to lower the number shown in the battery list.
Check battery usage before deciding whether it’s unusual
On your iPhone, open Settings → Battery, choose one of the available dates or time ranges, and review app usage and activity for that period. Battery menus and reporting can vary by iOS version, so use the options shown on your device. After tapping a period in the chart, make sure the list below has switched to the same range; otherwise, you may be comparing a full day’s usage with one hour of activity.
The percentage beside an app shows its share of battery usage within the selected period. It does not mean the app used that many percentage points of battery on its own. For example, if the battery drops from 80% to 70% during an unplugged observation period, a 30% share in the list does not mean “the app drained 30 percentage points.” Battery estimates and usage attribution are not precision measurements, so they cannot provide an exact power-consumption figure.
“Background Activity” means work occurred while the app wasn’t in the foreground. It does not mean the processor stayed at full load with the screen off. Shadowrocket uses the system network extension to handle tunnel traffic; requests from other apps may still pass through the tunnel even when you’re not viewing Home. To assess unusual drain, compare overall battery loss, heat, and connection stability under the same conditions. Don’t draw conclusions from the app’s position in the list alone.
What contributes to power use with an always-on connection
Keeping the connection switch on and continuously transferring large amounts of data are not the same thing. Once the tunnel is established, its workload depends on traffic volume, rule processing, encryption, connection maintenance, and network quality. Video streaming, photo syncing, and file transfers add workload. On weak signals, retransmissions and repeated reconnects may also increase the demands on both cellular communication and tunnel processing.
Global Routing in Home determines how requests are routed; it is not a battery-saving mode. Proxy, Direct, Config, and Scene can’t be ranked from “most” to “least” power-hungry: Config depends on its rules, and the outcome for Scene depends on how it’s set up. Actual power use also depends on outbound traffic and network conditions. Direct does not mean the system tunnel is off.
- Heavy data transfer: Pause known background syncs or downloads, then compare overall battery loss. Simply switching away from the app won’t stop requests from other apps.
- Connection maintenance: Some protocols and connection configurations use keep-alive mechanisms. The interval depends on the actual configuration; there is no single interval that applies to every connection.
- Unstable network: If the device heats up while requests are timing out, check signal strength, network switching, and server reachability first. Avoid adding more automation conditions as a first step.
Run a comparison before setting up On Demand
On Demand is a system mechanism that connects the VPN when specified conditions are met. It does not mean “stop working when the screen turns off.” If the conditions are true most of the time, its behavior may be similar to an always-on connection; if they change frequently, it may repeatedly establish the tunnel. First identify which networks actually need a connection, then check the existing setup under Settings → On Demand.
-
Record a baseline
Choose a repeatable observation period, such as 60 minutes with the screen locked on the same Wi-Fi network. Record the starting and ending battery levels, whether the device is charging, the network type, and any known background tasks. The 60 minutes is a test duration, not a product power-use benchmark.
-
Check the current setup
In Home, note the current connection status and Global Routing. In Config, note the active configuration, then record the trigger conditions under Settings → On Demand. During testing, don’t change the server, rules, and routing mode at the same time.
-
Narrow the trigger conditions
Configure On Demand using the network conditions available on the page. If you need to distinguish Wi-Fi networks, check the SSID character by character and confirm whether the condition applies to connecting or disconnecting. Different bands at the same location may use different network names.
-
Test network switching
In a controlled setting, check the connection on the target Wi-Fi network and on cellular separately. If automatic triggers are enabled, manually turning the connection off may cause it to reconnect. Check which condition was met before assuming the switch isn’t working.
-
Retest and keep a record
Repeat the test for the same duration and record overall battery loss and whether connectivity behaves as expected. Test a disconnected state only when doing so won’t interrupt essential network tasks. Repeat several times before deciding which approach to keep.
Choose a connection method for your everyday use
There is no “most battery-efficient setup” that works for every device. An always-on connection avoids waiting for the tunnel to connect before use. On Demand is better suited to situations where connection needs have clear boundaries based on network conditions. Choose based on whether your use is continuous, how stable the network is, and whether missing a trigger could interrupt an essential task.
| Use case | Try first | What to check |
|---|---|---|
| Continuous use on the same stable network | Always-on connection | Whether there is ongoing background traffic or repeated timeouts |
| Tunnel needed only on specific networks | On Demand | Whether the SSID and connection action match correctly |
| Frequent network switching during a commute | Simplify the conditions before comparing | Whether connections are repeatedly established within a short period and whether cellular signal is stable |
| Background tasks needed while the screen is locked overnight | Verify the task before deciding | Whether background tasks complete and whether standby battery loss is repeatable |
If you already have a service provider and subscription, keep the connection you use fixed during testing so that server-side changes aren’t mistaken for an On Demand effect. Protocol names alone don’t indicate battery use: how Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard perform depends on configuration, network conditions, and workload. There is no universal ranking independent of those factors.
Rule out retries when connections time out or keep reconnecting
If battery drain increases while requests are failing, resolve the connection issue before comparing connection methods. The following are error messages that may appear in network logs. Troubleshoot them only if the corresponding text appears in your logs; these are not guaranteed prompts in every version. Don’t use an error message to estimate power use.
Error: Operation timed out
Cause: The connection or operation did not complete within the allotted time. Possible causes include an unreachable network, packet loss, or an unresponsive server.
Fix: First check the current network and whether your existing service is available, then retry once using the same connection. If it keeps failing, stop repeated tests and check the service status with your provider.
Error: Connection refused
Cause: The connection request was refused, commonly because no service is listening on the target port or an access policy is blocking it.
Fix: In Home, check that the address and Port for the selected connection match the information from your provider. Don’t change every port to 443 based on assumption.
Check rule behavior separately. In Config, first confirm that specific rules appear before broader ones, then check which policy FINAL selects. The example below shows rule syntax for testing a domain with a direct connection; it is not a complete configuration or a universal battery-saving solution. Don’t route all requests through DIRECT just to lower the percentage in the battery list.
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,PROXYThese two lines route example.com and its subdomains through DIRECT, while requests not matched by earlier rules go to PROXY. Before using them, check how policies are defined in your configuration. DOMAIN-SUFFIX, GEOIP, and IP-CIDR match different types of target information; On Demand controls when a connection is established. They solve different problems.
Common questions about background battery drain
Does long background activity mean the app is constantly using power?
Background duration does not mean continuous high power use. In Settings → Battery, select the same time range and compare overall battery loss with screen activity. Syncs or messaging connections may still run through the tunnel while the screen is locked. Use repeated comparisons rather than drawing conclusions from one activity-duration figure.
Will swiping Shadowrocket away from the app switcher save battery?
Swiping an app away does not confirm that the system VPN has disconnected. Check the connection status in Home and review Settings → On Demand for automatic reconnect conditions. When testing a disconnected state, make sure those conditions won’t immediately establish the connection again.
What if battery drain gets worse after enabling On Demand?
First check whether it mainly happens while switching between Wi-Fi and cellular, then look for overly broad or conflicting conditions in Settings → On Demand. Change one condition at a time, keeping the connection and test duration the same. If the conditions are always met, On Demand won’t automatically create a meaningful idle period.
Does changing Global Routing to Direct disconnect the VPN?
No. Direct determines how requests are routed; the connection switch and On Demand determine whether the tunnel is established. To compare connected and disconnected states, check the actual VPN status. Changing Global Routing alone is not enough to compare battery figures.
Should I update my subscription every day to fix battery drain?
Updating a subscription syncs connection details supplied by your existing provider; it is not a battery maintenance step. An update may indirectly fix connection failures only if the address, port, or service information has changed. Check the cause of the failure first. Avoid repeatedly refreshing on a network that isn’t working, and don’t change multiple settings at once.
Keep the option that meets all three conditions: essential tasks work, network switching behaves as expected, and overall battery loss is acceptable in the same scenario. If the two approaches make little difference, prefer the setup that’s easier to understand and verify. If the problem returns, use the same method to record results, check for changes in traffic and network conditions, and then adjust On Demand.