Android Proxy Battery Drain: Background Settings and Clash Tweaks

First, tell normal proxy overhead from repeated background restarts

Compare under the same conditions before changing battery settings. Using a proxy on your phone adds traffic forwarding, encryption and decryption, and rule matching, so some extra battery use is expected. But persistent heat with the screen off, service restarts every few minutes, or noticeably faster standby drain on mobile data are worth investigating. Disabling every restriction at once may fix disconnects, but it won't prove the battery issue is resolved.

On Android, Clash clients typically use VpnService to create a local VPN interface, then route traffic from selected apps to the core for processing. This is not the same as paying for a remote VPN service. The key icon in the status bar also doesn't mean every connection passes through a remote proxy node. Connections matched to DIRECT may still go through local forwarding; they just don't use a remote node.

Establish a baseline with two standby tests

Don't draw conclusions from a full day with the proxy on yesterday and off today. App updates, signal changes, and screen brightness can all affect the result. Run the short comparison below first, then decide whether you need a longer test.

1. Record the setup: Note the phone model, Android version, client and core versions, Wi-Fi or mobile data, and starting and ending battery levels. You can usually find version details under About in the client.
2. Keep conditions consistent: Use the same Wi-Fi network, location, and approximate battery range. Pause system updates, cloud photo backups, and large downloads. Don't test while charging.
3. Test 1, proxy off: Confirm the VPN service has stopped. Leave the screen off for 60 minutes, then record battery use and background network activity.
4. Test 2, proxy on: Keep the same apps in the same state, select a fixed node and rule mode, then leave the phone idle for 60 minutes. Don't run a full speed test at the same time.
5. Change one setting, then retest: For example, increase the health check interval first and leave everything else unchanged. Repeat the test at least once so battery percentage rounding isn't mistaken for an improvement.

For example, if the phone goes from 80% to 79% with the proxy off and from 80% to 77% with it on, those two tests differ by 2 percentage points. That doesn't predict all-day battery use on every phone. These figures illustrate how to record results; they aren't measurements from a client. If the difference over an hour is too small to judge, extend the test to 3 hours. Test poor mobile signal separately; don't combine those results with Wi-Fi data.

Background reliability: Allowlist battery optimization only when needed

An allowlist can help prevent Android from stopping the app; it isn't a battery-saving switch. Change this setting first only if the connection drops when the screen is off, the system kills the service, or the client keeps restarting. A persistent notification alone doesn't mean the client is under heavy load. Check whether the core keeps initializing or connections keep getting rebuilt.

Where to look on Android 14

On a near-stock Android 14 device, go to Settings → Apps → See all apps → select the Clash client → App battery usage, then check whether it is set to Restricted. If you need the proxy to stay connected, try Unrestricted. The labels may differ after system updates—for example, you might see Allow background usage. Use the options shown on your device.

• Manufacturer battery controls: Search Settings for Battery optimization, Background activity, or Autostart. If your phone has separate app launch management, grant permissions only to clients that need to run the proxy long-term; there's no need to exempt every app.
• Locking the app in recent tasks: Some systems let you lock an app card to prevent it from being dismissed during manual cleanup. This isn't a universal Android guarantee of background operation and doesn't replace battery settings.
• Notifications and service status: Keep the client's running status visible. On Android 13 and later, notification permission and foreground service operation are separate controls. A missing notification alone doesn't prove the VPN has stopped.
• Battery Saver: First check whether the issue occurs only when system Battery Saver is on. Keep it in the same state during both tests; don't enable it for one and disable it for the other.

Check whether Always-on VPN matches your needs

On stock-style Android, go to Settings → Network & internet → VPN, then tap the settings icon beside the relevant profile. If supported by the client, you'll see Always-on VPN and Block connections without VPN. The latter blocks network access when the VPN is unavailable; it doesn't make proxy nodes more reliable. Understand what happens on disconnect before enabling it, so a system-enforced traffic block isn't mistaken for a DNS problem.

Android typically allows only one VpnService-based service per user or work profile at a time. Starting another VPN-style firewall, filter, or proxy app may replace the current service. If connections keep switching or dropping, check for competing apps before granting more background permissions.

Health checks: Reduce probing before switching nodes

Node checks make real network requests. Checking many nodes at short intervals can wake the wireless radio more often and increase connection activity. On mobile networks in particular, frequent short requests may keep the radio active longer. The impact depends on the network and device, so request size alone doesn't tell the whole story.

In mihomo, proxy provider health checks are configured under proxy-providers in health-check. The example below is a partial section for an existing provider, not a complete configuration. Replace mobile-pool with an existing provider name, and keep its existing type, URL, path, and other fields.

proxy-providers:
  mobile-pool:
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600
      lazy: true

