Clash Meta Draining Battery on Android: Background Restrictions, Battery Optimization & TUN Settings

Separate actual battery drain from background restarts and battery-use attribution

Start with how quickly your phone is actually losing charge, then check where Clash Meta ranks on the battery usage screen. Android VPNs handle connections for other apps, so the system may attribute some network activity to the VPN app. A top spot in battery usage doesn't mean the core is constantly maxing out the CPU. Downloads, cloud photo backups, video playback, and a weak mobile signal can all use more power than the proxy itself.

Clash Meta refers to a client and related core, while mihomo is a commonly used core. Settings, configuration overrides, and background service behavior vary across Android clients. Before troubleshooting, note the client version, core version, Android version, and active configuration name. Don't apply Linux systemd keep-alive tips or TUN permission commands to a phone.

Compare two runs under the same conditions

1. Use a stable Wi-Fi connection and keep signal strength, screen brightness, and background sync settings consistent. Pause downloads and backups, and avoid testing just after startup, a system update, or charging, when the phone may be warm.
2. Run a 60-minute screen-off test. Record the starting and ending battery levels, any disconnections, and whether the phone feels warm. For the control run with the proxy off, keep app activity the same. If apps stop syncing because they can't connect, the results aren't directly comparable.
3. Then repeat the test with the same apps and duration, but with the screen on. Establish a new baseline if you change video quality, game frame rate, or network type.

For example, a drop from 80% to 77% over 60 minutes is a 3-percentage-point decrease. This is just a calculation example, not a measured Clash Meta baseline. Battery percentages are rounded, so a single 1% drop isn't enough to judge an optimization. Repeat at least twice, and also record heat, reconnects, and whether notifications arrive on time.

Health checks: lengthen the interval before tackling duplicate tests

Node speed tests make network requests. With many nodes and short intervals, they generate periodic connections even when you're not actively browsing. On mobile data, these requests can also repeatedly wake the radio from its low-power state. Check health checks under proxy-providers first, then see whether policy groups such as url-test or fallback are running similar tests too.

The fields below are a partial example to merge into an existing Provider entry, not a complete subscription. Keep the entry's existing type, url, path, and health-check url. Continue using a tested, reachable address for checks; don't swap it out just to match the example.

interval: 86400
health-check:
  enable: true
  interval: 900
  lazy: true

If 80 nodes were tested every 60 seconds, and every round completed in full, that would amount to about 4,800 node tests in an hour. At 900-second intervals, it would be about 320. This estimate excludes retries, initial loading, and manual tests; it isn't the actual number of HTTP requests or a measure of battery savings. For unstable nodes, try 300 seconds and adjust gradually to balance switch speed with background activity.

• Adjust subscription updates and node tests separately. Updating the configuration daily doesn't mean nodes are checked only once a day. Their interval settings are at different levels.
• Cut duplicate checks. If several automatic-selection groups use the same nodes, review each group's settings. Changing the Provider alone won't stop all automatic probing.
• Check which configuration is actually active. Client overrides, subscription updates, and UI settings may supersede the file. After reloading, check the running configuration or logs to confirm the check frequency.

Logs, dashboards, and retries: avoid continuous background activity

For everyday use, start with info. While troubleshooting battery drain, try warning and reduce how long detailed logs are kept. debug is useful for a short reproduction, not for monitoring all night. Log volume depends on the number of connections and the client implementation, so changing the log level won't save a predictable amount of power.

log-level: warning

Close dashboards that continuously refresh connection lists, live speed charts, or external control panels. Whether a client keeps refreshing these views with the screen off depends on its implementation; try exiting the dashboard before testing again. If the phone runs cooler, investigate whether the difference came from UI refreshes, log writes, or network traffic.

Enable detailed logging for a few minutes to find repeated events

• Repeated connection timeouts: try a more stable node first, then see whether retries decrease. A shorter timeout doesn't always save power; rapid reconnect attempts after failures can happen more often.
• Repeated DNS failures: check that upstream servers are reachable, whether requests are routed through a dead node, and whether there is a DNS resolution loop. Don't try to fix the problem simply by adding more upstream DNS servers.
• Repeated configuration reloads or core restarts: check background restrictions, client crashes, and automatic switching scripts before reducing the speed-test interval further.

Before sharing logs, remove subscription URLs, credentials, node passwords, and access domains. A short log covering one disconnection and recovery is usually enough; a full day's logs are rarely needed. Once things are stable, restore your normal log level.

Battery optimization exclusions: for reliable background operation, not lower power use

Excluding an app from battery optimization reduces system restrictions on its background activity. This can help with lost connections when the screen is off, a stopped VPN, or delayed scheduled tasks, but it won't automatically reduce battery use. If the client already runs reliably, there's no need to enable every autostart, background activity, or high-power permission in the name of saving battery.

