How to Fix High Background Battery Drain in Clash for Android: Battery-Saving Settings and Background Reliability

First determine whether the app is staying active normally or draining power abnormally

After starting the proxy, clients such as Clash, Clash Meta for Android, and FlClash use Android's VpnService to create a local VPN interface. A key or VPN icon remaining in the status bar only means that the interface is active; it does not mean the processor is running under constant heavy load. After the screen turns off, a stable connection usually keeps only the foreground service, a small amount of connection state, and necessary network wakeups.

To determine whether battery use is abnormal, look at battery loss, background activity time, and mobile network status together. Seeing Clash near the top of the battery-usage list is not enough to draw a conclusion. If it is the only network app running for a period of time, it will naturally account for a larger share of battery use.

Run an 8-hour baseline test under fixed conditions

1. Charge the battery above 80% and record the test start time.
2. Stay on the same Wi-Fi or mobile-data connection, and avoid switching networks repeatedly during the test.
3. Close obvious sources of load such as video playback, games, cloud-photo syncing, and system updates.
4. Keep Clash connected, stop active latency tests and close configuration-editing pages, then lock the screen for 8 hours.
5. When the test ends, open Settings → Battery → Battery usage and record Clash's battery consumption, background activity duration, and the system's idle drain.

For a device with normal battery health and a capacity of about 5000 mAh, a 2%–5% drop after 8 hours locked on stable Wi-Fi is usually not worth addressing on its own. If the drop exceeds 10%, or the battery page shows the client running heavily in the background, check latency tests, reconnect loops, subscription updates, and TUN settings. Results vary with the chipset, signal strength, Android version, and notification volume, so these figures are useful for troubleshooting rather than a universal standard.

Reduce latency testing and subscription polling first

The most common source of background drain is not the VPN interface itself but periodic network tasks. Strategy groups using url-test, fallback, or load balancing perform health checks against test URLs at set intervals. The more nodes you have, the more DNS lookups, TCP connections, and TLS sessions each test round must create. A strategy group with 80 nodes tested once per minute may trigger an order of magnitude more background wakeups than one tested every ten minutes.

Change automatic latency tests from 60 seconds to 300–600 seconds

In clients that support strategy-group editing, check the health-check options under Configuration → Override or Settings → Configuration Override. Menu names vary by client. On a stable everyday network, set interval to 300 seconds; with more than 50 nodes, try 600 seconds first. For devices that frequently switch between Wi-Fi and mobile data, keep 300 seconds to avoid leaving failed nodes in the active strategy for too long.

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

lazy: true reduces unnecessary health checks when a strategy group is not actually being used. Whether it works depends on the current core and the client's support for that field. tolerance: 80 can prevent frequent switching when two nodes differ by only a few dozen milliseconds. Repeated switching rebuilds connections and helps neither stability nor battery life.

Do not use manual latency tests as background monitoring

• Use “Test All” in the node list to confirm a problem, not to run repeated tests for long periods.
• For a single test, select the current strategy group instead of testing every node in the subscription.
• Set the test timeout to around 5000 ms. An overly long timeout makes failed nodes occupy the test process for longer.
• Small differences across three consecutive test rounds usually come from network jitter and do not justify switching nodes repeatedly.

Keep automatic subscription updates at hourly or daily intervals

Subscription contents usually do not change minute by minute. Setting automatic updates to 1440 minutes, or once a day, covers most use cases. If the provider explicitly requires a shorter interval, use 360 or 720 minutes. Updating every 15 minutes repeatedly downloads the configuration, parses YAML, rebuilds strategy groups, and may trigger node health checks.

Handle vendor battery-saving policies to prevent process kills and reconnect loops

Restricting Clash in the background may appear to save power, but it can have the opposite effect. After the system terminates the foreground service, the client, an automation task, or a network change may wake it again. The VPN interface must then be rebuilt, and DNS plus existing connections must be initialized again. Repeated “terminate–wake–reconnect” cycles cause more processor wakeups and network handshakes than stable background operation.

