Android Proxy App Battery Drain: Background Restrictions, Battery Optimization, and TUN Settings

First, separate battery drain, usage attribution, and background disconnections

A high battery ranking for an Android proxy app doesn't tell the whole story. Once an app uses Android's VpnService to handle connections, the system may attribute some network activity and related battery use to the VPN app. Attribution also varies across Android versions and manufacturers. An app near the top of the list isn't necessarily responsible for that share of the phone's total battery drain.

Compare the phone's battery drop under the same conditions first, then check connection stability, and only then adjust background permissions and configuration. If the connection drops only when the screen is off, start with background restrictions. If standby drain increases noticeably, check health checks, reconnection attempts, actual background traffic, and mobile signal strength. Both issues can occur at once, but they call for different fixes.

Create comparable standby measurements

Run each test for at least 60 minutes and change one variable at a time

Choose the same location and network, and start with a similar battery level each time—for example, around 80%. Pause system updates, photo backups, and large downloads. Close the client's live connection panel and keep the screen off. For the first round, stop the proxy service; for the second, enable the same subscription; for the third, change just one setting you suspect. Test each round for at least 60 minutes; for light-use scenarios, extend it to 2–3 hours.

• Track total battery change: Starting and ending levels, test duration, screen-on time, and whether the phone was charging.
• Track network conditions: Wi-Fi or mobile data, notable signal fluctuations, and any switches between networks.
• Track client details: Product and version, core version, configuration name, and whether per-app routing is enabled.
• Track activity: Whether audio was playing, messages were arriving, photos were backing up, or a hotspot was active.

For example, if the battery drops from 80% to 76% over two hours in one test, then from 80% to 73% in another, the average drain is 2 and 3.5 percentage points per hour, respectively. These figures illustrate the calculation only; they are not product test results or a pass/fail threshold. Battery percentages are rounded, so a one-point difference in a single test isn't enough to draw a conclusion. Repeat the tests and account for differences in temperature, signal, and background activity.

Battery optimization: Allow background access only when needed

Android Doze, app standby restrictions, and manufacturer background controls can affect network access and scheduled tasks. Setting a client to “Unrestricted” can reduce interference from some battery policies, but won't fix node timeouts, DNS loops, or incorrect rules—and it can't guarantee the process will never be stopped. Prioritize background permissions only if you see issues such as disconnections with the screen off or the service repeatedly stopping.

Find your app's battery settings

1. Long-press the client icon, open “App info,” then look for “Battery” or “App battery usage.”
2. On some stock Android 13 devices, go to Settings → Apps → See all apps → select the client → App battery usage, then choose “Unrestricted.” Other versions may show an option such as “Allow background usage.” Available settings vary by device.
3. On some HyperOS devices, look under Settings → Apps → Manage apps → select the client → “Battery saver” for the “No restrictions” option. If that path isn't available in your version, search Settings for “Battery saver.”
4. On Samsung devices, go to Settings → Battery → Background usage limits and check whether the client is in the Sleeping or Deep sleeping apps list. The menu path may differ between One UI versions.
5. Change one setting at a time, test with the screen off for 30–60 minutes, then check the notification, network connection, and logs for continuity.

“Allow autostart,” locking the app in Recents, and excluding it from battery optimization are separate controls. Locking an app in Recents usually only makes it less likely to be dismissed by a “close all” action; it doesn't guarantee that Android will keep the process alive. If you need the client to connect after a reboot, also check its launch-on-boot setting and the system's autostart permission. If you don't need automatic connections, there's no reason to enable them just for a standby test.

If total battery drain increases after removing battery restrictions, investigate connections and logs: tasks that were previously limited may now run continuously. Exempting an app gives it more opportunity to run; it doesn't make its tasks more efficient.

VPN always-on and TUN: Check how traffic is actually routed

Clash clients on Android typically use VpnService to create a virtual network interface, then rely on a core or companion forwarding component to handle connections. Don't apply desktop advice like “turn off TUN and use only the system proxy” directly to a phone. Android's Wi-Fi proxy is configured per network, not every app honors it, and it isn't a universal system-wide proxy.

In a client, “TUN,” “VPN mode,” and “network stack” may refer to different implementation layers. Some products don't have a separate TUN switch; disabling the VPN service means traffic is no longer routed through it. Network stack options also depend on the client and core version, so switching stacks isn't a universally effective way to save battery.

Choose the traffic coverage that matches your needs

• Proxy only a few apps: If the client supports selecting specific apps, include only those that need proxying. Read the mode description first and confirm whether selected apps are routed through the VPN or bypass it.
• Use rule-based routing: Keep rule mode enabled and make sure mainland China services or local network destinations match the intended direct-connection rules. Traffic that matches DIRECT after entering the VPN path has still been handled by that path.
• Keep the connection active: Consider Android's “Always-on VPN” setting. On some stock Android devices, find it under Settings → Network & internet → VPN → the settings icon for the connection.
• Prevent traffic from bypassing the VPN: Consider “Block connections without VPN” only if needed. This is a connection policy, not a battery-saving setting. Test it carefully with app bypass rules and local network access.