Repeatedly stopping and restarting the client can also mean repeatedly setting up the VPN, resolving domains, and reconnecting to nodes. If the connection returns as soon as the screen turns on but drops a few minutes after it turns off, stabilize the service first, then review periodic tasks such as health checks.

These are common menu names; they can vary by Android version, regional firmware, and manufacturer. If you can't find a setting, long-press the app icon and open App info, or search Settings for “battery optimization,” “background activity,” or “autostart.” Locking an app in Recents is an extra measure on some devices, not a substitute for battery permissions.

Android VPN and TUN: decide which apps need VPN coverage

Android clients typically use the system VpnService to create a virtual network interface and pass traffic to the proxy core. This differs from enabling tun.enable, configuring routes, and granting network permissions on Linux. A client's “VPN mode” may not correspond to a single YAML setting you can edit.

VPN coverage is usually the practical choice if you need to route traffic from browsers, chat apps, and apps without proxy settings. If only a few apps that support manual proxies need access, compare a local proxy port with VPN mode. Check that the client can run its proxy service on its own and that the target apps actually use the proxy.

Three ways to narrow VPN coverage

1. Exclude apps that don't need the proxy. In the client's “Access Control” or “Per-app proxy” settings, check whether the list means “proxy only selected apps” or “bypass selected apps.” The two options mean opposite things and produce very different coverage.
2. DIRECT in a rule doesn't bypass the VPN. Traffic may still enter the virtual interface before the core routes it directly. App-level exclusions usually happen earlier, but test the specific implementation and DNS behavior.
3. A local proxy port isn't a full VPN replacement. For example, 127.0.0.1:7890 works only if the client is listening on that port. Android's Wi-Fi HTTP proxy doesn't cover every app or UDP, and doesn't automatically apply to mobile data.

Don't turn off the VPN just to remove one layer of processing. List the apps that must keep working, then test notifications, browsing, voice calls, and switching between mobile data and Wi-Fi. Some clients let you choose a userspace network stack; names and support vary by version. No stack is most efficient on every phone. After switching, recreate the VPN and retest UDP, IPv6, and DNS resolution.

Android's “Always-on VPN” and “Block connections without VPN” options control connection behavior; they aren't performance optimizations. The latter may prevent excluded apps from connecting directly. Check both settings before testing per-app exclusions so you don't mistake a system-level block for a broken rule.

Use Android battery stats and ADB to check background activity

Start at Settings → Battery → Battery usage and check the proxy client's foreground and background time, along with data usage during the same period. Manufacturers report this differently, and a long background time only shows that a service was running; it doesn't prove anything is wrong. Investigate busy loops or repeated retries if the phone stays warm while idle on a stable network.

If you have a computer, you can run the read-only commands below after enabling USB debugging and authorizing the connection. ADB is included in Android SDK Platform-Tools; you don't need root for these checks. Output can be long, so save it on your computer and filter by process name, UID, and time period.

adb devices
adb shell pm list packages | grep -i clash
adb shell dumpsys battery
adb shell dumpsys batterystats --charged > battery-session.txt
adb shell dumpsys deviceidle > deviceidle-session.txt
adb shell dumpsys connectivity > connectivity-session.txt

grep is a computer-side filtering command. In Windows PowerShell, replace it with Select-String clash. If the package name doesn't contain clash, the first filter may return nothing; search the full package list for the client's actual package name. Don't use another client's package name to interpret the stats.

• dumpsys battery: check battery level, charging state, and temperature. Temperature is commonly reported in tenths of a degree Celsius; interpret it in context.
• batterystats --charged: view records from the current battery statistics cycle. This isn't an automatic report for the last 60 minutes or a precise measurement of hardware power.
• dumpsys deviceidle: check idle state and related exemptions. A single output can't be used to calculate battery savings.
• dumpsys connectivity: help check VPN and underlying network status. Available details vary by Android version, and reports may include network identifiers.

A USB connection may charge the phone and affect battery comparisons. Run performance checks and battery-drain tests separately; don't count battery changes while plugged in as screen-off drain. Before sharing these files, check them for network names, addresses, and app usage details.

Narrow down the configuration by symptom, then verify everyday use

Keep a stable configuration: start with health checks at 900 seconds, set subscription updates to match your needs, enable detailed logs only to reproduce an issue, and grant background access only to clients that need to stay running. If failed nodes take too long to detect, shorten the interval gradually instead of switching straight back to full checks every few dozen seconds.

After making changes, test screen-off notifications, switching between Wi-Fi and mobile data, voice calls, and connectivity after a reboot. Check both battery use and reliability. If the phone still gets hot or CPU usage stays high, report the client and core versions, Android version, a minimal reproduction configuration, and a short log. See the configuration reference for field definitions, or visit Troubleshooting for basic connection issues.