Why Clash Drains Your Phone Battery: Background Activity, Android Battery Optimization, and Always-On TUN

Separate battery usage percentage, actual battery drain, and connection drops

Check the phone’s overall battery drop first, then review Clash’s background activity. A high percentage on the battery screen doesn’t mean the app used that same percentage of the battery’s total capacity. Systems calculate usage differently: some show each app’s share over a reporting period, while others may attribute VPN-routed activity to the relevant app. A ranking screenshot alone isn’t enough to diagnose a problem.

For example, if your battery drops from 80% to 76% and the battery screen says an app accounts for 25% of usage, that doesn’t mean the app used 25 percentage points of battery. The figures below illustrate how to test; they aren’t measurements from a specific phone or targets that every device should meet.

Persistent heat and steadily increasing data use: Check background downloads, cloud sync, video preloading, and repeated connection attempts first.
Works normally with the screen on but drops connections when locked: Check battery restrictions, background permissions, and whether the VPN service is still running.
Fast drain only on cellular: Check signal strength, network handoffs, and node reachability as well. Don’t assume TUN is the cause.
Sudden increase after a client update: Note the client and kernel versions and any configuration changes, then compare one change at a time.

Run a 60-minute screen-off comparison

Run two tests under the same conditions before changing background permissions. Use the same Wi-Fi with a stable signal, start at roughly the same battery level, and pause system updates and large backups. After changing a setting, wait about five minutes for subscription updates, rule loading, and connections to settle before starting the timer.

Record the test setup: Note the phone model, OS version, client version, kernel version, Wi-Fi or cellular connection, and whether Battery Saver is on.
Baseline test: Turn off the proxy service, lock the screen for 60 minutes, and record the starting and ending battery levels and the phone’s background data use. This is for comparison only; don’t access services that require the proxy during the test.
Proxy test: Restore the same app state, connect to a stable node, and repeat the 60-minute screen-off test under the same conditions.
Repeat in reverse order: Swap the test order and run another pair to avoid skew from a one-off event, such as a photo upload, system maintenance, or app update.

What to record	How to record it	Why it matters
Starting and ending battery	For example, 80% → 78% over 60 minutes	Compare the phone’s actual battery drop, not just app rankings
Background data	Record the difference in cumulative MB before and after the test	Distinguish standby drain from actual data transfer
Connection status	Note whether it reconnects after you unlock the phone	Identify background restrictions and unreachable nodes
Error logs	Note when timeouts occur and how often they repeat	See whether retries continue throughout the test

Battery readings are usually rounded to whole percentages, so a one-point difference over a short period isn’t conclusive. If the results are close, extend the test to three hours or compare two similar overnight periods. Don’t disable essential network services if you need to receive important notifications.

Android battery optimization: exempt the app only if connections drop

Android proxy clients typically route traffic through the system VPN interface and use a foreground service to keep running. Battery optimization exemptions reduce background restrictions; they don’t reduce the CPU work required for encryption or traffic forwarding. Setting an app to “Unrestricted” may prevent drops when the screen is locked, but it can also let background activity continue when it would otherwise be paused.

Check the app’s battery settings first

On a stock-style Android 14 device, go to Settings → Apps → See all apps → select the client → App battery usage, and check whether it’s set to “Restricted.” Depending on the OS version, the option may be called “App battery usage” or “Allow background usage.” Follow the labels on your device; not every manufacturer uses the same menu names.

Start with “Optimized” or the system default. Connect, lock the screen for 15–30 minutes, and check whether the app actually stops running in the background.
If the logs and VPN status indicate that the service was stopped, set the client to “Unrestricted” or allow background activity, then test again.
If your system has an “Auto-start” setting, enable it only if the service needs to resume automatically after a reboot. Auto-start and staying active while the screen is locked are separate settings.
Don’t remove battery restrictions for every app at once. Change only the proxy client’s settings so you can tell what made a difference.

Separate manufacturer background controls from Android VPN settings

On Samsung One UI 6, a common path is Settings → Battery → Background usage limits. Check whether the client is listed under “Sleeping apps” or “Deep sleeping apps.” Other manufacturers may offer background locking, smart power saving, or controls for apps with high background usage; names vary by OS version. “Locking” an app in the recent-apps screen doesn’t necessarily exempt it from battery optimization.

On devices that support it, go to Settings → Network & internet → VPN → settings for the relevant profile and check “Always-on VPN.” “Block connections without VPN” blocks network traffic when the VPN is unavailable, which can be useful if you need a kill switch. It isn’t a battery-saving feature. Before enabling it, test recovery after a node failure, reboot, and Wi-Fi handoff.

Always-on TUN: traffic coverage matters more than the toggle’s name

Desktop apps often offer separate “System Proxy” and “TUN Mode” options, but that distinction doesn’t map directly to phones. Android clients typically use VpnService to create a virtual network interface; even without a separate “TUN” button, the app may already be routing traffic through the VPN interface. The client determines the forwarding stack, per-app controls, and how the kernel is integrated.

The cost of leaving TUN running depends on packet volume, connection count, protocols, and encryption work, as well as how often the wireless radio wakes up. An active virtual interface doesn’t automatically mean sustained high CPU usage when there’s no traffic. Conversely, lots of short-lived connections, failed retries, or background uploads can drain the battery even in rule mode.

Use case	Suggested approach	What to check
You need proxy-dependent messages all day	Keep the VPN on and use a stable node with rule-based routing	Screen-locked notifications, recovery after a drop, and network handoffs
You use specific services only briefly each day	Turn it on when needed and stop it afterward	Related apps may lose network access when it’s stopped
Only a few apps need to use the proxy	Use a per-app include list if the client supports it	Sign-in redirects, browsers, and related system components
You must block traffic that bypasses the proxy	Keep Always-on VPN and the kill switch enabled if required	How the phone recovers from a node failure that blocks all network access

