To troubleshoot Shadowrocket battery drain, compare overall battery loss under the same conditions, then check background activity and connection logs. Don’t rely on the percentage in the Battery list alone. This guide is for users who already have their own provider, subscription, and working configuration. It walks through establishing a baseline, distinguishing an always-on tunnel from ongoing data transfer, testing On Demand, and choosing a connection mode based on how you use it.
1. Check overall battery loss before interpreting app percentages
On your iPhone or iPad, open Settings → Battery, select the time range that overlaps with the issue, and review Shadowrocket’s battery usage and activity. Time ranges and detail labels vary by system version, so refer to what your device shows. An app’s percentage in the Battery list is its share of attributed usage during the selected period—not the same percentage of battery capacity directly consumed by that app.
For example, a “30%” reading does not mean “Shadowrocket used 30 percentage points of my battery.” If overall usage was low during that period, a background activity may still account for a large share. By contrast, substantial overall battery loss, a warm device, and sustained background activity warrant a closer look at network requests, signal quality, and reconnections. The VPN icon alone does not prove that large amounts of data are being transferred.
-
Match the time range
Open Settings → Battery, select the period when the issue occurred, and note the starting and ending battery levels, screen activity, and whether the device was charging. Don’t compare daytime navigation with overnight standby.
-
Note the connection settings
Return to Shadowrocket’s Home screen and note the connection toggle, the currently selected node you already have, and the Global Routing setting. Then open Config and confirm which configuration is active.
-
Check what triggers the connection
In Shadowrocket, open Settings → On Demand. Note whether On Demand is enabled and which network conditions the existing rules use. Record the original settings before making changes for comparison.
-
Establish a baseline
Choose a period when the device is unplugged and the signal is stable. Note the screen brightness, Wi-Fi or cellular connection, main task, and starting battery level. Use the same observation period each time—for example, 60 minutes.
2. An always-on connection doesn’t mean constant heavy activity
The Shadowrocket app interface and the VPN tunnel managed by the system are different things to monitor. After you leave Home, the connection can continue handling network traffic that meets the configured conditions. The app being out of the foreground does not mean network processing has stopped. Conversely, an active tunnel with no ongoing requests should not be treated as heavy activity for the entire time it remains connected.
Power use also depends on data volume, encryption, wireless signal strength, network changes, and connection retries. Photo sync, video playback, or requests from other apps can keep the tunnel busy even while the Shadowrocket interface is closed. Wireless communication over a weak cellular signal can also increase overall battery use, so don’t attribute every change to the proxy protocol.
- Always-on connection: The tunnel remains available, but it isn’t necessarily sending or receiving large amounts of data every second.
- Ongoing data transfer: Consider what you were doing and any available traffic records. Check for background sync and extended playback.
- Repeated reconnections: These often occur when the network is unstable, the device switches networks, or trigger conditions change. Compare the failure times with the network status.
- Force-quitting the app repeatedly: This is not a substitute for checking On Demand and is not a reliable way to manage tunnel status. To stop the connection, check the connection toggle and the system VPN status.
3. Understand the different roles of Global Routing and On Demand
Global Routing determines how traffic is routed; On Demand determines when the system establishes or manages a connection. They are not interchangeable battery-saving switches. In particular, switching Global Routing to Direct does not turn off the VPN tunnel. To compare against a disconnected state, check the connection toggle and On Demand separately.
| Setting | Primary function | What to check while troubleshooting |
|---|---|---|
| Proxy | Routes traffic through a proxy | May change which traffic is routed through the proxy; it should not be treated as a battery-saving mode. |
| Direct | Routes traffic directly | Direct does not mean the tunnel is disconnected. |
| Config | Routes traffic according to the active configuration’s rules | First confirm which configuration is active and where the matching traffic is routed. |
| Scene | Applies the configured scene logic | Check the scene conditions as well. Don’t treat this as the same test as a fixed routing state. |
| On Demand | Manages connections based on conditions | Check the network conditions and rule order. A condition may reconnect after you expect the connection to stop. |
In Config, DOMAIN-SUFFIX matches domain suffixes, GEOIP matches based on an IP address’s geographic location, IP-CIDR matches IP ranges, and FINAL specifies where traffic goes when no earlier rule matches. These rules determine traffic routing; they don’t directly control how long a connection stays active. Removing rules to save battery may change traffic routing without reducing background requests.
4. Test whether On Demand works for you with three comparisons
On Demand may reduce unnecessary connection time only when its trigger conditions match your usage. It is not a general-purpose battery feature that automatically detects what every app needs. Broad conditions can keep a connection active for long periods; frequent network changes can lead to more connection attempts. A domain-based condition also does not mean “connect whenever any app opens.”
Start by testing a single network condition—for example, one Wi-Fi network—rather than combining a Wi-Fi name, cellular service, and domain conditions from the outset. For rule actions and order, use the fields actually shown in Settings → On Demand. Check each rule individually rather than copying a complete set from an unknown source.
-
Save the original settings
Record whether Settings → On Demand is enabled and the order of its existing rules. Also note the Global Routing setting on Home. During testing, don’t update subscriptions, switch nodes, or replace Config.
-
Test with the connection off
Temporarily turn off On Demand, then disconnect and check the system VPN status. Run a preselected local task or one that connects directly, and record the battery level at the start and after 60 minutes. If you can’t perform the same task, use this run only as a standby baseline.
-
Test an always-on connection
Keep On Demand off and manually connect to the same node you already have, using the original routing mode. Repeat the same task on the same network at a similar battery level, and note battery loss and any unexpected reconnections.
-
Test On Demand
Open Settings → On Demand and enable the single network condition you checked. First verify how the connection behaves when the condition is met, then test what happens when it is no longer met. Check the system VPN status each time; don’t rely on the setting alone.
-
Repeat the comparison
Observe each setup for another period of the same length. If the battery difference is small or inconsistent, record the result as inconclusive rather than assigning a fixed battery-saving percentage. Also compare whether connection delays affect your usage.
The 60-minute period is a test duration, not a battery-life claim for the app. Keep screen brightness, signal, task, and ambient temperature as consistent as possible. Avoid charging and periods of heavy system sync. If short-term results vary, extend the observation period while keeping conditions comparable.
5. If connections keep retrying, check network errors first
If unusual battery drain happens alongside connection failures, check the order of events in the logs: did retries start after the network dropped, or was the node already failing to connect? The following are examples of system network errors that may appear in connection logs, not battery alerts. Capitalization, additional details, and where they appear may vary; refer to the records in the app. A single error does not prove how much battery it used.
Error: Connection refused
Cause: The connection to the destination address or port was refused. The service may not be listening, or the connection may have been actively rejected.
What to do: In Home, check the address, port, and protocol for the node you already have. If an entry managed through your subscription has changed, update it according to your provider’s instructions and try again. Don’t repeatedly guess and edit values by hand.
Error: Operation timed out
Cause: The connection or related operation did not complete in time. Possible causes include packet loss, an unreachable destination, or a slow response.
What to do: Keep the same node and try again once on stable Wi-Fi, then compare with another working connection you already have. Don’t run repeated batches of latency tests as a substitute for troubleshooting.
Error: Network is unreachable
Cause: The current network path is unreachable, possibly because the network changed or the device had no available connection at the time.
What to do: First confirm that the system can access the network normally. Then check any conditions for the current network in Settings → On Demand. Avoid repeatedly toggling the connection before the network has recovered.
- Note when the error occurred, the network type, and the exact error text. Before sharing logs, remove subscription URLs, authentication details, and private domain names.
- Run only the individual tests needed to troubleshoot. Continuously testing multiple nodes also creates network activity and can skew battery comparisons.
- If you enabled additional detailed logging, restore your usual settings after troubleshooting. Don’t include the extra logging activity in long-term observations.
- If similar battery drain and heat continue after disconnecting Shadowrocket, check other activity in the system Battery list and review the signal strength.
6. Choose always-on or On Demand based on your usage
Choose between always-on and On Demand based on how often you connect, rather than assuming one will always save battery. If you use the same connection frequently throughout the day, keeping it connected may reduce waits and repeated connection setup. If you need a connection only on certain networks or at specific times, verified On Demand conditions can limit connections during other periods. Check either choice against your own battery records.
| Usage pattern | What to try first | What to check |
|---|---|---|
| Frequently accessing the same resources throughout the day | Keep the same node and Config, then test a stable always-on connection | Check for ongoing data transfer and failed reconnections, and whether wait times decrease. |
| Connecting only on a specific Wi-Fi network | Set and verify the network condition in On Demand | Check whether behavior matches expectations when joining and leaving that network. |
| Frequently switching between Wi-Fi and cellular | Simplify the conditions first and test each network separately | Check for repeated reconnections during network changes and heat when the signal is weak. |
| Using the connection only occasionally, at set times | Start with manual connect and disconnect as a comparison | Check whether On Demand reconnects after you disconnect and whether background activity continues after the task ends. |
Protocol names are no substitute for measurement. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard use different connection methods and settings, but results also depend on the device, network path, actual throughput, and server conditions. Test only what your existing service supports. Don’t switch protocols or apply mismatched settings just to chase unverified battery savings.
7. Common questions about battery drain and On Demand
The VPN icon is still showing after the screen locks. Does that mean it’s using a lot of battery?
The icon shows connection status, not data throughput. Check overall battery loss and background activity for the relevant period in Settings → Battery, then look for sync tasks or failed reconnections. To confirm the disconnected state, temporarily turn off Settings → On Demand and check the system VPN status.
Why didn’t enabling On Demand noticeably reduce battery use?
First check whether the conditions keep the connection active almost all the time, or whether network changes cause more reconnections. Record the conditions and order in Settings → On Demand. Keep just one verified test condition, then compare it with a manually maintained connection over the same period.
Why is there still activity in Battery after switching to Direct?
Home → Global Routing → Direct changes the routing mode; it does not stop the tunnel. For a disconnected baseline, separately turn off On Demand triggers and disconnect, then confirm the system VPN status. Keep in mind that the Battery page may still include statistics from earlier periods.
Do subscription updates and latency tests need to run all the time?
No. Repeated tests are not necessary to keep a connection active. Complete any needed subscription updates first, then keep the node fixed for battery comparisons. While recording results, avoid repeatedly refreshing subscriptions on Home or testing an entire group of nodes, since extra requests can affect the comparison.
Keep a reproducible record of the device, network type, test duration, starting and ending battery levels, Global Routing, On Demand status, and when the issue occurred. Change one variable at a time. If the result cannot be reproduced, restore the original configuration and keep observing; this makes the cause easier to identify than turning off several features at once.