Clash Battery Drain on Mobile: Android Background Settings and iOS VPN Options

Identify the source of battery drain: tunnels, app traffic, and background tasks

A VPN icon that stays in your phone’s status bar doesn’t mean the proxy core is running at full capacity. Android clients typically use the system VPN interface to create a virtual network interface and route traffic through the core. Compatible iOS clients usually run through a Network Extension packet tunnel. Actual battery use also depends on data volume, repeated reconnections, and cellular signal quality.

Here, “Clash on mobile” refers to Android clients using the Clash or mihomo core, as well as iOS clients that support compatible subscriptions or rule formats. These aren’t all the same app. In particular, don’t assume an Android client’s settings menu, TUN switch, or YAML fields apply to iOS.

Tunnel processing: Routing traffic through a virtual interface, matching rules, and encrypting or decrypting protocols adds processing overhead. The impact is more noticeable when streaming video, downloading files, or using a hotspot.
App activity: Cloud photo backups, message syncing, and short-video preloading can all use the tunnel, even when routed directly. A DIRECT rule doesn’t necessarily bypass the system VPN layer.
Scheduled tasks: Node health checks, subscription refreshes, rule downloads, and retry attempts wake the network. The more frequent these tasks are, the less time the phone spends in a low-power idle state.
Wireless activity: Weak signals, switching between Wi-Fi and cellular, and repeated connection setup can all keep the wireless radio active for longer.

Run a two-hour idle comparison before changing settings

Start with a short, controlled comparison before changing background settings. On Android, check Settings → Battery → Battery usage. On iOS 18, go to Settings → Battery to review the charge graph and app activity. Menu names vary by manufacturer; if you can’t find the option, search Settings for “Battery usage.”

Keep test conditions consistent: Use the same location and network each time, and start at roughly the same battery level—for example, around 80%. Pause system updates, photo backups, and large downloads.
Record a baseline: Turn off the tunnel during a period when you don’t need a proxy. Leave the phone locked and idle for two hours, then record the starting and ending battery levels, background activity, and network conditions.
Test the current setup: Restore the tunnel and your usual rules, then repeat the two-hour locked-screen test. Don’t change the node, speed-test interval, and system battery settings all at once.
Retest one change at a time: Either extend the automatic speed-test interval or adjust one background restriction. Keep everything else the same and repeat the test at least twice.

For example, if one test goes from 80% to 78% with the tunnel off and from 80% to 75% with it on, the difference between those runs is three percentage points. That alone doesn’t prove TUN is the cause. These figures are examples, not measurements from this site or universal benchmarks. If the second run included a weak-signal reconnect or photo sync, the comparison isn’t meaningful.

Record these six details for each test

Phone model, OS version, client version, and the core version shown in the client.
Test start and end times, and battery percentages.
Wi-Fi or cellular connection, and whether the signal was stable.
Tunnel status, rule mode, and selected node.
Automatic speed-test interval, subscription update interval, and rule-set update interval.
Whether the phone disconnected or reconnected, delayed notifications, or heated up while the screen was locked.

Keep Android clients running in the background: adjust battery settings based on disconnections

Exempting an app from battery optimization can help when the system is stopping its background process. It won’t reduce the cost of processing proxy traffic. If the connection remains stable with the screen off, there’s no need to remove every background restriction. If the network drops after the screen has been locked for a few minutes, check the client’s background permissions.

Android 14: a step-by-step checklist

Go to Settings → Apps → See all apps → select the client → App battery usage. Some devices call this “Battery.” First, check whether background usage is allowed.
If the connection drops while the app is set to “Restricted,” switch to “Optimized” and test again. If it still gets interrupted and needs to stay connected, try “Unrestricted.” The available options depend on your Android version.
Check that the client’s persistent VPN notification is enabled. Android foreground services usually need an ongoing notification. Hiding the notification isn’t a battery-saving measure, and a hidden notification doesn’t tell you whether the service is still running.
Some manufacturers add settings such as “Auto-start,” “Background activity,” or “Lock app.” Enable them only for clients that need to stay active. Don’t remove restrictions from unrelated apps at the same time.

To check the system VPN settings on stock Android, go to Settings → Network & internet → VPN and select the client. If “Always-on VPN” and “Block connections without VPN” are enabled, the whole device may lose internet access when the client stops. That may be expected protection, not a failed node. Note the original state of both settings before troubleshooting.

Choosing between TUN and per-app proxying

Unlike desktop browsers, regular Android apps typically don’t all use the HTTP proxy port configured in a client. So turning off VPN/TUN while leaving a local listening port enabled doesn’t mean the whole phone can still access the internet through the rules. Keep the tunnel enabled for device-wide coverage. If only a few apps need the proxy, check whether the client supports per-app include or exclude lists through Android VPN.

Per-app exclusions and YAML direct rules work at different levels. If supported by the client and system, an exclusion lets a selected app bypass the VPN. A direct rule typically routes traffic out directly after it reaches the core. After changing the app list, reconnect as directed by the client and test your browser, messaging, and payment apps separately.

Reduce wake-ups from automatic speed tests and rule updates

