Troubleshooting Clash Mobile Battery Drain and Background Optimization
Clash battery drain on mobile usually traces back to background keep-alive, global routing, and log levels. Per-platform fixes and a troubleshooting order.
First, a Reality Check: Battery Stats Overstate the Number
Keyword: battery attribution. Android and iOS battery stats share one trait: any traffic passing through the VPN tunnel has its network power cost charged to the VPN app. Clash works as a VPN on mobile — Android via the VpnService API, iOS via Network Extension — so every byte from video calls, short-video apps, and map navigation passes through the Clash tunnel, and the cost of modem wake-ups and radio transmission all gets attributed to Clash. The process's own CPU usage is usually just a fraction of the reported figure.
Two metrics tell you whether the drain is real. On Android, go to Settings → Battery → App battery usage, tap the Clash entry, and check its foreground and background CPU activity time. On iOS, go to Settings → Battery and look at the background activity duration under the Clash row. With rule mode running all day, Clash's own CPU time is typically just a few minutes, and a share hovering around 5% is normal. Only when the share stays above 15% for several days in a row, with CPU time measured in hours, do you need to investigate further.
Expectation bias should also be ruled out. Once a proxy runs permanently, usage habits tend to shift with it — you browse more content outside China, and battery life naturally shortens. The rigorous approach is a half-day control test: turn Clash off, keep a similar usage intensity, compare screen-on time and standby drain, confirm the gap actually exists, and only then decide whether to tweak settings.
How to Read the Numbers
The percentage in the battery ranking is an attributed share, not process power draw. To judge whether Clash is misbehaving, go by CPU activity time, not the percentage ranking.
Background Keep-Alive: Balancing Battery Savings Against a Stable Connection
Keyword: battery optimization whitelist. The most common conflict on mobile: the system kills background apps to save power, and a killed tunnel means a dropped proxy; the client fights back with more aggressive keep-alive, which itself costs power. The right fix is not to make Clash keep itself alive more aggressively, but to take it off the system's power-saving list so the system leaves it alone.
The standard move on Android is adding Clash to the battery optimization whitelist. Path: Settings → Apps → Special app access → Battery optimization, find Clash, and set it to "Don't optimize." Once whitelisted, the system no longer restricts its background networking or wake-ups, and the foreground service alone is enough to keep the tunnel stable — no extra tricks needed.
Chinese Android skins add a second layer of restrictions. On Xiaomi's MIUI, you also need to enable "Autostart" and lock the Clash card by pulling it down in the recents screen. On Huawei's EMUI, open "App launch management," turn off automatic management, switch to manual, and allow background activity. OPPO and vivo use different setting names but the same logic: allow background running and allow high background power usage. Skip this step, and the whitelist alone won't stop the ROM's own cleanup policies.
Don't disable the persistent notification. Clash's VPN notification is a foreground-service notification — Android's compliant keep-alive mechanism. If you revoke notification permission entirely because it looks cluttered, the foreground service gets demoted, the process gets killed and restarts over and over, and each restart rebuilds the tunnel and re-handshakes — which costs more power, not less.
There is no manual keep-alive on iOS. Network Extension is managed by the system, and tunnel start/stop is left to system scheduling. Just keep On Demand enabled in Clash Plus — the system brings the tunnel up when network access is needed and suspends it when idle, which saves far more power than toggling it manually all the time.
Battery-Saver Tools Conflict with VPNs
"Battery master" and "background cleaner" tools treat VPN tunnels as cleanup targets. Killing the tunnel triggers a client reconnect, and the kill-reconnect loop burns power. If you have such a tool installed, add Clash to its ignore list first — or simply uninstall it; the built-in battery management is already enough.
Routing Mode and Rule Sets: Where Matching Overhead Comes From
Keyword: rule mode. Routing mode decides how much traffic goes through encrypted forwarding, and it is the single biggest factor in power draw. In global mode, all traffic enters the proxy — every byte gets encrypted and forwarded — so it drains the most and is only suitable for temporary connectivity checks. Rule mode lets sites in mainland China connect directly and only proxies traffic that matches a rule; it should be your everyday default. Direct mode effectively turns the proxy off and is outside this discussion.
More rules are not better. Every new connection is checked against the rules one by one, and tens of thousands of GEOSITE rules mean CPU overhead on every match. The rule set bundled with a subscription config is usually enough — don't stack third-party mega lists on top. Double the rule count and you double the matching cost, while the benefit is often imperceptible.
Use fake-ip for DNS. In redir-host mode, proxied domains must be resolved with real DNS before rule matching, and every resolution is a network round trip plus a modem wake-up. fake-ip mode returns a fake address from a reserved range directly and hands the domain to the remote side for resolution as-is, skipping the local resolution wait and wake-up. Enabling it is recommended on mobile.
Don't pile up DNS upstreams. With seven or eight upstreams in nameserver, every concurrent query sends packets to each of them, waking the radio over and over. Two or three low-latency upstreams are enough — for example, your carrier's DNS plus one public DNS.
mode: rule
log-level: warning
dns:
enable: true
enhanced-mode: fake-ip
nameserver:
- 223.5.5.5
- 119.29.29.29You can merge this snippet into the override section of your subscription config, or fill in the matching items one by one on the client's settings page. Reload the config for the changes to take effect.
Logging and UI Refresh: Two Easily Overlooked Factors
Keyword: log level. With log-level set to debug or info, every connection's setup, matching, and teardown writes a log line, and frequent file writes and wake-ups are real power costs on mobile. Keep it at warning or error for daily use; only switch back to info temporarily when troubleshooting, then set it back.
Keeping the UI open costs power too. The connections panel and log panel refresh in real time; watching connections scroll by keeps both CPU and screen awake. Close it when you're done — don't leave the client in the foreground for long stretches.
Rein in automatic latency testing. Some clients periodically test every node by default; a short interval means pinging the entire node list on a schedule, sending a probe to each of dozens or hundreds of nodes. Turn auto-testing off, or stretch the interval to 30 minutes or more — manual testing is enough for everyday node picking.
Per-Platform Battery-Saving Checklist
A table with the conclusions first, then platform-by-platform details:
| Setting | Battery-friendly choice | Why |
|---|---|---|
| Routing mode | Rule | Global mode encrypts and forwards everything — the highest drain |
| DNS mode | fake-ip | Skips local real-resolution round trips |
| DNS upstreams | 2–3 | Every upstream gets a packet on concurrent queries |
| Log level | warning / error | debug and info log every connection |
| Auto latency test | Off or ≥30 min | Periodic probes hit the entire node list |
| Battery optimization | Whitelisted | Prevents system kills that cause repeated reconnects |
Android (Clash for Android / FlClash)
- Keep routing mode on Rule; switch to Global only temporarily for troubleshooting.
- Set the log level to warning; bump to info temporarily when troubleshooting.
- Turn off auto latency testing, or stretch the interval past 30 minutes.
- Configure the battery optimization whitelist and ROM background permissions as in the previous section, and leave keep-alive to the foreground-service notification.
- When you don't need the proxy, disconnect inside the client instead of swiping the card away to kill the process — the rebuild cost of a kill-and-restart is higher than just staying resident.
iOS (Clash Plus)
- Keep On Demand enabled and let the system schedule tunnel start/stop.
- Rule mode plus fake-ip, for the same reasons as on Android.
- Set the log level to warning or error.
- In Low Power Mode, the system throttling background network activity is normal — don't repeatedly restart the tunnel by hand because of it.
Standard Troubleshooting Order
When battery drain shows up, follow this fixed order, changing one variable per step and observing for half a day to a full day after each change:
- Check CPU and background activity time in battery stats to confirm whether it's real drain or inflated attribution.
- Check the routing mode; switch Global back to Rule.
- Drop the log level to warning and turn off auto latency testing.
- Trim DNS upstreams and rule sets, and confirm fake-ip is enabled.
- Verify the battery optimization whitelist and ROM background permissions, and keep the persistent notification on.
- Run a half-day control test; if it's still abnormal, temporarily set logging to info, capture a segment, and report it to the client project along with your device model and OS version.
The vast majority of cases return to normal by step three. Drain genuinely caused by client defects is rare, and following the order saves you from flailing back and forth.