Clash Android Battery Drain Troubleshooting: Background Operation, Manufacturer Power Policies, and Always-On VPN

First identify what is draining the battery

A key or VPN icon in the Android status bar only means the system is maintaining a VPNService tunnel; it does not prove that the Clash core is under sustained heavy load. The mihomo core, client UI, mobile network, Wi-Fi scanning, and proxied apps may appear under separate battery categories. Before troubleshooting, turn “20% overnight drain” into reproducible data.

Run a controlled 8-hour comparison

1. Charge the phone above 80%, then close games, cloud photo backups, and system updates.
2. Record the current network type, signal strength, Clash mode, selected node, and configuration update time.
3. On the first night, keep Clash disabled, lock the screen, leave the phone idle for 8 hours, and record the percentage lost.
4. On the second night, enable Clash in the same location, using the same Wi-Fi network and node, then leave the phone idle for another 8 hours.
5. Open “Settings” → “Battery” → “Battery usage” and compare the shares for Clash, Android System, mobile network, and the main apps.

For example, if the phone drops 3% in 8 hours with Clash off and 6% with it on, treat the extra 3 percentage points as an approximate cost of the proxy path and its wakeups. If the two tests show 4% and 19%, while “Mobile network” ranks first, check weak signal and Wi-Fi disconnects before changing proxy rules.

Use system tools to observe background activity

Menu names vary by manufacturer on Android 14 and Android 15, but you can usually open “Settings” → “Battery” → “Battery usage”, tap Clash, and review foreground and background time. Background time covering most of the night is normal for an always-on VPN; warning signs include persistently high CPU use after the screen locks, a device that stays warm, or a Clash battery graph with repeated steep rises.

With an ADB setup available, you can supplement this with system statistics from a computer. The commands below do not change the client configuration:

adb shell dumpsys batterystats
adb shell dumpsys deviceidle
adb shell dumpsys connectivity
adb shell dumpsys vpn_management

Available services vary by Android version. If the last command reports that the service cannot be found, use the first two only. Focus on wakeups during the locked-screen period, network activity, and Doze status rather than drawing conclusions from a single momentary CPU reading.

Start by disabling frequent health checks and automatic updates

Many battery issues come not from normal traffic forwarding, but from the client repeatedly running URL-Test, subscription updates, or node health checks in the background. A single health check may connect to multiple nodes in a proxy group; if a group contains 80 nodes and the interval is 60 seconds, it could theoretically trigger thousands of connection attempts per hour. Timeouts and retries on a weak network keep the wireless radio active even longer.

Check proxy-group health-check intervals

Open the active configuration and look for proxy groups containing type: url-test, type: fallback, or type: load-balance. Common fields include:

proxy-groups:
  - name: Auto Select
    type: url-test
    proxies:
      - Node A
      - Node B
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 80
    lazy: true

interval: 600 means checking every 600 seconds, which is more suitable for a phone that stays connected than 60 seconds. mihomo’s lazy: true can reduce unnecessary probes when a proxy group has not been used for an extended period. Whether the client’s configuration editor preserves these fields depends on the exported YAML; some subscriptions overwrite local changes during every update.

Client menu names are not standardized. Common paths include “Configuration” → “Current configuration” → “Overrides” or “Settings” → “Subscriptions” → “Automatic updates”. If the interface only lets you set the subscription update interval, adjust proxy-group health-check intervals through the configuration provider or a local override.

Control rule-set size and DNS overhead

Clash rule matching is usually not the main source of battery drain during normal use, but oversized configurations, frequently updated rule sets, and repeated DNS fallback can still increase memory use and network wakeups. The problem often comes from loading the same rules multiple times or enabling many providers that do not participate in actual traffic decisions.

Remove duplicate rules and overly frequent updates

Open the configuration log and check how many rule-providers load at startup. The same domain list should not be duplicated as a remote rule set, inline DOMAIN-SUFFIX entries, and script overrides. Set remote rule-set update intervals according to how quickly the content changes: 12 to 24 hours is usually enough for ad or general domain lists, while daily geographic-database updates rarely provide a practical benefit.

rule-providers:
  common-direct:
    type: http
    behavior: domain
    interval: 86400
    path: ./ruleset/common-direct.yaml

interval: 86400 represents 24 hours. Rule providers are downloaded by the client or core; frequent updates wake the network and write to storage. If a configuration updates hourly but the rule file itself changes only every few weeks, extend the interval directly.

Check for DNS loops and repeated failures

Misconfigured DNS often appears as slow first loads, repeated timeout messages in the log, or continued resolution attempts while the client is idle. Fake-IP mode is useful for rule-based routing and does not inherently mean high battery use; focus instead on unreachable nameservers, repeated fallback timeouts, and the dependency chain created when a DoH hostname must be resolved before the DoH server can be reached.

• Configure a reachable bootstrap resolution path for hostname-based DoH servers.
• Avoid stacking multiple layers of similar forwarding across Android Private DNS, browser Secure DNS, and Clash DNS.
• Make sure LAN DNS is not sending requests back to Clash’s listening port on the phone.
• When the log repeatedly shows 3-second or 5-second timeouts, replace unreachable upstreams first instead of simply adding more concurrent servers.

The common mixed-port is 7890, but when an Android client takes over traffic through VPNService, apps generally do not need this port entered manually. Adding 127.0.0.1:7890 to a browser while also using the system VPN can create a confusing route. Unless you are testing a partial proxy setup, keep app traffic on a single entry point.

