Noticing faster battery drain after enabling Clash on mobile? Diagnose the cause across rule complexity, keep-alive connections, log level, and background policy, with actionable fixes.
When users report unusual battery drain on mobile, don't jump straight to tweaking a single setting. First split the cause into two rough categories: the core itself "doing too much" — too many rule entries, a high log level, or a long request-processing chain, forcing the CPU to do extra work on every connection; or the app "running too long" — the system should be suspending or throttling the process, but due to poor keep-alive settings or an incorrect battery-optimization whitelist, the Clash client keeps running at normal priority even after the screen locks. These two causes combined are the real reason behind most "phone gets hot and battery drops fast with the proxy on" reports. Below we break it down across four areas — rule complexity, connection keep-alive, log level, and background policy — and recommend checking them in order rather than changing everything at once, so you can tell which fix actually made a difference.
Every time Clash or the Clash Meta (mihomo) core processes a flow, it matches rules top to bottom until one hits or it falls through to MATCH. The more entries in the rule file and the later a match occurs, the more CPU cycles a single match burns. Mobile devices constantly generate scattered short-lived background connections (push heartbeats, analytics pings, image preloading, etc.), and if each one has to run through hundreds or thousands of rule lines before its route is decided, the cumulative power cost adds up.
GEOIP and rule sets (RULE-SET) over hand-written domain rules listed one by one — rule sets use internal indexing and match far more efficiently than a linear list.Note
Don't dump every domain into one giant hand-written rule file placed at the very end "for convenience" — this forces most traffic to run through the entire rule chain before it lands, and it's one of the most common hidden causes of battery drain on mobile.
To reduce latency and avoid frequent reconnects, some nodes or clients enable TCP Keep-Alive or app-layer heartbeats, sending small packets periodically to keep connections alive. This has limited impact on Wi-Fi, but on mobile networks, each heartbeat can wake the baseband modem from sleep — and waking the baseband costs far more power than the heartbeat data itself. If the client uses a short idle timeout or a high-frequency heartbeat interval, connections left running in the background will keep waking the device, causing the classic "battery keeps dropping fast even with the screen off" symptom.
The log level controls how much detail the core records while running, typically ranging from low to high as silent, error, warning, info, and debug. The higher the level, the more content the core has to format, write, and possibly rotate — this I/O and string processing also eats into CPU and storage write bandwidth on mobile devices, making it an easily overlooked drain on battery. Unless you're actively troubleshooting, running debug level long-term isn't recommended.
| Log Level | Output | Best For |
|---|---|---|
silent | No log output | Everyday long-term use, prioritizing battery life |
error | Errors only | Everyday use, with some ability to trace issues |
warning | Errors and warnings | Occasional issue troubleshooting |
info | Connection setup and rule-match overview | Temporary debugging of routing issues |
debug | Full call-chain detail | Short, deep-dive troubleshooting — turn off right after |
log-level: silent
Changing log-level in your config from debug or info back to silent or error is one of the simplest and most effective power-saving moves, and it barely affects the day-to-day experience for most users.
Android relies on the VpnService interface to create a virtual network adapter that intercepts system-wide traffic, which means the Clash client has to run as a long-lived background process to keep the proxy connection alive. But manufacturer-customized systems (especially those from Chinese device makers) apply more aggressive sleep, freeze, or even force-kill policies to background processes for the sake of overall battery life. If Clash isn't added to the battery-optimization whitelist or autostart list, the system may periodically freeze the process and then wake it to rebuild the connection — this repeated "freeze and reconnect" cycle is itself a major battery drain, and it often comes with noticeable connection drops and stutter.
Work through the four checks above in order — trim rules first, then adjust keep-alive settings, then lower the log level, then fix the background whitelist — and watch the battery curve for half a day to a full day after each change. This makes it much clearer which fix actually matters for your device, instead of changing everything at once and losing track of the root cause.
TUN mode intercepts system-wide traffic, so in theory it handles more connections than just setting a system proxy. If the drain started right after enabling TUN, try switching back to system proxy mode to compare. But TUN mode itself isn't inherently more power-hungry — the real factors are still rule complexity and whether the keep-alive policy is sensible.
A node's own latency and packet loss affect how often the client reconnects — high-latency or unstable nodes tend to trigger frequent retries, which indirectly increases battery drain. Pick a stable, low-latency node first, then apply the four fixes above together.