Clash Android Battery Drain Explained: Background Keep-Alive, TUN Mode, and OEM Power-Saving Trade-offs

Classify the Drain First: Real Consumption or Perceived Bias

Feeling that your phone runs "hotter and drains faster" after enabling a proxy on Android doesn't necessarily mean the proxy app is the culprit. Start with a basic distinction to avoid chasing the wrong lead. Open the battery usage stats in system settings and check whether Clash-type apps consume a noticeably higher share than other persistent apps (chat apps, mail clients). If the share is in the low single digits, it's likely normal proxy-forwarding overhead. If it consistently ranks in the top three and stays high even with the screen off, that's when it warrants further investigation.

Also separate "battery drain" from "heat." Heat is usually short-term high load — right after importing a subscription, or during a batch latency test on nodes. Drain is a long-term cumulative cost, mainly reflected in behavior while running in the background. This article focuses on drain during sustained background operation, not brief high-load heat spikes.

Three Main Drain Sources: Wake-ups, TUN, Rule Matching

Background Wake-up Frequency

To keep the proxy service and established connections alive, Clash-family clients get flagged by the system as processes that need to persist. If the client itself or the system scheduler frequently wakes the CPU for heartbeat checks, connection keep-alive, or subscription expiry checks, that adds up to meaningful drain even without actual traffic flowing. This is most visible overnight when the phone sits idle — battery drops noticeably faster than without the proxy installed, which usually points straight to wake-up frequency.

System-Level Takeover in TUN Mode

TUN mode sets up a virtual network interface at the system network layer, routing all app traffic on the device through the Clash core for processing before forwarding it per rule. This global takeover has broad coverage and good compatibility — almost no app can bypass the proxy — but the cost is an extra layer of encapsulation, decapsulation, and rule matching for every packet. On Android, TUN mode also interacts with the system's VPN service framework, and that interaction alone carries a fixed resource cost. Mobile CPUs and thermal headroom are far more limited than desktops, so this overhead shows up amplified as drain and heat.

Rule Set Size and Matching Complexity

Rule-based routing compares each connection's target domain or IP against the rule list entry by entry. The larger and more layered the rule set, the longer each match takes. Some subscriptions ship with rule sets containing thousands of entries plus multiple remote rule-providers, and the client needs to pull updates for these on a set schedule in the background — the fetch and parse process itself consumes CPU and network. Loading several large rule sets at once noticeably raises the background maintenance cost.

Trade-offs in Background Run Policy

Android's background management mechanism balances "keeping apps alive" against "limiting background drain," and proxy apps sit right at the friction point between the two: a proxy needs to hold connections in the background long-term to stay effective, but the system's power-saving policy tends to restrict background processes. There's no universally correct setting here — only trade-offs based on your scenario.

1. Light everyday use: If you're just browsing or reading news and don't need the proxy holding a connection year-round in the background, manually disconnect the proxy service when not in use to cut down wake-up frequency — this is the most direct way to save power.
2. Scenarios requiring a persistent connection (e.g. keeping push notifications alive, long idle sessions): add the client to the system's background whitelist to let it bypass power-saving restrictions, while accepting the corresponding battery cost — this is a deliberate trade-off, not a bug.
3. Using the proxy for specific apps only: if the client supports per-app rules or routing by package name, route only the apps that genuinely need the proxy through the TUN tunnel and let everything else connect directly, which significantly cuts overall rule-matching and forwarding load.

Match the setting to your actual usage pattern rather than applying the most aggressive or most conservative setting across the board regardless of scenario.

Rule Trimming: Reducing the Background Footprint

Many subscription-bundled rule sets are designed as "all-encompassing," covering a huge range of niche scenarios. For most users, trimming these rule sets directly reduces background matching and update overhead. Here are a few actionable directions:

• Check how many rule-providers are loaded in the client and merge or remove category rule sets you rarely use (for example, rules for a specific regional service you barely visit).
• Extend the update interval for rule sets — there's no need to pull updates daily; most rule sets don't actually change that often, and an interval of 3–7 days is usually sufficient.
• Reduce the number of simultaneously loaded policy groups — automatic latency testing (url-test) inside a policy group periodically fires probe requests, so more groups means more scheduled background tasks.
• Make sure no duplicate rule sets are pulled in from multiple subscription sources — duplicates slow down matching without adding any real benefit.

rule-providers:
  reject:
    type: http
    interval: 259200   # update every three days instead of the default shorter interval
    behavior: domain

After adjusting rule sets, compare battery usage over a day or two before deciding whether to trim further — cutting too much at once can cause traffic that should have been proxied to leak through.

Whitelist Settings Under Common OEM Power-Saving Policies

Mainstream Android OEM skins layer their own power-saving and process-management policies on top of stock Android. These policies often kill the proxy service process without the user noticing, causing the proxy to "drop for no reason" or restart repeatedly to stay alive — which ironically drains more battery. The table below lists common setting locations; exact menu wording may vary slightly by OS version:

After whitelisting the client, background kills and connection drops become noticeably less frequent — but understand that this trades battery life for stability, and it works against the power-saving policies in the previous section. The reasonable approach: whitelist it if you genuinely need it running long-term; otherwise keep the system's default power-saving limits and turn it on manually when needed.

When to Consider Skipping TUN Mode

TUN mode isn't the only option. If heat and drain are already noticeably affecting daily use, consider switching to system proxy mode instead (configuring the proxy address individually in the apps or browser that need it), trading some coverage for lower system-level overhead. Under system proxy mode, only apps explicitly configured to use the proxy get routed through it, while everything else is completely unaffected — the total matching and forwarding volume drops considerably.

This trade-off fits scenarios where you only need the proxy in a browser or a handful of apps, the device itself is lower-powered and heat-sensitive, or you're only using it temporarily rather than aiming for full coverage. Conversely, if you need to cover every app on the device (for example, some apps have hardcoded domain checks and break when bypassing the global proxy), TUN mode is still the safer choice — in that case, the battery cost is a cost you have to accept, and effort should go into the rule trimming and whitelisting covered earlier, rather than debating whether to use TUN at all.

A Complete Troubleshooting Workflow

1. Open the system battery usage stats and confirm whether the drain share is actually abnormal (see the diagnostic criteria in the first section).
2. Check whether TUN mode is enabled; try switching to system proxy mode for a day as a comparison and observe the drain difference.
3. Take stock of the currently loaded rule sets and update intervals; trim categories you rarely use and extend the update cycle.
4. Check the probe frequency of automatic latency testing inside policy groups and cut unnecessary scheduled probes.
5. Confirm whether the OEM power-saving setting is reasonable: whitelist it if you need long-term background operation, otherwise keep the system default restrictions.
6. Watch the battery curve over the following day or two to confirm drain has returned to a reasonable range before deciding on further adjustments.

Following this order will usually pinpoint the drain to a specific step rather than vaguely blaming "the proxy software." In most cases, the root cause is an oversized rule set or overly frequent background wake-ups — adjusting these two is usually far more effective than debating whether to use TUN mode.