“Speed test” can mean at least two things: latency checks and download-throughput tests. Latency checks use little data, but testing many nodes at short intervals can still generate a lot of connections. Download tests transfer real data, so they’re even less suitable for frequent background use. First turn off any extra client-side cycles that test every node, then check for health checks and automatic groups in your subscription.

Try changing the interval from 60 to 600 seconds

Suppose a provider has 100 nodes and checks every node in each cycle. At a 60-second interval, that’s about 6,000 checks per hour; at 600 seconds, about 600. These are example request counts based on the node count and interval. Lazy checks, retries, and client scheduling affect the actual total, so the figures can’t be translated directly into battery savings.

For mihomo configurations that support these fields, adjust the following under health-check in an existing proxy-providers entry. Keep the working probe URL already in your config. This is a snippet, not a complete, standalone configuration.

health-check:
  enable: true
  interval: 600
  lazy: true

interval is measured in seconds. lazy: true reduces scheduled health checks when a provider isn’t in use; it doesn’t stop traffic on an active connection. If your config also uses url-test or fallback groups, check their probe settings separately. Provider checks and policy-group checks may both be running, so changing just one may not stop duplicate probes.

Schedule the three update tasks separately

Task	Starting point	Notes
Node health checks	600 seconds	Shorten the interval only if switching becomes too slow; there’s no need to test every node every minute.
Automatic subscription updates	Once a day	Adjust to how often your provider makes changes, and avoid refreshing through both the client and a script.
Remote rule-set updates	86400 seconds	Only applies to configurations that support this field. Don’t confuse it with the subscription update interval.
Download speed tests	Run manually when needed	Speed tests download real data, so they’re not suitable as an always-on keep-alive task.

Subscription updates may overwrite local changes. Prefer the client’s override or merge feature, and check the effective configuration after updating a subscription. If the same rule URL fails to download every few seconds in the logs, fix the URL or network route instead of simply extending every update interval.

iOS VPN On Demand: distinguish leaving the app from stopping the tunnel

An iOS client’s main app and its system-managed tunnel extension are separate components. The tunnel doesn’t stop just because the app isn’t in the foreground, and repeatedly swiping the app away from the app switcher isn’t a reliable way to save battery. Check the connection status in the client, then go to Settings → General → VPN & Device Management → VPN to review the active configuration.

VPN On Demand works best when network conditions are clearly defined

VPN On Demand uses rules configured by the client to connect or disconnect the VPN when network conditions match. It doesn’t simply disconnect when the screen turns off. Whether rules can be based on a Wi-Fi name, network type, or domain depends on the client. Don’t assume an “On Demand” switch has suitable conditions configured by default.

Need a proxy all day: Keep the connection active to start with, reduce frequent speed tests, and observe idle battery use on a stable network.
Use a proxy on specific networks only: If the client supports it, configure On Demand rules for clearly defined Wi-Fi or network conditions, then check what happens after leaving that network.
Use it occasionally: Connect manually when needed, then disconnect in the client when you’re done. This is easy to verify, but background apps will use the regular network afterward.

If the VPN reconnects right after you tap “Disconnect,” an On Demand rule may still match; the button may be working as intended. To pause the VPN, also check whether On Demand is enabled for that configuration. Conversely, Low Power Mode and Background App Refresh don’t replace VPN On Demand rules. Don’t enable background refresh for every app just to keep the tunnel running.

Narrow down settings based on symptoms, and keep a record you can revert

Network drops after locking the screen, but idle battery use is low

First check Android background restrictions and Always-on VPN, or whether the iOS On Demand rule is actually being triggered. Once the connection is stable, compare battery use. Don’t repeatedly restart the tunnel while testing battery life—reconnecting itself generates network activity.

The phone stays warm with the screen locked, and logs keep updating

Look for repeated speed tests, failed rule downloads, node reconnections, and DNS timeouts. Set the log level back to the client’s normal default, and turn off continuous packet capture and debug logging. Keep only the short-term logs you need for troubleshooting. Fix the DNS resolution path instead of hiding the problem by disabling traffic routing.

Battery drain is noticeably worse on cellular only

At the same location, compare signal strength first, then test using a single stable node. Don’t change the TUN stack, MTU, DNS mode, and protocol at the same time. In particular, don’t copy an MTU value just because of battery drain. If the issue occurs only during large downloads, note the speed, temperature, and number of reconnections, then troubleshoot the network further.

Checklist for verifying your changes

After 30 minutes with the screen locked, the apps you need can still connect and receive notifications.
After switching between Wi-Fi and cellular, the connection resumes or stops as expected.
After one subscription update, the speed-test interval and custom rules are still in effect.
Complete two two-hour idle tests under the same conditions; don’t rely on a single battery percentage reading.
Record each setting you changed. If the benefit isn’t clear, restore its original value instead of piling on more changes.

A good long-term setup keeps connections stable, limits background tasks, and makes behavior easy to explain. On Android, add the client to the battery optimization exemption list only if it disconnects with the screen locked. On iOS, enable On Demand only if it fits your usage and what you need to happen when disconnected. Reducing unnecessary work first usually makes the cause easier to find than enabling every permission at once.