On Demand tells the system when to establish a connection based on conditions; it is not a low-power switch. To troubleshoot Shadowrocket battery drain, distinguish battery percentage from actual battery loss and repeated connection attempts, then compare settings under similar network and usage conditions. This guide is for iPhone and iPad users with their own service and subscription who are deciding between manual and automatic connections.
Start with iOS battery usage—not time in the background
After Shadowrocket connects, its network extension can handle traffic while the app is not in the foreground. Sending the app to the background does not disconnect the VPN, and a VPN icon in the status bar does not mean the device is continuously transferring data at high speed. Background activity, connection duration, and actual energy use are different measures.
On iPhone or iPad, open Settings → Battery, choose a time period, then review the battery level chart, screen activity, and Shadowrocket usage. Labels may vary by iOS version. The percentage shown next to an app generally represents its share of usage during the selected period; it is not the number of percentage points the entire battery lost. Nor can background hours be converted directly into battery use.
For example, if the battery drops by the same 5 percentage points in two periods, Shadowrocket may account for a larger share when other apps are used less. That’s a reason to investigate further, not proof that a setting doubled battery use. System attribution also affects how energy use from traffic handling is reported, so an individual app’s figure may not capture the full energy cost of networking.
Bottom line: Check total battery loss before changing connection conditions
If background time increases but total battery loss stays about the same under similar standby conditions, keep your current setup for now. If the battery curve keeps getting steeper, compare traffic, signal strength, and reconnection activity during the same period.
On Demand controls automatic connections—not all background traffic
Settings → On Demand configures connections triggered by specific conditions. The system can initiate a connection when those conditions are met. This is neither a setting that connects only when you open the app nor a guarantee that the connection drops as soon as there is no traffic. Actual behavior depends on the enabled conditions, such as Wi-Fi, cellular networks, and domains.
Turning off On Demand does not necessarily end an existing connection. For a manual comparison, return to Home and check the connection toggle and the system VPN status. Conversely, if On Demand is still enabled, the system may reconnect after you disconnect manually when a trigger condition is met. This usually means the condition took effect, not that the toggle failed.
| Setting or mode | What it controls | What it means when troubleshooting battery use |
|---|---|---|
| On Demand | When the system initiates a connection based on conditions | Check for repeated connections caused by network changes or matching conditions |
| Global Routing → Proxy | Routes traffic through the proxy | Changes the scope of traffic handled, so it is not directly comparable with another mode |
| Global Routing → Direct | Uses a direct connection | Does not mean the VPN is off or stop the network extension |
| Global Routing → Config | Handles traffic according to the current rules | Keep the same configuration so rule changes do not skew the comparison |
| Global Routing → Scene | Uses the selected Scene | Check the active Scene’s actual settings; its name alone does not reveal the traffic path |
There’s no universal answer to whether enabling On Demand saves battery. If the same connection stays active and carries the same traffic with On Demand off, the difference may be small. Automatic conditions may reduce unnecessary connection time, but overly specific conditions can repeatedly rebuild the connection and add overhead.
Run a repeatable battery comparison in four steps
Test the situations where the problem usually occurs—not standby battery life while continuously running latency tests. The times below are a practical way to structure a comparison, not a battery-life guarantee. Keep your existing configuration and don’t change the protocol, server, and routing mode at the same time.
-
Record a baseline
In Settings → Battery, note the starting charge, selected time period, and screen activity. In Home, note the current connection and Global Routing setting. Use the same Wi-Fi network, pause large transfers, and observe for 60 minutes.
-
Turn off automatic connections
Go to Settings → On Demand, turn off On Demand, then return to Home and connect manually. Keep usage consistent and observe for 60 minutes. This compares a manually maintained connection—not standby with the connection fully disconnected.
-
Enable the conditions you need
Go to Settings → On Demand and enable only the conditions needed for your current scenario. Keep the same connection, Global Routing setting, and network, then observe for 60 minutes. Note whether the connection starts automatically or reconnects repeatedly.
-
Repeat the test if results look unusual
If the results differ substantially, repeat the comparison during a similar time period. To add a fully disconnected baseline, first turn off On Demand, then disconnect from Home and check the system VPN status. Do this only when disconnecting is acceptable for your use case.
The battery percentage changes in whole numbers, so readings over an hour can be affected by display granularity, temperature, and background tasks. Don’t draw conclusions from a one-point difference in a single test. Avoid subtracting the results of two tests conducted while charging, during system-wide syncing or photo uploads, or while moving through areas with weak signal. If the device gets warm, also check screen brightness, cellular signal, and foreground app activity.
When background battery use rises, check reconnections and network quality first
Establishing connections, encryption, network transfers, and repeated requests all use energy. Switching between Wi-Fi and cellular, weak signal, or a temporarily unreachable server can cause repeated connection attempts, while other apps may keep retrying their own requests. Check records from when the problem occurred rather than relying only on whether the most recent test succeeded.
The following are error snippets that may appear during network troubleshooting. Full logs vary by protocol and system version. These messages can help identify a type of failure, but they do not measure battery use, and your logs may not match them exactly.
Error: connection timed out
Cause: The connection did not complete before the timeout. Possible causes include packet loss, an unreachable destination, or a mismatched port. This message alone does not identify the source of the problem.
Fix: Check the selected connection in Home. Use your existing service details to verify the server address and port, then test once on stable Wi-Fi and once on cellular. Avoid running repeated tests in a loop.
Error: certificate has expired
Cause: TLS certificate validation failed. The server certificate may have expired, or the device clock may be outside the certificate’s validity period.
Fix: In Settings → General → Date & Time, check that automatic date and time are enabled and the displayed time is correct. Then ask your service provider to confirm the server certificate status. Disabling certificate verification is not a fix.
- Only happens on cellular: Check signal strength and whether you’re moving between coverage areas. Changes in wireless network quality can increase retransmissions and radio activity; don’t assume On Demand is the cause.
- Happens frequently after switching networks: Check whether the network conditions in Settings → On Demand match your expectations. Record the connection status before and after each switch.
- Only happens with one connection: Check that connection’s existing protocol settings one by one. Don’t switch through several protocols and treat the last result as a battery verdict.
- No errors, but traffic keeps increasing: Check photo syncing, cloud backups, video playback, and background app refresh. Successful transfers can also use more battery; troubleshooting isn’t limited to failed connections.
Check protocols and configuration before attributing changes to battery savings
Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard differ in how they connect, transfer data, and use their settings. The protocol name alone does not determine a fixed battery-use ranking. Actual overhead depends on the device, network quality, traffic volume, server configuration, and connection stability. First make your existing setup stable, then consider changing one setting at a time based on evidence.
In Home, open the editor for the current connection and check the protocol, server, port, and authentication details against your original information. For example, if your details specify TLS port 443, verify that it matches. 443 is a common example, not a universal port for every protocol or server. For TLS, also check the server name and related settings against your details.
- Config: Keep the same configuration throughout the test. When Global Routing is set to Config, rule changes can alter where traffic goes.
- DOMAIN-SUFFIX / GEOIP / IP-CIDR: These keywords match different kinds of rules; they are not battery settings for reducing CPU usage.
- FINAL: Handles traffic that did not match any preceding rule. Changing this fallback can alter the path for a large amount of traffic, so don’t change it at the same time as On Demand when comparing results.
- Subscription updates: Update only a subscription you already have, then check whether the active connection changed. If its settings changed during the comparison, record a new baseline.
Latency tests, subscription refreshes, and active diagnostics generate network requests. They can help pinpoint a problem, but shouldn’t run throughout a standby comparison. Perform any necessary checks first, then leave a period with no active testing.
Choose whether to enable On Demand based on how you use it
Base your choice on whether you need the connection to resume automatically and whether the trigger conditions accurately match your use case. If some network requests need to follow your current configuration consistently, don’t disconnect at random just to get a lower battery reading. If you use the connection only at specific times, manual control can make it easier to see when it is active.
| Use case | Option | What to verify |
|---|---|---|
| Connect only for specific tasks | Turn off On Demand and connect or disconnect manually from Home | After the task, the VPN status is as expected and essential tasks still work |
| Frequently switch between Wi-Fi and cellular | Configure On Demand network conditions as needed | The connection recovers after switching networks, without repeated rapid reconnects |
| Connect only when certain requests occur | Check the relevant domain conditions in On Demand | The target request triggers the expected behavior; keep in mind that caching and existing connections can affect the test |
| Unexpected battery drain during overnight standby | First compare On Demand on and off with the same connection, then add a disconnected baseline if needed | Use the full-device battery chart, background transfers, and error records together |
Bottom line: Keep automatic connections you need and avoid unnecessary repeated triggers
Keep On Demand enabled if it reliably meets your connection needs without repeated reconnects. If turning it off only reduces unnecessary connection time, switch to manual control. If battery use is high either way, investigate actual traffic, network quality, and connection settings instead of repeatedly toggling the switch.
Shadowrocket is a paid client for Apple platforms, primarily iPhone and iPad. Check the App Store listing for device compatibility and system requirements. The app is a one-time purchase; buying the app does not include a service plan. This guide covers checks for configurations you already have and does not provide, sell, or recommend servers or subscriptions.