Subscriptions, health checks, and reconnections: Find periodic wakeups

An idle client doesn't necessarily mean the configuration has no scheduled tasks. Subscription updates, proxy provider health checks, url-test group tests, and heartbeats from apps in use can all generate background requests. Multiple mechanisms may test the same nodes repeatedly, so check both the client settings and the effective configuration when troubleshooting.

Check these four things first

1. Health check interval: In mihomo, the interval for proxy group and proxy provider health checks is usually measured in seconds. An interval of 30 seconds means 120 scheduled checks per hour; 300 seconds means 12. The actual number of requests also depends on the number of nodes, lazy checks, and implementation, so it can't be directly translated into battery use.
2. Lazy checks: If supported, consider lazy: true to reduce unnecessary checks for unused groups or providers. Place the field at the appropriate configuration level; client overrides may also change the effective result.
3. Subscription updates: Most everyday use doesn't require updating subscriptions every minute. Follow your provider's update schedule and choose updates every few hours or manual updates to avoid repeatedly downloading, parsing, and reloading the configuration.
4. Failed connection retries: If the logs show repeated timeouts, first select a node that connects reliably, then see whether repeated connection attempts continue. Increasing the speed-test interval won't fix a node that keeps failing in active use.

Don't delete all automatic policies at once just to reduce probes. Start by increasing an overly short test interval to, say, 300 seconds, then check node switching and standby data. This is a troubleshooting starting point, not a recommendation for every subscription. A subscription manager may overwrite edits during updates, so use the client's persistent override feature if available and verify the effective configuration after updating.

DNS, logs, and background activity: Find what's keeping the device busy

Fix DNS errors at the source instead of just switching modes

If the logs repeatedly show DNS timeouts, check whether the upstream DNS server is reachable, whether proxy server hostnames resolve, and whether DNS connections depend on a proxy that hasn't been established yet. mihomo's proxy-server-nameserver can resolve proxy node hostnames, but it still needs to fit your existing DNS routing design. Adding a single field isn't enough to confirm the problem is fixed.

Fake-IP uses virtual addresses to map domains to connections; it isn't, by itself, evidence of excessive battery drain. Change the related filtering or DNS strategy only when a specific app has a demonstrable compatibility issue. Android's “Private DNS” can also route app lookups differently from the client's configuration. Note the original setting before changing it, so you don't alter two DNS layers at once and lose track of the cause.

Limit diagnostic logging and check where traffic is coming from

• Keep the client's default log level for normal use. If you temporarily enable debug, capture only the 5–10 minutes needed to reproduce the issue, then switch it off again.
• Don't leave the connection list or live speed panel refreshing with the screen on, then treat that battery use as a screen-off standby result.
• Check for long-running connections from photo uploads, cloud drive sync, video preloading, and similar activity. The proxy client may simply be forwarding traffic generated by those apps.
• Compare Wi-Fi with mobile data. Weak signals and frequent reconnections can increase radio power use even when the proxy configuration hasn't changed.

Advanced diagnostics: Use ADB to check battery and idle status

If you're comfortable with debugging, use ADB from a computer to read system data. These commands don't require root, but USB debugging must be enabled and the computer authorized. Available fields and output vary by Android version; don't convert a single counter directly into battery use attributed to the client.

adb shell dumpsys battery
adb shell dumpsys batterystats --charged
adb shell dumpsys deviceidle

dumpsys battery can help check battery level, charging status, and temperature; batterystats shows accumulated system battery activity; and deviceidle reports the device idle state. Don't force the phone into idle mode just to test it—this changes normal usage conditions.

A USB connection may charge the phone at the same time, so these commands are best used to capture data before and after a test. For a consistent long-term comparison, disconnect power before you start recording. Wireless debugging also creates network activity, so don't assume it has zero overhead. Before sharing logs, remove any information you don't want public, such as subscription URLs, node credentials, visited domains, and app package names.

Final checklist: Test stability and battery use separately

1. Establish a baseline: Use the same network and location, and compare at least one test with the service running against one with it stopped. Don't use the battery ranking as a substitute for total battery drain.
2. Check background behavior: If connections drop with the screen off, remove battery restrictions and grant permissions such as autostart one at a time, recording each change.
3. Check traffic: Use per-app routing if needed and avoid unnecessary background activity. Confirm that messaging, local network access, and essential apps still work.
4. Check configuration: Review health check intervals, subscription updates, node retry behavior, and whether overrides remain active after configuration updates.
5. Finish diagnostics: Restore the normal log level, close live panels, and run another screen-off test.
6. Report persistent issues: Include the phone model, Android version, client and core versions, reproduction time, network type, and redacted logs.

If a repeatable standby difference appears only after an update under the same conditions, include the version change in your report rather than blaming all TUN implementations or every Clash client. To choose a client, check platform support and maintenance status on the downloads page; for configuration concepts, see the user guide. The goal is to keep the connection reliable while reducing unnecessary activity you can identify and verify.