Clash Battery Drain on Android: Background Settings and Health Check Intervals

First, distinguish VPN traffic from excessive idle drain

After enabling Clash on Android, the VPN client may account for a larger share of battery use in system stats. That doesn’t necessarily mean the client itself is constantly working hard. Android’s traffic attribution and battery estimates can be affected by VPN routing; some network activity from video streaming, downloads, and sync may show up under the VPN app. To assess the issue, look at overall battery loss, screen-on time, network type, and client logs—not just the app ranking.

This guide is primarily for devices running Clash Meta for Android or other Android clients powered by Mihomo. Clash Verge Rev is a desktop client; its service mode and system proxy settings don’t apply directly to phones. Android typically uses VpnService to create a local VPN interface and route traffic through it. Background behavior and menus vary by platform, and the Android battery settings below do not apply to iOS.

Start with comparable battery measurements

Run three tests on the same network

On Android, open Settings → Battery → Battery usage, then view the details for the client. Depending on the device, the menu may be called Battery usage by app or App battery management. Record foreground and background time, along with the battery level at the start and end of each test. If your system shows mobile network active time, record that too.

1. Baseline: Stop the proxy service, lock the screen for 60 minutes on stable Wi-Fi, and record the change in overall battery level.
2. Current settings: Restart the proxy service and repeat on the same Wi-Fi, with the same app sync settings and screen-off duration. Don’t run manual speed tests.
3. Adjusted settings: Change only the health check interval or the background policy, then repeat the 60-minute test.

Don’t charge the phone, download subscriptions, update apps, or play audio during the tests. Poor cellular reception can draw far more power than proxy processing, so don’t compare a Wi-Fi test directly with a weak-signal 5G test. Battery percentages are shown as whole numbers; if the results are close after 60 minutes, extend the tests to 3–6 hours and repeat them.

Short, sequential tests like these are still affected by temperature, background tasks, and battery level. They can help identify what to investigate, but they don’t prove that a setting will always save power. Keep a record of the subscription configuration and client version used for each test so you can reproduce the results.

Health check intervals: check node count and duplicate probes first

Health checks use a specified URL to test node availability and latency. Each check typically establishes a connection; with HTTPS, it also involves a TLS handshake. The more nodes you have and the shorter the interval, the more often the network is active. On mobile networks, frequent small requests can also keep the radio active for longer.

Three intervals that are easy to confuse

• interval under proxy-providers: how often remote proxy providers are updated—not how often nodes are tested.
• health-check.interval: the health check interval for proxy providers, in seconds.
• interval under policy groups such as url-test and fallback: how often that group runs its own checks. Changing the provider interval alone does not necessarily reduce all probes.

For example, a full check of 100 nodes every 60 seconds works out to about 6,000 attempts per hour under the simplified assumption of one check per node. At 600 seconds, that drops to about 600. This illustrates the scale only; it does not represent actual packet counts. Real behavior depends on lazy checks, node usage, timeouts, and the core’s implementation.

Start at 600 seconds instead of running manual speed tests

For everyday mobile browsing, try setting the relevant automatic check intervals to 600 seconds and see whether node failover is still fast enough. If your network changes frequently, try 300 seconds; for a stable connection using fixed nodes, consider 1,800 seconds. Longer intervals can delay failure detection, so there’s no single best setting for everyone.

# Merge this into the relevant provider under the existing proxy-providers.
# Keep the existing type, url, path, and subscription update interval.
# This snippet is not a complete subscription you can import as-is.
proxy-providers:
  mobile:
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600
      timeout: 5000
      lazy: true

Here, interval is in seconds and timeout is in milliseconds. lazy: true reduces routine checks for unused providers; it does not stop all policy group probes. If your existing provider isn’t named mobile, edit that entry rather than adding a new one without a subscription URL.

Back up your configuration before making changes. Prefer a local override feature supported by the client so subscription updates don’t overwrite your changes. Save and reload the configuration, then briefly check the logs to confirm it loaded. Check the next scheduled probe to see whether the new interval has taken effect. Don’t repeatedly tap “Test all” to verify battery settings—that adds extra load.

Background operation: allow only the permissions needed for an always-on proxy

On Android, VpnService authorization controls whether a VPN can be established; battery settings control how background processes are scheduled. They are separate permissions. Even after granting VPN access, a manufacturer’s background manager may restrict the service when the screen is off. Conversely, exempting the app from battery restrictions won’t fix failed nodes or incorrect DNS settings.

Choose settings based on when disconnects occur

