Troubleshooting 12-minute read

How to Troubleshoot Excessive Clash Battery Drain on Android: Background and Battery-Saving Checklist

Find the main sources of mobile battery drain—latency checks, complex rules, persistent TUN, and manufacturer background limits—with practical settings to keep connections stable while using less power.

Clash clients on Android typically take over traffic through the system VPN interface. Once the key icon appears in the status bar, the app must continuously handle connections, DNS queries, and rule matching, so long-term background activity in battery statistics is normal. What needs investigation is abnormal drain: more than 5% lost during one hour of standby, persistent heat, over 15% lost during an eight-hour night, or repeated restarts after switching networks.

Battery usage should not be judged solely by an app’s percentage in the system battery list. If the phone uses only 4% overall during a period and Clash accounts for 30% of that, the actual drain is about 1.2 percentage points. If total drain reaches 25%, the same share deserves priority. Before troubleshooting, record total battery level, screen-on time, network type, and test duration, then change one setting at a time.

First determine whether the draincomes from the client or the network

Separate the problem with three tests

The most effective approach is not an immediate reinstall, but three controlled comparison tests. Run each for at least 45–60 minutes, keeping brightness, network conditions, and foreground apps the same.

  1. Clash off: Record baseline system drain and check whether mobile signal, Wi-Fi, or other apps are abnormal.
  2. Clash on, standby only: Do not play video or run speed tests; observe the additional drain caused by the persistent VPN.
  3. Clash on during normal use: Browse the web, send messages, or play video at a fixed quality to observe high-traffic behavior.

For example, if the phone loses 1.5% per hour with Clash off and 2.2% in standby with it on, the 0.7-point difference is usually acceptable. If drain reaches 6% per hour and the device warms from 30°C to 38°C, check latency tests, connection retries, logs, and DNS. With only one or two bars of mobile signal, the modem increases transmit power, so the phone may drain noticeably even with the proxy off.

Review Android battery statistics

On stock Android and Pixel devices, open Settings → Battery → Battery usage, then select the client to view foreground and background time. Some systems report the last 24 hours, while others report usage since the last full charge. Always compare data over the same reporting period.

  • Long background time but little hourly battery change: the VPN service is usually running normally in the background.
  • Long background time combined with rising CPU activity and temperature: check speed tests, logging, and reconnections first.
  • Low Clash percentage but high “Mobile network standby”: address signal coverage first.
  • Frequent disconnects with the screen off: this is usually caused by manufacturer background restrictions, not necessarily sustained high kernel load.

Latency test intervalsand proxy-group checks

A client’s “automatic speed test” is not a one-time action. URL-Test, Fallback, and Load-Balance groups can access test URLs at fixed intervals to measure node latency or availability. If a subscription has 80 nodes and three proxy groups check them independently, one round can create hundreds of connections. With a 30-second interval, the network and CPU keep waking up during standby.

Set check intervals to practical values

For everyday mobile use, start with 600 seconds, or 10 minutes. If the network rarely changes, increase it to 900 seconds. A Fallback group that needs fast failover can stay at 300 seconds, but do not run every proxy group at 30 or 60 seconds. Clicking “Test all” also creates many connections at once, so avoid repeated clicks while troubleshooting.

proxy-providers:
  mobile-nodes:
    type: http
    url: https://example.invalid/subscription
    interval: 86400
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600
      lazy: true

interval: 86400controls the subscription-provider update interval in seconds; interval: 600 under health checks controls node testing. They serve different purposes. mihomo supports lazy: true to reduce proactive checks for unused providers, but both the client version and configuration format must support the field.

Reduce duplicate automatic-selection groups

Check whether multiple URL-Test groups contain the same nodes. If “Auto Select,” “Streaming Auto,” and “Download Auto” all cover every node, each group maintains its own health-check state. On mobile, keep one general-purpose automatic group and use fixed nodes or longer intervals for special services. Reducing the node list from 120 to the 15–30 you actually use also lowers the size of each probe cycle.

Persistent TUNand system VPN overhead

TUN on Android clients usually runs on the system VpnService. The app reads packets from the virtual network interface and passes them to the mihomo core. Unlike an HTTP proxy assigned to one app, TUN covers more apps and protocols, so the background service must remain active. However, most Clash-style Android clients already depend on the VPN interface. The meaning of a “TUN” switch varies by client implementation and should not be treated as the desktop system-proxy concept.

