Shadowrocket's battery impact depends on data use, signal strength, and how often the connection reconnects—not just the VPN icon or its ranking in Battery. This guide is for iPhone and iPad users who already have their own service details and want to adjust how they connect day to day. First, distinguish the tunnel from background app activity, then configure On Demand and compare Battery records under the same conditions.
Why does background activity appear in Battery?
Does seeing Shadowrocket's background activity mean it's constantly running at high load? No. The app's foreground interface and the system network extension that handles the connection are separate. After you leave Home, the VPN tunnel can continue handling network requests from other apps. The interface being off-screen doesn't mean network processing has stopped.
Where does the battery power go? When data is flowing, the tunnel handles data processing, encryption and decryption, and network traffic. Even when idle, keepalives, DNS requests, and reconnections may occur. Requests from video playback, photo syncing, or large file transfers can pass through the tunnel, so related activity in Battery doesn't necessarily come from using Shadowrocket in the foreground.
Does the battery percentage show the extra power the app uses? No. The Battery screen attributes usage over the selected period, and the percentage is also affected by activity from other apps. Open Settings → Battery and compare the charge level graph, screen activity, and background activity for the same period before deciding whether the battery is draining unusually fast.
- Check the time period first: Choose a range that includes the issue. Don't compare an entire day's records with a 10-minute test.
- Check what was running: Note whether anything was syncing, downloading, playing media, or continuously receiving messages.
- Check the network: Record whether you were on Wi-Fi or cellular, the signal strength, and any network switches.
Can On Demand save battery automatically when there's no traffic?
Is On Demand an idle timer? No. It lets the system handle on-demand connections according to configured network conditions and connection rules. It doesn't mean “disconnect when there's no traffic and reconnect whenever an app opens.” What triggers a connection depends on the rules, and enabling On Demand doesn't guarantee lower battery usage.
How is On Demand different from Global Routing? On Demand determines when a connection is triggered; Global Routing determines how requests are handled while connected. Under Home → Global Routing, Proxy, Direct, Config, and Scene are different handling modes. Config routes traffic according to the current configuration, while Scene follows the configured scenario. Switching between these options doesn't turn off On Demand.
Bottom line: Set connection conditions first, then adjust traffic handling
To connect automatically after leaving a particular Wi-Fi network, start with Settings → On Demand. To send some requests directly, check Home → Global Routing and Config. Direct is not a way to turn off the tunnel, and On Demand is not a substitute for traffic rules.
How should you configure Wi-Fi and cellular separately?
Should On Demand be enabled on every network? Set it according to your needs. Before changing anything, connect manually from Home and use your own service details to confirm access works. Then go to Settings → On Demand and review the available network conditions. Options can vary by app version, so follow what's shown in the app. Network-name conditions, connection actions, and the master switch are separate settings.
- Confirm the connection works first. On a stable Wi-Fi network, open a page you use regularly and note the current Global Routing mode and configuration. If a manual connection fails, fix that before adding automatic triggers.
- Set the Wi-Fi conditions. If you need to distinguish networks by name, check the actual SSID. Similar names can belong to different networks, and matching names don't guarantee a network is trustworthy. Consider how the network is managed before deciding.
- Check cellular separately. If you need a connection while mobile, review the conditions for cellular. If you only use the connection on fixed networks, check what happens after switching to cellular rather than relying on the master switch alone.
- Test a round trip. Switch from Wi-Fi to cellular, wait for the network to stabilize, and send a request. Then switch back to Wi-Fi and check the system VPN status and connection status in Home.
- Check again after locking the screen. Note the network and connection status before locking the screen. Unlock it later, send the same request, and check for connection delays or repeated reconnections.
Why does the connection come back after I turn it off manually? An On Demand condition may still be met, prompting the system to reconnect. For a full-disconnect test, pause On Demand in Settings → On Demand before disconnecting from Home. Restore your original settings when the test is over. Repeatedly force-quitting the foreground app isn't a substitute.
Always-on or on-demand connection: which should you choose?
Which option always saves more battery? There's no single answer for every network. A stable connection can avoid repeatedly establishing sessions; connecting only under certain conditions can reduce tunnel use when it's not needed. But if those conditions change frequently, reconnecting, handshaking, and restoring activity also use power. Compare connection reliability as well as battery usage.
| Usage scenario | Recommended approach | What to check |
|---|---|---|
| Ongoing use on the same network | Start with a stable, always-on connection as a baseline | Heavy background traffic and unexpected reconnections |
| Connect only on specific networks | Set On Demand conditions for each network | Actual behavior when joining and leaving that network |
| Frequent network switches while commuting | Avoid unnecessary changes between conditions | Time to resume requests and number of failed attempts |
| Set up a short disconnect comparison | Pause On Demand, then disconnect manually | Whether the system triggers a reconnection anyway |
Will switching to Direct show battery use with “the tunnel off”? No. Direct is a traffic-handling mode; it doesn't mean the system VPN tunnel has stopped. Likewise, DOMAIN-SUFFIX, GEOIP, IP-CIDR, and FINAL in Config match traffic and select how to handle it—they don't determine when On Demand starts.
Bottom line: If recovery keeps failing, reduce the number of variables
If you have to wait or retry after every network switch, first keep the connection on one network and verify that it's stable. Once the basic connection works, add On Demand conditions one at a time. Don't change the protocol, DNS, and Global Routing at the same time.
What should you check first if the device gets hot or keeps reconnecting?
Can device heat be blamed on a particular protocol? No. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard work differently, but actual resource use also depends on traffic, server response, transport settings, and wireless signal. Your protocol must match your own service details. Don't change Type for testing while leaving fields from a different protocol in place.
What should you look for in the logs first? Match the error to the time the issue occurred, then check for repeated timeouts, connection refusals, or handshake failures. The examples below are possible low-level error messages, not guaranteed full alert text in every app version. Keep the exact message and timestamp, then troubleshoot based on the error type.
Error: connection refused
Cause: The destination refused the connection, often because nothing is listening on the port or the connection was explicitly rejected.
Fix: Open the current server configuration from Home and compare its address and Port with your service details. Ask your service provider whether the port is available. Repeatedly changing On Demand won't fix an underlying connection problem.
Error: TLS handshake timeout
Cause: The TLS handshake didn't complete in time. The link may be unreachable, the network may be restricting traffic, or the server may not be responding properly.
Fix: Try again on a stable network, then check the TLS settings against the server's requirements. If this happens only on one Wi-Fi network, check its web login and connectivity. Don't disable certificate verification as a general fix.
What if there's no error but battery use remains high? Pause any heavy data activity and see whether the charge still drops noticeably while idle. Then check for overly frequent scheduled tests or other recurring tasks. Also distinguish subscription updates from tunnel connections: refreshing your own subscription updates its configuration source; it won't fix a weak signal or automatically reduce battery use.
- Weak signal: Move to a location with a stable signal and test again. Don't attribute cellular network searching and repeated transmission attempts entirely to the tunnel.
- Heavy ongoing traffic: Check whether syncing or media activity is running, then note what changes after it stops.
- Repeated failures: Keep the error text and timestamps after removing sensitive details. Don't share subscription links, passwords, or full connection credentials.
How can you run a battery comparison you can repeat?
How can you compare battery usage without being misled by the Battery ranking? Use the same device, a similar starting charge, and the same network. Record results separately for an always-on connection and On Demand. The time periods below are a test plan, not measured results or a promise of a particular battery impact.
- Record the starting conditions. Note the starting charge, screen brightness, network type, Global Routing mode, and background sync status. Don't charge the device during the test.
- Test the always-on connection. First observe for 30 minutes with the screen off, then spend 30 minutes on a consistent task, such as repeatedly reading similar web pages. Record the charge at the end of each period.
- Test On Demand. Restore similar starting conditions and repeat the same test with verified On Demand conditions. Record network switches and reconnection attempts.
- Run a disconnected baseline. Pause On Demand and disconnect, then repeat the same task if it works without the connection. If you can't access the service directly, don't treat this result as an equivalent comparison.
- Repeat the comparison. Run at least one more round. If the difference is close to the battery indicator's display precision, extend the observation period. Don't claim a setting saves a fixed percentage based on that result.
Which settings should you keep in the end? Favor the setup that reliably handles your activity and recovers normally after network changes, then compare battery use across repeated tests. If On Demand avoids unnecessary connections without causing more failures, keep the relevant conditions. If frequent reconnections disrupt use, simplify the conditions and rule out network problems. Verify reliability and battery life together; the VPN icon alone isn't enough.