• Always-on proxy, but the service stops with the screen off: Long-press the app icon → “App info” → “Battery” or “App battery usage” → “Unrestricted.” Some devices also require “Allow background activity” and autostart to be enabled.
• Service is stable and stays connected with the screen off: Keep the current background policy. There’s no need to grant extra permissions to every related app.
• Proxy used only for short tasks: Stop the proxy service in the client when you’re done. Closing the app or swiping it away from recent apps may not stop the VPN.

Menu names vary by manufacturer, including on Android 13 and 14. Search Settings for “battery optimization,” “background activity,” or “autostart” to find the relevant controls. Locking an app in recent apps is an extra feature on some devices; it doesn’t replace VpnService authorization or guarantee that the system won’t stop the process.

If you’ve enabled always-on VPN, check Settings → Network & internet → VPN → the settings icon next to the app. With “Block connections without VPN” enabled, regular network access may also be blocked if the service stops. Use this only when you specifically need to prevent traffic from falling back to a direct connection—it isn’t a battery-saving switch.

DNS and rules: diagnose timeouts before switching away from Fake-IP

Incorrect DNS settings can cause pages to spin, apps to keep refreshing, and logs to fill with DNS timeouts. The extra battery use comes from repeated requests and connection retries—not from one DNS mode inherently using more power. Fake-IP uses synthetic addresses to maintain domain mappings for later connections and rule matching. Switching to real-IP mode won’t make an unreachable upstream server work.

1. Check when the issue occurs: Temporarily set the client’s log level to info, open an affected app, and look for repeated DNS timeouts, connection timeouts, or failures for the same domain.
2. Check upstream reachability: Make sure the DNS server is reachable over the intended route. For encrypted DNS that requires a proxy, check whether it depends on resolving a proxy node’s domain before the proxy connection is established.
3. Check Android Private DNS: Settings → Network & internet → Private DNS can affect some DNS queries. Note the original setting, then change only one variable at a time. Don’t change the core DNS and system DNS settings together.
4. Review rule matches: Rules are evaluated in order, and usually the first matching rule determines where traffic goes. If a high-traffic app is routed to an unreliable node, it may keep reconnecting. Fix the rule or change the selected policy first.

Don’t add multiple DNS upstreams just to “speed up resolution.” Some configurations query them concurrently, and more upstreams don’t mean fewer requests. If your current setup is stable, fix incorrect routing instead of copying an entire DNS configuration from an unknown source. Avoid clearing all caches to test battery life, too—it forces fresh DNS lookups and new connections.

Balancing per-app proxy, logging, and network switching

Per-app proxy settings are not the same as DIRECT rules

If your client supports per-app proxying, you can route only the apps that need it through the VPN. Android’s per-app VPN feature limits which apps use the VPN interface; a DIRECT rule is usually applied after traffic has entered the core and selects a direct outbound route. These are different paths—DIRECT does not mean the traffic bypasses the client entirely.

If you select “Proxy only selected apps,” test your browser, message notifications, sign-in redirects, and file downloads. Apps may rely on Android’s download manager or another app to complete a task, so an overly restrictive app list can send related connections over different routes. Follow the applicable network policies for work, financial services, and corporate networks.

Remove diagnostic overhead when troubleshooting is done

• Restore any temporary debug logging to info or the client’s default level. Changing the log level won’t fix connection problems, and verbose logs require more processing and disk writes.
• Close connection monitoring screens that don’t need to stay open. Don’t substitute watching the screen with it on for a test with the screen off—interface refreshes and screen power use can skew the results.
• Check how often subscriptions are updated. If you don’t need frequent updates, consider updating every 12 or 24 hours. Subscription updates and 600-second health checks are separate settings.
• After switching between Wi-Fi and cellular, give existing connections time to re-establish. If the issue occurs only in areas with weak signal, test on stable Wi-Fi first instead of immediately replacing the entire subscription.

Mobile VPN routing and desktop TUN mode both use a virtual network interface, but their settings are in different places. Don’t copy desktop instructions like “disable system proxy and enable TUN.” On Android, first check the VPN service status, per-app scope, and active configuration.

Narrow down settings by symptom and keep a recoverable configuration

A useful starting point is to keep rule mode enabled, use a verified working node, set relevant automatic health checks to 600 seconds, exempt the app from battery restrictions only if it disconnects in the background, and restore the usual log level when troubleshooting is done. Use this as a baseline for comparison, not a universal setting for every phone.

Change one category of settings at a time, and record when you made the change and how to undo it. When reporting an issue, include your phone model, Android version, client and core versions, network type, screen-off test duration, and error logs with sensitive details removed. Don’t share subscription URLs, access tokens, or node credentials publicly. Reproducible test notes are more useful for diagnosing a problem than a screenshot of the battery ranking.