• interval: 600: Sets the health check interval to 600 seconds. Start by testing 300–600 seconds; there's no need to check every few dozen seconds just to see the latest latency.
• lazy: true: Skips scheduled checks for provider nodes that aren't in use. Whether a node counts as in use depends on strategy group references and its current usage.
• url: Choose a test URL that's reachable from your current network and node and returns a small response. An unreachable URL causes false alarms; shortening the interval won't fix that.

Here's a rough estimate: checking 50 nodes every 60 seconds schedules up to about 3,000 node probes per hour. At 600-second intervals, that's about 300. This doesn't mean battery use will drop by a factor of ten, and it doesn't account for lazy checks, timeouts, or other strategy group checks. But it can reveal duplicated work in your configuration.

Also check the interval on strategy groups such as url-test and fallback, and whether the client runs automatic batch speed tests. Provider checks and strategy group checks can run at the same time. The interval under proxy-providers controls subscription updates; health-check.interval is the health check interval discussed here. Make sure you're editing the right setting.

DNS and connection retries: Fix the cause of repeated requests

Adding more DNS upstreams doesn't automatically make DNS more reliable. An upstream that's consistently unreachable, or a DNS request that depends on a proxy connection whose hostname hasn't resolved yet, can cause repeated retries. If the logs repeatedly show i/o timeout or context deadline exceeded, note the domain, destination address, and time. These errors can also come from connections or probes, so the error text alone doesn't prove DNS is at fault.

1. Check that there's one expected DNS path: Review the client's DNS settings, Android Private DNS, and any other filtering apps. On stock Android, go to Settings → Network & internet → Private DNS. Don't change all three at once.
2. Temporarily compare with Private DNS: If you've set a custom provider hostname, record it, then temporarily switch to Automatic to see whether it conflicts with the current VPN route. Restore the setting afterward if needed.
3. Check mihomo fields: dns.nameserver sets the default DNS upstream. dns.proxy-server-nameserver is used to resolve proxy node hostnames. Whether you need the latter depends on your existing configuration and the core documentation; don't add it without checking.
4. Look for the source of repeated requests: If the same app keeps contacting a domain that fails, check which rule it matches, which node it exits through, and what DNS returns. Don't just keep clearing the cache.

fake-ip and redir-host are DNS handling modes, not battery settings. Switching modes can affect app compatibility and caching, but it won't guarantee lower battery use. If your apps and sites work normally, don't overhaul DNS just to save power. Fix confirmed timeouts and repeated requests first.

Rules, TUN, and logs: Cut unnecessary processing

Rule mode doesn't bypass Android's local VPN

mode: rule chooses an exit based on rules. DIRECT means traffic doesn't go through a remote proxy node. If the app's traffic has already entered Android's local VPN, it may still be processed by the core. So switching back to rule mode doesn't guarantee lower battery use. However, routing traffic directly when appropriate can avoid an unnecessary remote hop and some encryption work.

If your client offers per-app proxying or app bypass, use it to narrow which apps are routed through the proxy as needed. First check whether the setting uses an allowlist or a blocklist; they mean opposite things. Excluded apps generally won't be controlled by these proxy rules, so consider their connection requirements before changing the list.

Don't apply desktop TUN battery advice to Android

Android phones commonly use a VPN interface to route traffic, so desktop advice like “disable TUN and use system proxy only” isn't a universal alternative on Android. Other operating modes depend on the client. The available values and behavior of tun.stack also vary by core and integration; don't choose by name alone. Test compatibility and battery use with the same network and workload.

Restore the normal log level when troubleshooting is done

Keeping verbose logs on for a long time adds processing and storage overhead. Enable them briefly to reproduce the issue, export the relevant lines, then restore log-level in the effective configuration to info or the client's original level. Don't leave live connection refresh, repeated speed tests, or a scrolling log view running in the background during standby tests.

Post-change verification checklist

Use the steps below to wrap up. Check that background operation is stable, connectivity works, and standby battery use is acceptable—not just that the client has dropped in the battery usage ranking.

1. Check background operation first: Turn the screen off for 30 minutes, then wake the phone. Confirm the VPN service is still running, the network reconnects normally, and the logs show no repeated restarts.
2. Then verify the configuration: Confirm the health check interval is active in the effective configuration, automatic batch speed tests haven't restarted, and your changes survive a subscription update.
3. Retest battery use: Compare under the same conditions using the 60-minute test above, and note battery drop and unusual connections. If results vary widely, extend the test period instead of adding more settings.
4. Restore everyday settings: Turn off temporary verbose logging, revoke test permissions you no longer need, and keep only the settings needed for reliable background operation.

If mobile data drains noticeably more battery than Wi-Fi, check signal quality and the route to the node first. If only one node keeps timing out, switch to a working node and retest. If the issue persists after changing clients, check Android's network settings and background apps too; don't automatically blame a particular core.

To review the import process, see the user guide. If overrides aren't taking effect, DNS is timing out, or rules aren't using the expected route, check each item in advanced configuration. Before sharing logs, remove subscription URLs, access tokens, node passwords, and personal connection history.