Stock Android and Pixel devices

Open Settings → Apps → Clash client → App battery usage and set background usage to “Allowed.” If the system offers “Optimized,” “Restricted,” and “Unrestricted,” choose “Unrestricted” for continuous VPN use. The path varies by Android version and may instead appear as Settings → Apps → Special app access → Battery optimization.

Xiaomi and HyperOS devices

• Go to Settings → App settings → App management → Clash client → Battery saver and select “No restrictions.”
• Open Security Center → App management → Permissions → Autostart management and allow the client to start automatically.
• In the recent-apps view, long-press the client card and lock it to reduce the chance that a one-tap cleanup will terminate the service.

Samsung One UI devices

• Go to Settings → Battery → Background usage limits.
• Make sure the client is not listed under “Deep sleeping apps.”
• For long-term connections, add the client to “Never auto sleeping apps.”

OPPO, OnePlus, and realme devices

You can usually enable “Allow background activity” under Settings → Apps → App management → Clash client → Battery usage. Some versions also require Settings → Apps → Auto-launch to allow automatic startup. Menu labels vary by ColorOS or realme UI version; search the system settings for “background activity” or “battery optimization.”

After setting the exemption, do not add an automatic cleanup tool on top of it. The goal of stable background operation is to let one VPN service run at low frequency, not to make the system recreate it every few minutes. If logs previously showed frequent service starts, network changes, or configuration reloads, those entries should become much less frequent after the exemption is applied.

Choose TUN mode, system proxy, and DNS settings based on your needs

On Android, Clash clients usually use VpnService to handle traffic, but the client may still offer different TUN stacks, per-app routing, enhanced DNS, and sniffing options. More features do not mean they all need to be enabled. Base battery-saving changes on the traffic that actually needs to be handled.

Configure per-app routing when only selected apps need the proxy

If only a browser, messaging app, and a few tools need the proxy, go to Settings → Network → Access control or Settings → VPN service → Per-app routing and select the apps to include. Excluding local video players, LAN casting, system backups, and large game downloads can reduce the number of connections entering the proxy core.

Access control usually offers two modes: “Allow selected apps only” and “Exclude selected apps.” After changing the setting, test one proxied app and one excluded app separately. Do not enable lists with opposite meanings at the same time, and do not bulk-exclude Android system components, or DNS queries may take a different path from the actual connections.

Prioritize TUN stability; do not stack parameters repeatedly

Common TUN stacks in the mihomo core include system, gvisor, and mixed. The available choices depend on the client and core version. system tends to use the system network stack and usually has lower overhead; gvisor uses a userspace network stack and can help with some compatibility cases, but its processing path is longer; mixed handles traffic by combining approaches according to the protocol. There is no single lowest-power option for every device.

1. Keep the client's default stack and complete one 8-hour idle test.
2. Switch to another stack only when a specific app cannot connect, UDP behaves abnormally, or connections drop frequently.
3. Change only one parameter at a time, clear the old logs, and reconnect.
4. Compare battery use, disconnect counts, and log errors—not just webpage loading speed.

Keep DNS and sniffing settings to the minimum necessary scope

fake-ip returns a mapped address for each domain, then the core matches rules using that mapping. It is not inherently power-hungry, but oversized rule sets, repeated DNS queries, unreachable upstream DNS servers, and persistent timeouts increase background activity. When battery use is abnormal, check whether the logs repeatedly show DNS timeouts, fallback retries, or high-frequency queries for the same domain.

Domain sniffing recovers domain information from connections and is useful when the domain cannot be obtained directly. If the current rules already match correctly and there are no transparent-interception compatibility issues, do not expand sniffing ports and protocols just to enable every option. After disabling or narrowing unnecessary features, verify that video, games, push messaging, and LAN access still work normally.

mode: rule

dns:
  enable: true
  enhanced-mode: fake-ip
  ipv6: false