Note that a rule resolving to DIRECT isn’t the same as an app bypassing the VPN. DIRECT usually means the traffic reaches the kernel, which then connects directly to the destination. Excluding an app from the VPN may keep it out of that routing path entirely. This can reduce the traffic the VPN handles, but it also changes DNS, routing, and the network exit point—so don’t judge it on battery savings alone.

Don’t switch TUN stacks or disable necessary DNS routing just to save power. A setting that reduces usage on one phone may have no effect on another. Save your configuration before making changes, change one option at a time, and keep it only after confirming that browsing, messaging, and network handoffs still work.

Reduce health checks, DNS retries, and background logging

Start by checking scheduled tasks. Subscription updates, proxy provider health checks, and proxy group tests are separate processes. Increasing the subscription update interval won’t necessarily reduce all background requests. In particular, several automatic selection groups may periodically test many nodes even if you never run a manual test.

Set test frequency to match how you use the proxy

In a mihomo configuration, the snippet below shows part of a health-check setup. Merge it into an existing proxy provider configuration; it isn’t a complete configuration you can import on its own. interval: 1800 runs a check every 1,800 seconds, or 30 minutes. lazy helps avoid unnecessary checks when a provider isn’t in use; its exact behavior depends on the client and kernel implementation.

health-check:
  enable: true
  url: https://cp.cloudflare.com/generate_204
  interval: 1800
  lazy: true

Use a test URL that’s reachable on your current network and through your proxy route. If you change the interval from 300 to 1,800 seconds, scheduled checks run at one-sixth the previous frequency—but that doesn’t mean total battery use will drop by the same amount. Active connections, checks from other proxy groups, and app traffic still remain.

Subscription updates: If the client allows it, start with once every 24 hours rather than fetching updates every few minutes. Shorten the interval only if your subscription changes often.
Node testing: Don’t repeatedly test hundreds of nodes all at once. Keep only the proxy groups and candidate nodes you actually use.
Log level: For everyday use, switch from debug to info or warning. Enable verbose logging temporarily when troubleshooting.
Live dashboard: When you’re done monitoring, close continuously refreshing connection lists and traffic graphs. Don’t leave the screen on to compare “standby” battery use.

Troubleshoot DNS and connection timeouts

If the same domain times out repeatedly within seconds, check DNS upstream reachability, node status, and the resolution path first. Encrypted DNS doesn’t inherently use more battery; the problem is often repeated retries after an upstream becomes unreachable, or a dependency loop between DNS requests and the proxy route. Don’t remove all DNS settings just to reduce retries, and don’t disable certificate verification.

Switch to a known-good node and see whether the same errors go away. If only one app keeps making failed connections, pause its background sync and compare. Before sharing logs, remove subscription URLs, tokens, node passwords, and any access history you don’t want to disclose. Don’t include this information in public screenshots.

iOS background behavior: distinguish the app from its network extension

On iPhone, proxy apps typically use a Network Extension Packet Tunnel to handle VPN traffic. Sending the app to the background doesn’t necessarily stop the tunnel extension; conversely, allowing “Background App Refresh” doesn’t grant the VPN unlimited background runtime. Available behavior depends on the client and iOS scheduling, so Android’s battery-exemption steps don’t apply.

Check when battery use occurred: Go to Settings → Battery, review the available Last 24 Hours or Last 10 Days view, and tap the period with unusually high usage. The layout may vary between iOS versions.
Check the VPN profile: Go to Settings → General → VPN & Device Management → VPN and confirm the active connection and profile. If “Connect On Demand” is available, check its conditions too.
Separate background refresh from VPN activity: Settings → General → Background App Refresh controls when apps can refresh; it doesn’t show whether a VPN extension is active.
Check Low Power Mode: Compare results with Low Power Mode in the same state for both tests. It changes some background activity, so don’t switch it between test runs.

“Connect On Demand” doesn’t necessarily mean the tunnel starts only when you open a particular app. It may connect based on the network, domain, or other configured conditions. Frequent disconnects followed by automatic reconnects can increase the number of connection setups. If you want to connect manually, check the client’s auto-connect settings first, then stop the tunnel and make sure it doesn’t reconnect right away.

Don’t repeatedly swipe up to force-close the client in an attempt to save battery. Stop the tunnel using the client’s connection control, then check the system VPN status. If it keeps disconnecting and reconnecting, save the logs, update to a client version compatible with your iOS version, and check for other VPNs or network-filter profiles.

Choose what to keep based on the test results

The goal is to reduce unnecessary activity while keeping the connections you need—not to turn off every setting or allow every app to run in the background. After comparing results, keep changes that offer a clear benefit without breaking anything, and restore the rest.

No more drops after allowing background activity, with little change in battery drain: Keep the client’s background permission; there’s no need to remove restrictions from other apps.
Background traffic keeps increasing while the screen is locked: Identify the apps and destinations involved, and check sync, uploads, and repeated connection attempts.
Heat and battery drain occur only with one node: Test with another stable node and compare timeouts, reconnects, and network paths.
Battery use improves after reducing test frequency: Keep the longer interval and confirm that automatic switching is still fast enough for your needs.
Battery still drains quickly after stopping the proxy: Check signal strength, system updates, battery health, and other background apps instead of focusing only on Clash settings.

For basic setup, see the Getting Started guide. For rules, DNS, and traffic routing, consult the full manual. Stabilize the configuration first, then assess the real cost of keeping it active in the background. That’s more reliable than relying on an app battery ranking alone.