Shadowrocket’s On Demand feature automatically establishes a VPN connection when specified conditions are met; it is not a universal battery-saving switch. This guide is for users experiencing battery drain while the screen is locked, automatic reconnection after disconnecting, or repeated connections when the network changes. Check iPhone battery activity first, set trigger conditions, then compare results under the same conditions to distinguish connection maintenance, actual traffic, and repeated retries. Connection tests assume you already have your own server configuration or subscription.
1. Distinguish Background Connections, Traffic, and Automatic Triggers
Leaving Shadowrocket’s foreground screen does not mean the system VPN tunnel has stopped. A network extension can continue handling traffic in the background, so the app being offscreen does not tell you whether the connection is still active. Conversely, a VPN icon in the status bar does not mean the device is constantly transferring data under heavy load. An idle connection and an ongoing download are not comparable in terms of power use.
On Demand lets the system decide whether to establish a connection based on configured conditions. It does not mean “connect only when a particular app is open,” nor does it guarantee disconnection whenever the screen locks. Background sync, network changes, or matching network requests can all coincide with connection activity. The exact triggers depend on your rules and system behavior.
A persistent connection may need to maintain a session, while reconnecting can involve DNS lookups, transport connections, and an encryption handshake. If On Demand causes repeated connections in a short period, the cost of rebuilding them may outweigh any savings from reduced idle maintenance. First check whether the connection is stable; then decide whether automatic connection makes sense.
2. Establish a Baseline in iPhone Battery Activity
On your iPhone, go to Settings → Battery. Review the available time ranges and activity details, then select a period when the battery drain seemed unusual. Charts and filters may vary by system version, so use the options shown on your device. Check whether the battery drop coincides with screen use, background activity, or heavy network use by other apps. Don’t rely on a single percentage in the app list.
- Record the starting conditions. Note the time, battery level, Wi-Fi or cellular connection, signal strength, and whether the device is charging. During the test, avoid charging and high-load tasks such as system updates.
- Keep usage consistent. For a screen-locked test, leave the screen locked; for a web-browsing test, use similar content. Don’t compare a video playback session with an idle period.
- Review the selected time range. Check when activity occurred in the battery chart and distinguish screen-on activity from background activity. An app’s usage percentage usually represents its share of battery use during the selected period; it does not directly show how many percentage points the battery lost.
- Repeat the observation. Battery readings over short periods have limited precision. A one- or two-point difference in a single test does not prove a setting helped. Repeat the test under similar conditions and consider the connection logs as well.
Takeaway: Align the time periods before drawing conclusions
Continue investigating this angle only if the battery drain coincides with repeated connections, failed requests, or sustained data transfer. A high ranking for background usage alone does not prove that On Demand is the cause.
3. Configure and Test Settings → On Demand
Before making changes, check which server is in use on Home and note the active configuration in Config. This helps avoid changing the server, routing mode, and auto-connect conditions all at once, which would make it hard to identify the cause. If you have questions about subscription content or connection parameters, check with your own service provider.
- Open the settings. In Shadowrocket, go to
Settings → On Demand. Check whether it is enabled and review the existing conditions. Note the current settings so you can restore them later. - Start with a control test with On Demand off. Temporarily turn off On Demand, then return to Home and disconnect manually. During a test period when you don’t need network access through the tunnel, check whether the connection still starts automatically.
- Specify the target network. If you want automatic connection based on the network environment, enable On Demand and configure the network type or matching conditions actually available on the page. If the interface offers an SSID condition, enter the exact name of the Wi-Fi network your device uses, including spaces and capitalization.
- Start with one condition. Test a single condition first; don’t add several overlapping matches at once. Don’t assume that leaving a restriction blank means the condition will not trigger. Check the interface guidance and verify the connection behavior.
- Test both joining and leaving the network. Test when joining the target network, leaving it, and resuming use after locking the screen. Check the connection status on Home each time. If you review the system configuration under iPhone Settings → General → VPN & Device Management → VPN, take care not to change configurations used for other purposes.
- Know how to disconnect. To keep the connection off, turn off On Demand first, then disconnect on Home. If you only use the connection toggle on Home, the connection may start again the next time its conditions are met.
4. Choose Between Persistent, On Demand, and Manual Connections
The goal is to reduce unnecessary connection changes while still meeting your access needs. If you need a tunnel for much of the day, keeping a stable connection may be better than repeatedly rebuilding it. If you use it only occasionally, manual connection is often easier to control. On Demand works best when the trigger conditions are clear; it does not replace deciding when a connection is needed.
| Use case | Settings to test | What to check first |
|---|---|---|
| You need tunnel access throughout the day | Keep the connection stable and compare it with your current On Demand settings | Check for ongoing traffic, failed retries, or frequent reconnections |
| You use the tunnel briefly each day | Turn off On Demand and connect manually from Home when needed | Check whether the connection stays off after you disconnect |
| You use the tunnel only on certain networks | Use network conditions actually supported by On Demand | Check whether behavior matches expectations when entering and leaving that network |
| You frequently switch between Wi-Fi and cellular | First reduce overlapping conditions and keep the server unchanged | Check whether network changes coincide with connection failures |
Weak signal, Wi-Fi networks with incomplete captive portal sign-in, and network changes can all prevent a connection from being established. For example, when joining public Wi-Fi, complete its sign-in requirements before testing the tunnel. Repeatedly toggling the connection won’t fix an underlying network that is not yet available. Battery use on a weak cellular signal may also come from wireless communication itself, not just Shadowrocket.
5. If Connections Keep Repeating, Check the Errors Before Changing Settings
If the connection log shows repeated failures, note the time, network, and target server, then compare these with the battery chart. The following are common English error messages in network diagnostics. Capitalization, prefixes, and additional details may vary, so keep the full text shown on your device. These errors point to areas to investigate; a single log entry is not enough to determine the cause.
Error: Connection refused
Cause: The target address is usually refusing connections on that port. The service may not be listening, the port may be incorrect, or a network device may be actively rejecting the connection.
What to do: Check the server address, port, and protocol against your existing configuration, then ask your service provider to confirm the service status. Don’t change the port to 443 just to clear the error.
Error: Operation timed out
Cause: The operation did not complete within the allowed time. Possible causes include an unreachable network, packet loss, an unresponsive destination, or a restricted connection path.
What to do: Keep the configuration unchanged and test again on another network available to you. If the problem occurs on only one network, check that network first, then investigate the server.
Error: Network is unreachable
Cause: The current connection path is unavailable. This often happens while network interfaces are switching or before the underlying network has recovered.
What to do: First confirm that the device has basic network access. Wait for the network to stabilize, then try again and check whether On Demand is triggering repeatedly during network changes.
A recovery after one failed attempt is not necessarily a problem. Look for frequent, repeated failures and reconnections, especially when no data is being transferred. Don’t change DNS, the server, the protocol, and On Demand all at once; even if the issue disappears, you won’t know what fixed it. Before sharing logs that include credentials or subscription links, redact sensitive information.
6. Global Routing and Rules Affect Traffic Paths, Not Disconnection
When checking Global Routing on Home, distinguish the routing policy from the tunnel switch. Choosing Direct changes how requests are routed; it does not turn off the system VPN. Choosing Config routes requests according to the current configuration. On Demand controls the conditions for automatic connection. They serve different purposes, so selecting Direct does not prove that the background tunnel has stopped.
If you want only specific websites to use a proxy, review the rules and their order in Config after making a backup. The example below illustrates syntax only: example.com is a demonstration domain, and PROXY must correspond to a usable policy in your configuration. This is not a universal battery-saving configuration and should not replace your entire active configuration.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECTDOMAIN-SUFFIXmatches a domain and its subdomains. Put more specific matches before catch-all rules.FINAL,DIRECTassigns DIRECT to requests that were not matched by earlier rules; it does not turn off the tunnel.- After simplifying your rules, check whether actual requests match the intended policies. Necessary proxy traffic, DNS lookups, and failed retries will not automatically disappear just because a FINAL rule exists.
Likewise, don’t switch from Shadowsocks, VMess, VLESS, Trojan, Hysteria2, or WireGuard blindly to save battery. The protocol, transport, server quality, and current network all affect the result, and the existing server must support the relevant configuration. The protocol name alone cannot predict how much battery an iPhone will use on a particular network.
7. Finish Troubleshooting with Reproducible Comparisons
Wrap up the investigation with three tests: fully disconnected, manually connected and stable, and On Demand with a clearly defined condition enabled. Use similar durations and activities for each test, keeping the same network, server, and routing configuration. These are test scenarios, not a recommendation to keep switching connections during everyday use.
- Fully disconnected test. Turn off On Demand and disconnect. Record baseline battery use for this scenario. If you still see unusual drain, check screen activity, other apps, signal strength, and system tasks.
- Stable connection test. Keep On Demand off and establish the connection manually. With similar traffic, check for unusual heat, repeated errors, or heavy background requests.
- Automatic connection test. Enable the single condition you have verified. Check whether connection attempts increase noticeably and whether those changes coincide with periods of faster battery drain.
- Keep a record. Save the battery level and time at the start and end of each test, connection status, and the full text of any errors. This information is more useful for further troubleshooting than simply saying “background activity uses a lot of battery.”
Takeaway: Keep only the automatic conditions your usage requires
If the automatic connection test shows frequent reconnections but the stable manual connection test is normal, adjust the On Demand conditions first. If both connection tests show problems, investigate the network, server, and ongoing requests. Don’t attribute every change in battery use to the same switch.
Your final settings should be both usable and verifiable: the connection should start when needed, stay off when it isn’t needed, and avoid repeated failures after network changes. After completing these tests, choose a persistent, On Demand, or manual connection based on your needs—not a single battery percentage.