tun:
  enable: true
  stack: system
  auto-route: true
  strict-route: false

This configuration is for showing which fields to inspect during troubleshooting; it should not directly replace an existing subscription. Some Android clients generate TUN settings through their graphical interface, and subscription updates may overwrite manual changes. Before making adjustments, copy the current Profile and test in the duplicate.

Check network switching, weak signals, and competing VPNs

Weak mobile signals make the modem consume more power on their own. After Clash switches between Wi-Fi and cellular data, it must also migrate or rebuild connections, so battery drain during commutes, in underground garages, or with two SIMs in weak-signal areas cannot all be blamed on the proxy client. For testing, compare “VPN off” and “VPN on” along the same route while keeping screen-on time similar.

Turn off other services that use the VPN interface

Android generally allows only one primary VPN connection for a user at a time. Firewalls, tracker blockers, enterprise VPNs, and other proxy clients may also use VpnService. When multiple apps take turns requesting a connection, you may see the key icon disappear and reappear, notifications refresh repeatedly, brief network interruptions, and the client reload.

• Go to Settings → Network & internet → VPN and confirm which VPN is currently active.
• Temporarily disable other VPNs, firewalls, or local filtering services and observe the device for 2 hours.
• Do not enable “Always-on VPN” for two proxy clients at the same time.
• If “Block connections without VPN” is enabled, turn it off before switching clients to prevent a total network outage during the transition.

Look for log patterns that indicate reconnect loops

Open the client's Logs page and keep the level at info. During normal idle operation, new log entries should appear slowly. If network changed, start service, reload configuration, DNS timeout, or connection timeout repeats every few dozen seconds, trace the trigger in chronological order. Avoid leaving the level at debug during troubleshooting; verbose logs increase writes and make important events harder to identify.

If reconnects occur only after the screen turns off, check battery optimization and Wi-Fi sleep policies first. If they occur exactly every 60 seconds, check the health-check interval and automation tasks. If they occur only on mobile data, check signal strength, dual-SIM switching, IPv6, and carrier-network reachability.

A practical order for battery-saving adjustments

Changing a dozen toggles at once removes the comparison baseline. A safer approach is to start with high-frequency tasks and observe for at least half a day after each group of changes. The sequence below balances connection reliability with troubleshooting efficiency.

1. Keep a copy of the current configuration. Copy the Profile in use and record the core version, current node, TUN stack, and DNS mode.
2. Stop repeated latency tests. Set the health-check interval to 300–600 s and enable lazy testing if supported.
3. Reduce subscription polling. Set automatic updates to 720–1440 min, then confirm that the configuration loads correctly after a manual update.
4. Set a background exemption. Allow background activity, autostart, and the foreground VPN service to run reliably, and remove the client from the deep-sleep list.
5. Eliminate VPN conflicts. Turn off apps that use VpnService and keep only one active client.
6. Narrow the traffic scope. Use per-app routing to exclude high-bandwidth apps that do not need the proxy.
7. Adjust TUN last. Only if the preceding steps do not help, compare system, mixed, or other stacks provided by the client one at a time.

Acceptance criteria after adjustment

• There are no periodic disconnect notifications during 8 hours with the screen locked.
• Logs no longer reload the configuration or start the service repeatedly at fixed short intervals.
• Background activity shown on the battery page matches the actual time the VPN was in use.
• Push messaging, browsers, terminal apps, and LAN access follow the expected routing rules.
• After switching between Wi-Fi and mobile data, the connection recovers within a few seconds without manually restarting the client.

If idle battery drain remains clearly higher than the VPN-off baseline after all steps are complete, create a test configuration containing only a few nodes and basic rules. If the test configuration works normally, the issue is most likely in the original subscription's strategy groups, health checks, or rule-set size. If it still behaves abnormally, investigate compatibility with the client version, system firmware, or device network module. Before upgrading the client, record the current version and back up the configuration; after upgrading, measure again under the same conditions to determine whether the change helped.