Android Battery Drain with Clash: Background Policy & Power-Saving Checklist

Don't blame the client yet: 3 signals to check first

You leave the proxy running overnight and wake up to find 20%–30% of the battery gone. The instinctive response is to blame the client itself. But the standing power cost of a proxy client actually comes from three measurable factors: whether the system lets it stay alive in the background, whether the network layer keeps waking up the CPU, and whether rule matching is burning extra cycles. Before touching any setting, check three signals to figure out which one is the culprit.

Signal one: open the battery detail screen in system settings and check the Clash client's "background activity time." If it's close to the full overnight duration, the system isn't restricting it — it's staying awake as intended, which is normal proxy behavior, not a bug. Signal two: look at the "wakelock count" or "abnormal app standby" flag for the same period. An unusually high count usually means the probe interval is too short or rule matching is unstable, causing repeated reconnects. Signal three: compare standby drain with the proxy off. If the difference is within 5%, the real power drain is coming from other background apps, and it's not worth fighting the client settings any further.

The system's power-saving policy is variable #1: whitelist it properly

Starting with Android's Doze mechanism, most OEM skins layer on an even more aggressive power-saving policy on top — and this is the single most common cause of dropped connections that trigger reconnect storms. The logic is simple: once the system decides an app has been in the background with the screen off for too long, it restricts its network access and CPU wakeups. When the proxy process gets frozen, traffic forwarding through the TUN virtual adapter stops; the moment the phone reconnects, the connection has to be rebuilt from scratch. That repeated rebuild cycle is the real battery hog.

Whitelist settings differ by manufacturer skin and restriction level — check each of these:

• MIUI (Xiaomi): Settings → App settings → App management → find the Clash client → set battery saver to "No restrictions," and also disable the matching restriction under "Autostart management."
• ColorOS / realme UI (OPPO/realme): Battery → App battery management → find the client → allow background activity + allow high power consumption, and disable "sleep standby optimization" for the app under "Other settings."
• OriginOS / Funtouch OS (vivo/iQOO): i Manager → App management → Permission management → High background power consumption, add the client to the whitelist; also turn off the system's built-in "Smart power saving" restriction for it.
• EMUI / HarmonyOS (Huawei): Battery → More battery settings → App launch management, switch the client to "Manage manually" and enable auto-launch, secondary launch, and run in background.
• One UI (Samsung): Settings → Battery → Background usage limits, remove the client from the "Sleeping apps" or "Deep sleeping apps" list.
• Stock Android / Pixel: Settings → Apps → find the client → Battery → set "Battery usage" to "Unrestricted."

This step is nearly the deciding factor in whether the proxy can stay alive in the background at all. Skip the system whitelist, and every other power-saving tweak inside the client is just a band-aid.

TUN mode persistence vs. power saving: the trade-off

TUN mode takes over all traffic through a virtual network adapter without needing per-app proxy settings, giving it the best compatibility — but the cost is a persistent background service that keeps watching for network interface changes. That service itself uses very little power on its own; what actually drags on the battery is a mismatched power-saving policy: the system restricts background wakeups while the TUN service needs to respond instantly to network switches (say, Wi-Fi to mobile data). The conflict gets the service killed and auto-restarted, and each restart triggers a full routing table rebuild and DNS re-resolution — that's where the power spikes come from.

If you don't actually need global transparent proxying (say, you're only routing a few specific apps), consider turning off TUN mode and switching to the system VPN interface or per-app proxy settings instead, which removes one standing network service. But if you rely on TUN for global routing or need to intercept UDP/ICMP traffic, keeping TUN on while properly whitelisting it (per the previous section) is a better trade than disabling it.

Probe interval and concurrent testing: an overlooked power drain

The url-test proxy group type pings nodes for latency at a fixed cadence, controlled by the interval field, in seconds. Many subscriptions ship with a short default (60 seconds or even less), which means the client wakes the network module and fires an HTTP request to every node once a minute. Overnight, when the phone should be in deep sleep, it instead gets repeatedly woken up by these scheduled probes — and that adds up to a meaningful chunk of battery.

proxy-groups:
  - name: Auto Select
    type: url-test
    proxies: [Node1, Node2, Node3]
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

Bumping interval up to 300–600 seconds has no noticeable impact for the vast majority of use cases, but it substantially cuts down overnight wakeups. If a proxy group has a lot of nodes, probing happens concurrently, so more nodes means longer and more power-hungry wakeups each time. There's no need to cram dozens of subscription nodes into a single auto-test group — trimming it down to the 5–10 you actually use is plenty.

Rule complexity dragging down the CPU: how to trim it

Rules are matched top to bottom in order, so the more rules there are — and the further down the match happens — the more CPU cycles get burned per new connection. A community rule set with thousands of entries, placed at the top of the rule list and relying heavily on exact string domain matches instead of categorized rule sets (RULE-SET), forces every new connection through a long matching pass. Combined with frequent connection setup from background apps keeping themselves alive or push heartbeats, that produces frequent small CPU usage spikes — and those spikes add up as part of the drain.

The trimming strategy is straightforward: move high-hit-rate rules (direct-connect domestic domains, commonly split domains) toward the top of the list to reduce the average number of comparisons; prefer RULE-SET references to well-maintained categorized rule sets instead of stacking individual domain rules one by one; and remove entries that are clearly duplicated or already covered by a rule higher up. Rule sets themselves are already optimized for loading and indexing, which is more efficient than plain-text rule-by-rule matching — fewer rules by an order of magnitude means lower matching overhead too.

The power-saving checklist

Go through these in order and you'll rule out most battery drain that isn't actually the client's fault:

1. Open the system battery settings and add the Clash client to the background-run whitelist, disabling every OEM-specific "smart power saving" or "sleep optimization" restriction.
2. Check whether autostart or secondary-launch permissions have been disabled — a frozen background process may not wake itself up even after being whitelisted.
3. Confirm whether you actually need TUN mode; when you don't need global routing, switching to app-level proxying removes one standing service.
4. Open the config file and bump the url-test proxy group's interval to 300 seconds or more to cut down scheduled wakeups.
5. Trim the node count in the auto-test group down to the few you actually use, reducing concurrent probing overhead per cycle.
6. Check the rule count and prefer RULE-SET references over raw entries, moving high-hit-rate rules toward the top of the list.
7. Compare standby drain with the proxy on versus off. If the gap is still above 10%, go back and re-verify each of the previous steps.