Limit the apps that need to be intercepted

If the client offers per-app proxying, app proxy rules, or access control, select only the browser, messaging apps, and apps that actually need the proxy. Banking apps, maps, camera backup, and local-network casting that should connect directly can be excluded. This reduces the number of connections handled by the core and prevents some apps from repeatedly retrying after detecting a VPN.

Before switching to whitelist mode, confirm which system components depend on proxy access. The app store, WebView, and download manager may create connections through separate system processes. After changing the setting, test web pages, file downloads, push messages, and app updates—not just browser connectivity.

Disable persistent features you do not need

  • LAN sharing: If the phone is not serving as a proxy for other devices, turn off “Allow LAN connections.”
  • External controller: If you do not use a remote panel, restrict the controller to 127.0.0.1:9090 instead of listening on every network interface.
  • Traffic panel refresh: Exit the live connections view while troubleshooting. Refreshing connections and speeds every second increases foreground CPU activity.
  • Detailed logging: Use warning or error for everyday use. Debug logging is suitable for short investigations, not for running all day.
  • Hotspot sharing: Turn off forwarding options when you are not using the phone’s hotspot proxy.
mixed-port: 7890
external-controller: 127.0.0.1:9090
log-level: warning
allow-lan: false

mixed-port: 7890 is simply a local HTTP-and-SOCKS combined port; it does not by itself cause heavy continuous battery drain. What matters is whether another app keeps accessing the port and whether the control panel continuously pulls connection data.

How to streamline rules, DNS,and sniffing

The number of rules does not translate directly into proportional battery drain. mihomo indexes rules, so tens of thousands of domain rules may not create a noticeable load once the system is stable. More common issues are frequently updated rule providers, repeated configuration reloads, DNS request loops, or conflicts between sniffing and an app’s own encrypted DNS.

Update rule providers hourly or daily

Advertising, streaming, and regional rules usually do not need minute-by-minute updates. Set commonly used rule providers to 43200 or 86400 seconds. During an update, the client downloads a file, parses it, and replaces the rules. If several providers update on short intervals at the same time, regular CPU spikes can appear during standby.

rule-providers:
  direct-list:
    type: http
    behavior: domain
    format: mrs
    interval: 86400
    path: ./ruleset/direct.mrs
    url: https://example.invalid/rules/direct.mrs

Binary rule formats can reduce the loaded file size, provided the rule source is compatible with the current mihomo version. If loading fails after import, restore a YAML, text, or mrs format supported by the client; changing only the file extension is not enough.

Check for DNS loops and duplicate resolution

A query loop can occur when the client’s DNS points to a local address while upstream encrypted DNS is mistakenly sent back to the same local port. Typical signs include repeated timeout, context deadline exceeded, or exchange failed messages in the logs, with the phone staying warm during standby. Start with the client’s default DNS settings, then add custom upstreams one at a time.

  • Standard DNS commonly uses port 53, DoT commonly uses 853, and DoH usually uses 443.
  • Bootstrap DNS must be able to resolve the DoH server hostname directly; it cannot depend on a proxy chain that has not been established yet.
  • One reliable upstream plus one fallback is usually enough; there is no need to configure a dozen servers at once.
  • After changing Fake-IP, Redir-Host, or sniffing settings, clear existing connections and restart the client.

Domain sniffing can help the core identify the domains associated with some connections, allowing domain rules to take effect. But for configurations that do not need sniffing, expanding the port range to cover every protocol may provide no benefit. If the logs repeatedly show sniff failed, restore the client’s default sniffing range and observe battery drain and rule matches for an hour.

Avoid repeated restartscaused by manufacturer background policies

Many cases of “Clash drains the battery as soon as it starts” are actually caused by the system repeatedly terminating the VPN service, after which the client is relaunched by “always-on VPN” or an autostart policy. Each full restart reloads the configuration, rules, and DNS cache. Restarting every few minutes consumes more power than staying stable and can also delay messages or cause occasional page interruptions.

Stock Android and Pixel

Go to Settings → Apps → See all apps → select the client → App battery usage, and allow background usage. If the page offers “Optimized” and “Unrestricted,” select “Unrestricted” for a one-day test when connections drop frequently. This may slightly increase background residency, but it can prevent repeated termination and restarts.

Xiaomi HyperOS

