You can’t judge Shadowrocket’s background battery use from the VPN indicator or its position in the battery usage list alone. First, compare battery changes under consistent conditions. Then go to Settings → On Demand to set connection conditions by network. Focus on avoiding unnecessary connections and failed retries rather than repeatedly force-quitting the app. This guide is for iPhone and iPad users who already have their own service provider and connection details and want to balance automatic connections with battery life.
Bottom line: Connection time doesn’t equal battery drain
Once Shadowrocket connects, the system network extension can handle network traffic while the app isn’t in the foreground. Leaving the app doesn’t stop the tunnel, and background activity doesn’t mean it runs at high load the entire time. Battery use depends on traffic volume, wireless signal strength, connection retries, encryption, and network activity from other apps.
On Demand lets the system decide when to establish or maintain a connection based on configured conditions. It isn’t a battery-saving switch or a timer that disconnects as soon as apps are idle. If nearly every network triggers a connection, it may work much like staying connected. Conditions that are too specific can lead to more reconnects when networks change.
Keep two separate functions in mind: On Demand manages connection conditions, while Global Routing controls where traffic goes. Setting Global Routing to Direct doesn’t turn off the VPN. Using Config and matching some requests to DIRECT doesn’t unload the system tunnel either. When troubleshooting battery use, track whether the tunnel is connected separately from how traffic is routed once connected.
Use Battery settings to establish a fair comparison
On your iPhone or iPad, open Settings → Battery and review the usage chart, time period, and app activity. Menu names may vary with the system language; the time range and details shown on your device are what matter. Focus on the period when the issue occurred rather than comparing an all-day summary with what you noticed during a single hour.
-
Choose a time period
In Settings → Battery, select the period you want to check. Note the starting and ending battery levels, screen activity, and Shadowrocket’s share of usage. Record whether the device was charging.
-
Keep conditions consistent
Use the same location and Wi-Fi network, keep screen brightness similar, and repeat the same tasks. Pause high-traffic activities such as large downloads and photo syncing before comparing connection settings.
-
Record a baseline
First, observe your current settings for a complete period, such as 60 minutes. Note video playback, time spent with the screen locked, and any network changes. Sixty minutes is just a test window, not a battery-life guarantee.
-
Change one setting at a time
For the next test, change just one On Demand network condition and leave everything else as is. Observe for the same amount of time. Don’t change the connection, DNS, and rules all at once.
The percentages in the battery list usually show each item’s relative share of usage during the selected period, not the number of battery percentage points an app consumed. For example, if your device drops from 80% to 70% and an app shows 20% usage, that doesn’t mean the app used 20% of the battery. System estimates also involve attribution and rounding, so don’t treat them as precise battery measurements.
Bottom line: Compare the battery level of the whole device first
If the app’s share rises but the device doesn’t lose more battery under comparable conditions, keep observing. Don’t change protocols or reset all your settings based on the ranking alone.
Settings → On Demand: Set connection conditions by network
In Shadowrocket, go to Settings → On Demand and check the master switch and network conditions. These settings control automatic system connections, not how often subscriptions update. Options may vary between app versions. Use the Wi-Fi, cellular, and SSID options shown in your app; don’t enter a network name in the server address field.
-
Note your current settings
First, record the current switch state and Wi-Fi and cellular conditions in Settings → On Demand. If you already have SSID conditions, review each one to avoid conflicting rules.
-
Set Wi-Fi conditions
Choose whether to connect automatically on Wi-Fi based on how you use the app. If the app offers per-SSID options, you can set different conditions for a known network. An SSID is a Wi-Fi network name, not a password.
-
Set cellular conditions
Review cellular conditions separately. If you need uninterrupted access while away from home to services that rely on your existing connection, keep the relevant automatic connection condition. If you only use it occasionally, you may prefer to connect manually.
-
Test network switching
After saving, switch from Wi-Fi to cellular and then back to Wi-Fi. Allow the system to complete each network change, check the connection status in Home, and open a familiar page in Safari to confirm connectivity.
-
Check after locking the screen
Lock and unlock the screen, then watch for repeated connection attempts or pages that take a long time to load. To pause the connection, turn off On Demand first, then disconnect in Home so an automatic condition doesn’t immediately reconnect.
Choosing between a persistent, on-demand, or manual connection
Choose based on how continuously you need access, not on an assumption that one option always saves battery. Staying connected on a stable network can reduce manual steps. Disconnecting when you won’t need the connection for a long time can reduce tunnel activity. On Demand falls between the two; how well it works depends on whether its conditions match your use case.
| Connection method | Best for | What to check |
|---|---|---|
| Stay connected | Ongoing use of services that rely on the existing connection | Check for a stable connection, continuous traffic, or failed retries |
| On Demand | Automatic connection handling based on Wi-Fi and cellular conditions | Confirm the connection state after switching networks and check for repeated triggers |
| Connect manually | Occasional, short tasks | Turn off automatic triggers and disconnect manually; reconnect when needed |
Weak cellular signal or frequent changes between access points can increase battery use through wireless communication and retries. Test again on stable Wi-Fi first. A successful latency test only shows that a test request received a response at that moment; it doesn’t prove that long-lived connections, DNS queries, or web requests will always work.
Bottom line: Limit automatic connections to the networks you need
If you only need automatic connections when away from home, adjust the conditions for known Wi-Fi networks first, then test cellular use. Don’t turn off every condition just to shorten connection time if that would interrupt tasks that need continuous access.
If it keeps reconnecting, troubleshoot errors before focusing on battery use
If the connection status keeps changing, open the logging options in Settings and keep the entries around the time the issue occurred. The examples below are error messages that may appear in network logs; surrounding text varies by connection and in-app logging. These aren’t battery alerts, and a single error doesn’t prove that the server or client is at fault.
Error: connection refused
Cause: The connection target or an intermediate device actively refused the connection. Check the address, port, and whether the service is listening.
What to do: In Home, compare the address and port for your existing connection with the details from your service provider, confirm the service is available, and test again.
Error: i/o timeout
Cause: A read or write operation didn’t complete within the allotted time. Possible causes include packet loss, an unresponsive destination, or network restrictions.
What to do: Test the same connection on stable Wi-Fi, then compare it with cellular. Note when the error occurred, and avoid repeated refreshes and tests that add unnecessary traffic.
If the issue only occurs after switching networks, check the On Demand conditions and connectivity on the new network first. If the same connection keeps failing across different networks, review its settings and service status. Protocol names alone don’t determine battery use; network conditions, server responses, and actual traffic all affect the result.
- Address and port: Use the details you already have; don’t change the port to
443just because the connection uses TLS. - Authentication and TLS: Check authentication details and fields such as the server name. Don’t disable certificate verification as a battery-saving measure.
- Subscription updates: Update only when the information you already have has changed. Updating a subscription doesn’t replace troubleshooting network errors.
- Sharing logs: First redact subscription URLs, authentication details, personal domains, and other sensitive information.
Config and DNS: Don’t mistake routing issues for background battery use
In Home, check the current Global Routing selection. If you use Config, open Config and confirm which configuration file is active. Proxy, Direct, Config, and Scene control traffic handling; they don’t replace connection conditions in Settings → On Demand. If you use Scene, check the configuration it actually references rather than relying on its name.
The rule snippet below illustrates matching order only. It isn’t a battery-saving configuration and shouldn’t replace a complete file. Rules are evaluated from top to bottom, with FINAL last. Requests matching DIRECT connect to their destination directly, but the system tunnel may remain active.
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYIf a page keeps loading while the connection status remains stable, check DNS and rule matching separately. Failed name resolution can cause apps to retry requests, but that doesn’t mean DNS is responsible for all battery use. If you use custom DNS or DNS over HTTPS, first confirm the resolver is reachable on the current network. Don’t change DNS, rules, and protocol in the same battery comparison.
- Issue occurs only with Config: Check the active file, rule order, and which policy actually matches.
- Domain access fails while other requests work: Check DNS settings and resolution logs.
- Wi-Fi works but cellular doesn’t: Test connectivity on each network separately, then review cellular auto-connect conditions.
Post-setup review checklist
After making changes, test at least one Wi-Fi-to-cellular switch, one screen-lock and wake cycle, and a period of normal use. Compare the results with your original Battery notes, and keep the settings that are stable and meet your needs. A connection that keeps failing isn’t suitable for battery comparisons because repeated retries change the test workload.
- The connection status shown in Home matches the current network conditions, with no unexpected automatic reconnects.
- Everyday pages and services that need continuous access work as expected, without repeated manual retries after unlocking the screen.
- Comparison periods are the same length, with screen use, signal conditions, and major background tasks noted.
- You can restore the original settings if something goes wrong, and you’ve kept the times and logs instead of clearing all configuration at once.
Shadowrocket is a paid client for Apple platforms, primarily used on iPhone and iPad. Check the App Store listing for system requirements and device compatibility. The app is a one-time purchase; buying the client does not include a service plan. This guide covers managing connection details you already have and system connection behavior.