Clash Android Battery Drain: Background Running and Battery Optimization Settings

Clash clients on Android need to keep handling the network connections routed through them. If the app ranks among your top battery users, disconnects when the screen is off, or makes your phone heat up, first distinguish between three causes: power used to process real traffic, how Android attributes VPN traffic in its stats, and repeated reconnects after the app is killed in the background. Each calls for a different fix. Simply hiding notifications or allowing every background permission usually won’t identify the cause.

Check battery usage, then compare under the same conditions

Go to Settings → Battery → Battery usage and find the proxy client you use. Some devices call this Battery usage by app or Battery drain. Note the time period, foreground and background activity, battery percentage change, and whether you were on Wi-Fi or mobile data. If the client accounts for “30% of battery use during this period,” that does not mean it used 30% of the battery’s total capacity.

A VPN routes traffic from other apps. Android versions and manufacturers attribute traffic and power use differently, so a high ranking for the client is a clue—not proof that the core is under constant heavy load. Large downloads, cloud photo uploads, and video streaming can all push the client higher in the list.

Run two screen-off tests to establish a baseline

1. Pause downloads, video playback, and system updates. Use the same stable Wi-Fi network, keep the phone at a similar temperature, and don’t test while charging.
2. Start the client, select one working node, and leave the screen off for 60 minutes. Record the battery level at the start and end, any disconnections, the client’s traffic increase, and errors in the log.
3. Under similar conditions, stop the client and leave the screen off for another 60 minutes. Keep other apps and sync activity as consistent as possible across both tests.
4. If the difference is only one percentage point, extend the test and repeat it. Battery percentages are coarse readings, and a short test is not enough to draw a conclusion.

For example, a test log might read “Proxy on: 82% → 79%; proxy off: 81% → 79%.” This is just a formatting example, not a measured result or a target. Look for extra battery loss that recurs across multiple tests, especially when it coincides with reconnects, timeouts, or unusual traffic.

What persistent VPN notifications and background services do

Android VPN clients typically use VpnService to create a virtual network interface. A VPN service that runs continuously generally needs to use the foreground service mechanism and provide a notification to Android. The notification itself is not a significant source of battery drain; actual power use comes from data processing, encryption and decryption, network wake-ups, and connection retries.

• VPN icon in the status bar: Indicates that Android has an active VPN connection; it doesn’t guarantee that the current node is reachable.
• Client service notification: May show the connection status, speed, or a disconnect button. If speed updates are too frequent, reduce their refresh rate if the client offers that option.
• Background activity permission: Controls whether a service can keep running after the app leaves the foreground. It is separate from whether notifications are shown.

Android 13 and later require runtime permission for notifications, but foreground service requirements still apply. Turning off app notifications is not a battery-saving fix and won’t make the service more reliable. During troubleshooting, keep the service notification enabled so you can tell whether the service is still running with the screen off.

“Always-on VPN” isn’t a universal keep-alive switch

A common path is Settings → Network & internet → VPN → the settings icon next to the client. Android may offer Always-on VPN and Block connections without VPN. The first keeps the VPN enabled; the second blocks network access when the VPN is unavailable. Neither can fix an unreachable node or incorrect DNS settings.

Battery optimization exemption: exempt only the client you use

Exempting an app from battery optimization addresses background restrictions; it does not directly reduce power use. The goal is to prevent the service from being killed and repeatedly rebuilding its connection—not to keep the CPU awake indefinitely. Change settings one at a time and retest only if the connection drops with the screen off, the service stops, or Android reports that background activity is restricted.

Common paths on stock Android and Pixel

1. Long-press the client icon and go to App info → App battery usage. Allow background usage; if Unrestricted is available, try it to see whether background limits are causing the problem.
2. On some older versions, go to Settings → Apps → Special app access → Battery optimization. Switch the list to All apps, find the client, and select Don’t optimize.
3. Return to the home screen, start the proxy, and leave the screen off for 15 minutes. Then unlock the device and check that the service is still running and the app can make new connections.

Android versions may show only one of these paths; there’s no need to change settings repeatedly just to find both. If the connection still drops when the app is unrestricted, check the node, network, and logs instead of exempting every app.

Additional settings to check on manufacturer-specific Android builds

These paths may be renamed after system updates. Search in Settings first instead of looking for an identical button in screenshots from another brand. Locking an app in Recent apps may only prevent it from being cleared with a single tap; it doesn’t replace battery optimization settings. Autostart permission also doesn’t mean the client’s own Start on boot option is enabled. If you need a connection after reboot, check whether the client offers that feature.

Screen-off disconnects and high battery use: check for repeated reconnects first

