Android Clash Battery Drain: Background Usage, Battery Optimization & Keep-Alive Settings

First, distinguish battery drain from background app shutdown

When an Android proxy client runs for extended periods, it processes packets routed through the VPN interface, applies routing rules, makes DNS queries, and maintains the connections it needs. Battery use depends on traffic volume, network quality, health checks, and kernel settings. Seeing a VPN icon in the status bar does not mean the device is under constant heavy load.

A different issue is when the proxy disconnects after the screen locks and only comes back after you unlock the phone. Check background restrictions first rather than simply reducing the health check frequency. Exempting the client from battery optimization is intended to keep it available in the background, not to reduce power use; allowing it to run longer may actually increase its background time in system battery reports.

Set up a repeatable standby test

The “app battery use” percentage shown by Android is not the percentage of battery charge your phone has lost. For example, if the phone loses 10 percentage points and an app accounts for 30% of the battery used during that period, that does not mean the app drained 30 percentage points. Some systems also attribute network activity routed through the VPN to the proxy app, and attribution methods vary.

Change one setting at a time

1. In Settings → Battery → Battery usage or Battery details, note the starting charge, the client's background time, and the network type.
2. Use the same Wi-Fi network and a similar starting charge. Pause system updates, cloud photo backups, and large downloads, then leave the screen off for 60 minutes.
3. Record the ending charge, whether the connection dropped, whether the device heated up, and the amount of data sent and received by the client. If the client has no traffic statistics, check the system's app data usage.
4. Change just one variable—for example, increase the health check interval from 60 to 600 seconds—then repeat the same test. Run at least two rounds so a brief network fluctuation doesn't skew the results.

The 60-minute window is a suggested test duration, not a measured result for your device. Battery levels are often rounded to whole numbers, so short tests may not show a difference; try an overnight standby test if you need a longer comparison. Test Wi-Fi and mobile data separately. Repeated reconnects on a weak signal can use power that should not all be attributed to the proxy core.

Health check intervals: reduce redundant probes first

Manually tapping “Test all” usually runs a one-off check. Automatic checks for proxy groups and health checks for proxy providers may run on a schedule. If your subscription includes multiple url-test or fallback groups and proxy-providers with health checks enabled, review what each one checks instead of relying on a single toggle in the interface.

What changing the interval from 60 to 600 seconds means

Suppose a proxy group has 30 candidate nodes and checks them once every 60 seconds. At one probe per node per round, that works out to about 1,800 probes per hour; at 600 seconds, about 180. This estimate illustrates the change in frequency. Actual probe counts depend on lazy checks, timeouts, connection reuse, and core implementation, and battery use will not necessarily fall by the same proportion.

Here is a partial mihomo proxy provider configuration showing health check settings only. It is not a complete subscription you can import directly:

health-check:
  enable: true
  url: https://www.gstatic.com/generate_204
  interval: 600
  timeout: 5000
  lazy: true

• interval: 600 is measured in seconds; timeout: 5000 is measured in milliseconds. Don't mix them up.
• lazy: true can skip scheduled checks while the proxy provider is not in use. The exact behavior depends on the core version; it does not mean all network requests stop.
• The example probe URL must be reachable on your network and through your proxy exit. If it keeps timing out, check whether the URL is accessible instead of retrying more often.
• With a select group where you choose nodes manually, you can test them first and pick one yourself. The trade-off is that you may need to switch nodes manually if one fails.

Automatic failover and less frequent probes involve a trade-off. 600 seconds is just a starting point for testing, not a setting that suits every network. Subscription managers may overwrite local changes during updates, so use the client's override or persistent configuration feature where available, and verify the effective settings after updating.

DNS, rules, and logs: look for repeated errors

DNS queries are normal network activity. Look into repeated failures to resolve the same domain, encrypted DNS connections that cannot be established, or DNS requests whose own connection depends on a lookup that has not completed—situations that can trigger repeated retries. The connections page may show the same destination repeatedly, while logs report recurring timeouts or resolution failures.

Check in this order