The usual path is Settings → Apps → App management → select the client → Battery saver → No restrictions. Then check Autostart in the app details or permission manager. Locking the app in the recent-apps screen only reduces the chance of cleanup; it does not replace background-policy settings. Menu labels may vary slightly between HyperOS versions.

OPPO, OnePlus, and realme

On ColorOS devices, go to Settings → Apps → App management → select the client → Battery usage and allow background activity. Also check Sleep standby optimization under Settings → Battery → More settings. If disconnections happen only overnight, test the sleep-related options first.

Samsung One UI

Go to Settings → Battery → Background usage limits and make sure the client is not listed under “Deep sleeping apps.” For a long-lived connection, add it to “Never sleeping apps.” Also check the current VPN configuration under Settings → Connections → More connection settings → VPN.

Avoid conflicting system VPN options

Android’s “Always-on VPN” suits situations where the proxy must remain active. “Block connections without VPN” is stricter: while the VPN restarts, all network access may be paused. If the client is already unstable, enabling both options makes interruptions more noticeable. During troubleshooting, disable the strict blocking option and keep the regular VPN active; restore it later if needed once the connection is stable.

Follow this orderfor the battery-saving checklist

The sequence below starts with low-risk changes whose benefits are easy to verify. After each change, observe the phone for at least 60 minutes; overnight drain requires a full 6–8 hour test.

  1. Stop repeated manual speed tests and set automatic health checks to 600 seconds.
  2. Set the subscription update interval to 86400 seconds and rule-provider updates to 43200 or 86400 seconds.
  3. Remove duplicate automatic-selection groups and limit frequently used nodes to 15–30.
  4. Change the log level from debug to warning, then exit live connections and the traffic panel.
  5. Disable LAN sharing, hotspot forwarding, and unused external-controller listeners.
  6. Enable per-app proxying and intercept only apps that genuinely need the proxy.
  7. Test with the default DNS settings to rule out custom DoH, DoT, and Fake-IP issues.
  8. Allow the client to run in the background in system settings to prevent VPN service restart loops.
  9. Test Wi-Fi and mobile data separately to identify modem drain caused by weak signal.
  10. Only then consider changing the client version or importing a streamlined configuration.

Use ADB for deeper evidence

If you are familiar with Android debugging tools, reset battery statistics first, run a fixed test procedure, and then export the results. The phone must have Developer options and USB debugging enabled; run the commands from a computer.

adb shell dumpsys batterystats --reset
adb shell dumpsys batterystats
adb shell dumpsys activity services

The first command resets the current battery statistics and should be run before testing begins. The second shows wakeups, network activity, and process activity; the third can confirm whether the VPN service is repeatedly created. Compare wakeup counts and runtime for the same client before and after changes, rather than comparing absolute values across different phone models.

Still seeing heat or battery drain?Check these anomalies

After basic optimization, if the phone still loses more than 5% during one hour of standby, review the log timeline. Repeated identical errors are usually more useful for diagnosis than the app’s percentage alone.

  • Node connection timeout: The current node is unreachable, so the client or app keeps retrying. Switch to a stable node and remove failed nodes from automatic groups.
  • Subscription parsing failed: The subscription content is incompatible with the client format, so every background update fails. Pause automatic updates first and check the subscription format.
  • Rule file download failed: The rule URL requires a proxy, but the proxy is not ready, which may create repeated requests during startup.
  • DNS timeout: Switch to a reachable upstream and check whether Private DNS, the client DNS, and the browser’s Secure DNS are all taking over resolution.
  • VPN service started repeatedly: Close other VPNs, accelerators, firewalls, or local filtering apps. Android usually allows only one VpnService to be active at a time.
  • Configuration reloaded repeatedly: Stop file-sync tools from continuously modifying the configuration directory so the client does not reload every detected change.

Export the current configuration and record reproducible conditions before updating the client. Clients such as FlClash that are based on mihomo may fix compatibility issues with core updates, but TUN, DNS, and rule behavior can differ between versions. After updating, test a basic subscription first instead of immediately layering on every experimental setting from the previous version.

The goal is not to make Clash disappear entirely from the system battery page, but to keep background activity steady and low: no persistent heat with the screen off, no VPN restart loop, and roughly 0.5–1.5 percentage points of additional drain per hour during ordinary standby. Results also depend on battery health, 5G signal, node latency, and traffic, so compare before and after on the same phone.

Download the latest Clash version