If the service is still running but connections keep failing, allowing more background activity may simply let retries continue longer. Open the client’s Logs page, set the level to info, and note the time before and after turning off the screen. Look for recurring timeouts, DNS resolution failures, connection resets, and core restarts.

• Service restarts: If the notification disappears with the screen off and startup messages reappear after unlocking, check background restrictions and client crashes first.
• Node timeouts: If the service stays up but the same node repeatedly fails to connect, test again with a different node you know works.
• Network changes: If the connection drops when switching from Wi-Fi to mobile data, check network handoff, weak signal, and tunnel reconnection before blaming battery optimization.
• Repeated retries from one app: If only one syncing app keeps generating connections, check its background uploads and the rules that match its traffic.

For troubleshooting, pin the client to one node to reduce variables from automatic switching. Configurations that health-check many nodes can also increase background requests if checks run too often. For example, testing 100 nodes every 30 seconds would theoretically generate about 12,000 test requests per hour; the actual number depends on the client, lazy loading, and whether a proxy group is in use.

If your client supports it, consider increasing unnecessary frequent checks to 300 or 600 seconds, then test whether switching still feels responsive. These values aren’t universal menu options for every client. Subscription updates may overwrite local changes; use the client’s supported override feature for persistent settings.

TUN and DNS: reduce duplicate routing and repeated lookups

Android VPN routing isn’t the same as a desktop TUN switch

Desktop guides often compare System Proxy and TUN mode as separate options. Android clients typically route traffic through a VPN interface already. Some mihomo-based clients also offer a TUN stack or related options, but behavior depends on the client. Don’t assume that turning off TUN will save power—it may also stop proxy routing altogether.

• Keep the client’s default network stack unless logs or project documentation point to a compatibility issue; only then test a different option on its own.
• Check whether another local VPN, firewall, or network filtering app is also enabled. Typical personal setups can’t run two VPNs based on VpnService at the same time.
• If the client supports per-app routing, exclude high-traffic apps that don’t need the proxy. Afterward, confirm that those apps connect directly as expected.

Check DNS timeouts before comparing resolver modes

Fake-IP returns a virtual address for mapping, while Redir-Host involves resolving the real address. The main difference is how resolution and connections are handled; the mode name alone can’t tell you which uses less battery. Check instead for an unreachable upstream DNS server, repeated failures to connect to encrypted DNS, or a dependency loop between the proxy and resolver.

1. Check the logs for recurring DNS timeout messages or resolution failures, and see whether the affected domains come from the same background app.
2. Go to Settings → Network & internet → Private DNS. If a custom hostname is set, temporarily switch to Automatic for comparison, then restore your preferred setting if needed.
3. Make sure the client’s DNS upstream is reachable on the current network. If the upstream is specified by hostname, it also needs a working bootstrap resolution path; don’t make the resolver depend on a proxy connection that hasn’t been established yet.
4. Change one setting at a time, then retest with the screen off and when first opening a webpage. Don’t change DNS, nodes, and rules all at once, or you won’t know which change helped.

How Private DNS interacts with the client’s DNS depends on the Android version and routing method; don’t assume one always overrides the other. After troubleshooting, set temporary debug logging back to a normal level and close any connection-monitor page that refreshes continuously, so the diagnostic tools don’t add extra work.

Set up a stable background configuration

Once you’ve finished testing, keep only the changes that made a difference. A good starting point for everyday use is one VPN route, a working node, health checks at a reasonable interval, reachable DNS, and only the background permissions the client needs. Add other features as required. Avoid installing keep-alive tools that hold the CPU awake, and don’t repeatedly force-stop the service to save power.

Post-change checklist

1. Screen-off recovery: Start with a 15-minute screen-off test, then observe for an hour. After unlocking, open a new webpage instead of checking only a page that was already loaded.
2. Network switching: Switch from Wi-Fi to mobile data and back. Confirm the client reconnects and the logs don’t show extended runs of timeouts.
3. Background messages: Use a messaging app you rely on to check that messages arrive. Distinguish restrictions on that app’s background activity from a VPN disconnect.
4. Battery retest: Repeat the battery test under the same conditions as in the first section, at least twice. Don’t judge the result from one short test.
5. Reboot test: If you need the VPN to connect after startup, reboot and unlock the device. Check the client settings, system VPN status, and whether the internet actually works.

If the client service is stable and the logs look normal, but mobile data uses noticeably more power than Wi-Fi, look at signal strength, 5G handoffs, and upstream connection quality. If the phone still heats up after you stop the proxy, return to the system battery page and check other apps and the device itself. Test proxy-related drain separately from overall device drain to avoid changing unrelated settings.