1. Temporarily set the client log level to info and watch for 1–2 minutes to see whether repeated errors come from DNS, node connections, or health checks.
2. Check that the DNS upstream, selected proxy node, and relevant routes are reachable. If DNS requests are routed through a proxy, first make sure that proxy can connect.
3. If you're using mihomo with respect-rules enabled, check the core documentation for the proxy-server-nameserver requirements. This helps avoid making proxy node domain lookups depend on the proxy itself.
4. Turn off continuous debug logging. Once you've identified the issue, restore the client's default level or use warning if supported.

Don't change the DNS mode, upstream servers, and all your rules at once to save battery—you won't know which change helped. fake-ip is a DNS and connection-mapping mechanism, not a standalone battery-saving switch; redir-host is not guaranteed to use less power. Start with a configuration compatible with your client, then fix specific errors.

The number of rules is not the only factor. Deleting important rules just because there are many could send high-traffic services through the proxy when they previously connected directly, increasing processing load. Rules-based routing can avoid unnecessary proxy traffic, but after making changes, verify the app's actual route instead of relying on rule names.

Battery optimization exemptions and background settings by manufacturer

Relax background restrictions gradually, and only if you need the client to stay connected while the screen is locked. First allow background activity for the client, then test with the screen off. If the system still shuts it down, check auto-start and app pinning. These are common menu paths; names vary by Android version, region, and device. If you can't find a setting, search Settings for “battery optimization,” “auto-start,” or “background activity.”

Locking an app in Recent apps is only an additional measure. It does not grant a battery optimization exemption or override every system restriction. Power saving modes, ultra power saving, system cleaners, and background data limits may still affect the VPN service. Check these settings individually instead of disabling all battery management on the phone.

Persistent notifications, VPN, and TUN mode

Android clients typically use the system VpnService to create a virtual network interface and pass matching app traffic to the core. This differs from how desktop clients connect through the system proxy settings, so the desktop approach of “turn off TUN and use only the system proxy” does not apply directly to Android. The Android VPN icon also doesn't tell you which remote proxy protocol is in use.

Keep the service notification; reduce frequent updates

A VPN service that runs continuously will usually show a foreground service notification. A static notification is not usually a major source of battery drain. Frequent speed updates, ongoing statistics calculations, or continuous logging are more likely sources of extra work. If the client has a “live traffic,” “notification speed,” or “refresh interval” setting, turn off live speed updates or change the refresh interval from 1 second to 5 seconds, then compare.

Don't block notifications as a substitute for proper background settings. On Android 13 and later, notification permission, VPN service status, and manufacturer background management are separate controls; hiding the notification does not guarantee the service will stop. Check the client's service status and the system VPN page to confirm whether it is still running.

Use “Always-on VPN” with care

Some systems let you enable “Always-on VPN” under Settings → Network & internet → VPN → the settings button next to the client. This enforces VPN usage; it does not save power or fix a faulty node. “Block connections without VPN” prevents relevant network traffic when the VPN is unavailable. Before enabling it, make sure you're prepared for the loss of connectivity.

In typical use, only one VPN service can be active at a time. Local VPN ad blockers, packet capture tools, and other VPN clients may replace or conflict with the proxy client. If the service keeps disconnecting, rule out these conflicts before granting more background permissions.

Verify changes and roll back if needed

A good order of operations is to investigate unusual traffic and errors first, reduce redundant health checks and logging next, then adjust background settings if the connection drops while the screen is locked. For reliable standby, check both battery use and whether essential apps can still connect when needed.

• Standby: Run a 60-minute comparison on the same network and record the starting and ending charge and data use. Don't rely only on the app battery ranking in system settings.
• Network switching: Switch from Wi-Fi to mobile data and back. Check whether the client reconnects and whether the logs keep reporting errors.
• Screen locked: Test the messaging, sync, or web connections you need in everyday use. Keep in mind that the system may also restrict those background apps.
• Configuration updates: After updating a subscription, recheck the health check interval, DNS, and log level, and confirm that persistent overrides are still in effect.
• Rollback: If less frequent checks make failover too slow, restore a shorter interval. If a battery optimization exemption doesn't improve reliability, revoke permissions you don't need.

If the device still gets noticeably warm with almost no traffic, note the client version, core version, Android version, and a short excerpt of the error logs, then report the issue to the relevant project. Before sharing logs publicly, remove subscription URLs, tokens, node credentials, and personal browsing activity. For help importing configurations and getting started, see the user guide; for common connection issues, see the FAQ troubleshooting guide.