How to balance TUN, VPNService, and the persistent VPN icon

Clash-based Android clients usually create a virtual network interface through the system VPNService and pass traffic to the mihomo core. A persistent VPN icon in the status bar is expected system behavior. While the proxy is enabled, this service needs to remain active; forcibly hiding its notification, freezing the process, or periodically clearing background apps can instead cause the tunnel to rebuild repeatedly.

When all-day connectivity makes sense

• Messaging, collaboration, and development services need rule-based routing at any time.
• The phone frequently switches between Wi-Fi and mobile data and needs to restore the proxy path automatically.
• The configuration includes direct rules, so most mainland China traffic does not travel through a remote node.
• The client uses sensible health-check and subscription-update intervals.

If you use the proxy only briefly each day in a few fixed apps, enabling it on demand saves more battery. The value of an always-on connection is continuity, not faster speeds. When Clash is disabled, Android removes the VPN interface; when it is enabled again, existing TCP connections may need to be rebuilt. That is normal.

Standard VPN versus always-on VPN

In Android’s native settings, you can usually go to “Settings” → “Network & internet” → “VPN” → the gear icon for the relevant Clash entry to find “Always-on VPN”. Manufacturer skins may place it under “More connections” → “VPN”. Once enabled, Android attempts to keep the VPN app running; if “Block connections without VPN” is also enabled, other apps may lose all network access when Clash fails to start.

TUN mode handles a broader range of TCP and UDP traffic, making it useful for apps that ignore the system HTTP proxy. In Android clients, VPNService usually already provides the TUN integration, so do not copy the desktop approach of combining “system proxy + TUN”. If the client offers “Bypass LAN”, “Proxy selected apps only”, or “Per-app proxy”, use those options first to narrow the scope.

Background whitelist settings by manufacturer

System cleanup and continuous battery drain are opposite problems. The goal of a whitelist is to prevent the process from being terminated incorrectly, not to enable every permission. Start by allowing auto-start and background activity, then observe for 24 hours; adjust battery optimization only if the tunnel still disconnects after the screen locks.

System version, region, and device model can change menu names. If you cannot find an entry, search Settings for “battery optimization”, “background activity”, or “auto-start”. After making changes, lock the screen for 30 minutes, send a message to the phone from another device, then switch once between Wi-Fi and mobile data to confirm that the VPN icon and network connection remain continuous.

“Lock app” in the recent-apps screen can only reduce termination caused by one-tap cleanup; it does not replace the system battery whitelist. Conversely, repeatedly clearing recent apps manually after adding Clash to the whitelist can still interrupt the foreground service. A stable setup should minimize these conflicting actions.

Use logs to locate abnormal connections and restart loops

If the phone gets warm after the screen locks, open Clash’s log page and sort by time. Normal idle activity may include a few connections, rule-set checks, or network-change entries; abnormal behavior usually appears as the same error repeating every few seconds.

Look for four types of repeated entries

1. DNS timeout: The upstream resolver is unreachable, so the core keeps waiting and trying other servers.
2. connection refused: A local port or remote service rejected the connection, while an app continues retrying rapidly.
3. network changed: Weak Wi-Fi or a dual-SIM data switch is repeatedly rebuilding the tunnel.
4. provider update failed: The subscription or rule-set URL is unreachable, and the update interval is too short.

Keep the log level at info first. debug or trace generates more log writes and should be used only for short reproductions. After recording 5 to 10 minutes, restore the normal level and note when the error occurred, the network type, and the affected app.

Per-app proxying can also help isolate the cause. First let Clash handle only the browser and observe the phone while locked; if battery use returns to normal, add social, video, and sync tools in batches. If background connection counts rise sharply after adding a batch, inspect push notifications, autoplay, cloud backups, and polling settings for those apps. The proxy forwards connections, but the app determines how often they are created.

A troubleshooting sequence from low risk to high impact

Do not change a dozen switches at once, or you will not know which step helped. Follow the sequence below and observe each change for at least one complete 8-hour idle cycle.

1. Establish idle baselines with Clash disabled and enabled, then calculate the additional battery drain.
2. Increase the URL-Test interval to at least 600 seconds and set subscription updates to every 12 to 24 hours.
3. Close the client’s latency panel and restore the log level to info.
4. Check for DNS timeouts, failed provider updates, and network-change loops.
5. Remove duplicate rule sets and set the rule-provider interval to 86400 seconds.
6. Use per-app proxying to identify apps that keep generating background connections.
7. Allow Clash background activity and auto-start to prevent power policies from repeatedly terminating the service.
8. Enable the system’s “Always-on VPN” only when continuous connectivity is genuinely required.

Finally, rule out incompatibilities between the client version and configuration. After upgrading a mihomo-based client, if the old configuration immediately causes crashes or restart loops, export it first, then create a minimal configuration containing one node, one proxy group, and a basic MATCH rule. If the minimal setup idles normally, the issue is concentrated in the original configuration; if it still fails, continue checking the client version, system VPN permissions, and the manufacturer’s background policies.

The practical goal for a persistent Android proxy is a stable VPNService, continuous connectivity after the screen locks, low-frequency health checks and updates, and a phone that does not stay warm. Long background time does not automatically mean high battery use, and a persistent VPN icon is not itself a fault. Controlled comparisons, logs, and one change at a time usually reach a stable result faster than repeatedly clearing processes.