To tell whether Shadowrocket is increasing battery drain, consider total device battery loss, the system’s battery attribution, and whether connections are repeatedly re-established. This guide is for users with their own connection service or subscription who are choosing between a persistent connection and On Demand. First, establish comparable records; then adjust the trigger conditions and check behavior during network changes and after locking the screen. Don’t draw conclusions from the VPN icon or a single usage percentage.
First, distinguish the app interface, VPN tunnel, and actual traffic
Shadowrocket is a paid client for Apple platforms, distributed through the App Store as a one-time purchase. To verify the genuine app, check its official icon, developer Shadow Launch Technology Limited, and app ID 932747118. System requirements and compatibility are as listed on the App Store page. Buying the client is separate from any connection service you already use; the purchase does not include a service plan.
Returning to the Home screen puts the app interface in the background, but it doesn’t necessarily stop the system VPN tunnel. While connected, the associated network extension still handles traffic routed through the tunnel. Conversely, a VPN icon in the status bar doesn’t mean the device is continuously transferring data at high speed. An idle connection, video playback, and repeated reconnects on a weak signal all have different energy demands.
Battery use may come from encryption, sending and receiving data, maintaining connections, DNS lookups, and retries after failures. Screen brightness, background sync, and cellular signal strength also affect total device drain. So “time running in the background” indicates how long activity continues, but doesn’t directly tell you how much extra battery it uses.
Always-on vs. On Demand: the connection timing changes
A persistent connection can suit use cases that need a more consistent network path. Once connected, later requests usually don’t have to wait for the tunnel to start, though connection maintenance and system network activity may continue while idle. On Demand lets the system manage connection behavior according to configured conditions. It doesn’t mean “disconnect when the screen turns off,” and it doesn’t only detect the app currently in use.
| Setup | Connection behavior | Costs to consider |
|---|---|---|
| Persistent connection | Keeps the tunnel up; actual traffic depends on app activity. | Idle maintenance, retries on weak signals, and ongoing background traffic. |
| On Demand | Triggers system connection behavior based on configured conditions, such as networks or domains. | Waiting for the initial connection, changing conditions, and overly broad triggers. |
| Manual connection | You connect and disconnect from Home. | Easy to forget to connect or disconnect; requires a consistent routine. |
If notifications, sync, or other background requests often meet the trigger conditions, On Demand may still keep the connection up for long periods. Frequent switching between Wi-Fi and Cellular, or conflicting configured SSID conditions, can also add connection overhead by repeatedly starting the tunnel. Enabling On Demand alone doesn’t guarantee better battery life.
Bottom line: reduce unnecessary reconnects first
Compare the two options with the same configuration on a stable network. If the logs show repeated connections and disconnections, fix the trigger conditions or network issue before assessing any battery benefit from On Demand.
Use the system Battery page to make comparable records
Check battery usage in Settings → Battery on your iPhone or iPad. The time range and chart controls may vary by system version, so choose a period that covers your test and record screen-on and background activity. An app’s percentage is its share of attributed usage within that reporting period; it doesn’t mean the battery capacity fell by the same percentage.
-
Keep conditions consistent
Use the same device, Wi-Fi network, connection configuration, and similar screen brightness. Don’t charge during the test, and avoid system updates, large photo syncs, and file transfers.
-
Record a baseline
Open Settings → Battery and note the start time, battery level, and network type. Also note whether Shadowrocket is connected and whether Settings → On Demand is enabled.
-
Test persistent connection
Observe a persistent connection for 30 minutes first. Follow a predefined usage pattern or leave the device locked and idle. Record the battery level and any unexpected reconnects at the end. Don’t combine screen-on use and locked idle time in the same test.
-
Test On Demand
Switch to the verified On Demand conditions and observe for the same 30 minutes. Keep app activity as similar as possible, and record whether a connection was actually triggered—not just whether the setting was enabled.
-
Repeat and compare
Repeat at a similar time, alternating the test order. Compare the system battery chart with total battery loss in each session. No visible battery-level change over a short window doesn’t prove there was no energy use.
The 30-minute period is a practical observation window, not a battery-life test result. Battery percentages are rounded, and background tasks vary. If the difference is small, extend the observation and repeat it rather than claiming a fixed “savings percentage.” If the device gets warm, also check signal strength, screen use, and activity from other apps.
How to check Settings → On Demand
In Shadowrocket, check the current On Demand settings under Settings → On Demand. Record the existing conditions first, then change one item at a time. Condition names and available actions depend on the current interface. Enter the SSID as it appears on the device’s connected Wi-Fi network; domain conditions aren’t general-purpose URL filters.
- Check the default behavior first: Confirm what happens when none of the specified conditions match, so you don’t configure exceptions while overlooking connection behavior on other networks.
- Then check Wi-Fi: Verify SSID spelling, spaces, and capitalization. If different bands at home use different network names, test each one; the router’s device name isn’t enough.
- Check Cellular separately: Leave Wi-Fi and observe whether the connection behaves as expected. Adding more trigger conditions won’t fix timeouts caused by a weak signal.
- Finally, check domains: If a domain trigger is configured, visit the target and verify the behavior. Caches and existing connections can affect the result; opening a page once doesn’t prove the rule always works.
- Test with the screen locked: Check the connection after locking the screen, after unlocking, and after a network change. Note whether it keeps reconnecting.
For example, if you don’t want to stay connected on home Wi-Fi but do want a connection on Cellular, first make sure your home network meets your everyday needs. Then configure the relevant conditions and test three scenarios: home Wi-Fi, Wi-Fi turned off, and reconnecting to home Wi-Fi. A brief wait during a switch may be normal while the connection is established. Persistent loading should be investigated as a connection issue, not automatically treated as normal On Demand behavior.
Global Routing and protocol settings don’t diagnose battery drain
On Demand determines when to trigger a connection; Global Routing determines how traffic is routed after connecting. They operate at different levels. The Proxy, Direct, Config, and Scene options under Home → Global Routing are not four battery modes. In particular, Direct doesn’t necessarily mean the system VPN tunnel is off.
| Mode | What to check |
|---|---|
Proxy | Traffic is primarily handled through the proxy; check actual data transfer and connection quality. |
Direct | Traffic is primarily connected directly to its destination; this doesn’t mean the network extension has stopped working. |
Config | Traffic is routed according to the current configuration; check the matched rule and final policy. |
Scene | Check the current scene configuration and the routing behavior it actually uses. |
With Config, rules such as DOMAIN-SUFFIX, GEOIP, IP-CIDR, and FINAL determine where requests go; they aren’t battery controls. If an app’s requests repeatedly fail, first check which rule they match and which policy is ultimately applied. Then decide whether an adjustment is needed—instead of switching everything to Direct just to reduce background activity.
Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard, and Snell have different connection-maintenance methods and transport characteristics, but there’s no universal battery-saving ranking independent of the device, signal, and server settings. Keep the protocol and parameters required by your existing service, then compare one variable at a time. Changing ports, transport modes, or keep-alive settings at random can turn a stable connection into repeated retries.
- When comparing routing modes, keep the On Demand conditions unchanged.
- When comparing protocols, confirm the server supports the configuration; changing only the client-side name isn’t enough.
- After troubleshooting, turn off any detailed debug logging you enabled temporarily to avoid unnecessary diagnostic activity over time.
If timeouts and reconnects occur, troubleshoot the connection first
If battery use rises alongside repeated failures, compare the connection errors with the corresponding period in Settings → Battery. The snippets below are examples of errors you might see in connection logs. Exact formats depend on the protocol and log source. They indicate possible network issues, but don’t prove which component is using the battery.
Error: i/o timeout
Cause: A read or write operation didn’t finish within the allowed time. The network may be unreachable, the signal unstable, or the remote end unresponsive.
Fix: Keep the existing configuration and test the same connection separately on stable Wi-Fi and Cellular. Check whether the failure happens only on one network, and don’t let a failing connection keep retrying.
Error: connection refused
Cause: The destination actively refused the connection, often because the port is incorrect or no service is listening on it.
Fix: Check the address, port, and protocol for your existing service. If needed, ask your service provider to confirm its status, then correct the settings before re-enabling On Demand.
If the errors started after a subscription update, first check whether the selected connection changed and whether the previous address and protocol settings still apply. Don’t keep refreshing the subscription to troubleshoot every timeout: an update retrieves configuration, but can’t fix a weak signal or a remote service issue. Before sharing diagnostic screenshots or logs, hide subscription links, authentication details, and other sensitive information.
Bottom line: keep the connection that fits your needs
If you need continuous access, prioritize connection stability. If your network boundaries are clear and there are long idle periods, test On Demand. Keep a setting as your everyday setup only when total battery loss, actual connection status, and usage activity support the same conclusion.