Clash Mobile Battery Drain Troubleshooting: Background Activity, Battery Optimization, and Connection Settings

1. Establish a comparable battery-use baseline

Looking only at the “Last 24 Hours” battery ranking can be misleading because of screen time, video playback, cellular signal strength, and system updates. Choose a period with similar usage instead, such as two hours of overnight standby or one hour of normal work. Compare proxy disabled, system proxy only, and TUN or VPN takeover enabled. Keep the network, node, and app activity consistent throughout the test.

Record four key details

1. Battery change: Record the battery level at the start and end. Do not look only at the client’s percentage ranking in system statistics. The ranking is relative, so a proxy client may appear near the top even when its actual use is modest if other apps are barely active.
2. Device temperature: If the device remains warm after the screen turns off, repeated reconnects, heavy logging, frequent speed tests, or abnormal network requests are likely.
3. Service continuity: Check whether the VPN icon repeatedly disappears, whether the proxy returns only after unlocking the screen, and whether the client log shows repeated starts within a short period.
4. Network conditions: Distinguish Wi-Fi, cellular data, weak-signal, and network-switching scenarios. Poor cellular reception can increase modem power use on its own, so do not attribute all drain to Clash.

If battery use with the proxy enabled is only slightly above the baseline, with no heat or service restarts, there is usually no need to disable every feature. Overly aggressive background restrictions can cause the system to terminate the VPN service, after which the client or system starts it again. This “stop–start–reconnect” cycle can ultimately use more power than stable operation.

2. Check background activity and system battery optimization

Android manufacturers commonly provide system battery optimization, app background-activity limits, auto-start management, and power-saving modes. These controls may take effect together: even when background activity is allowed, a deep power-saving policy may restrict networking after the screen turns off; even when auto-start is allowed, the app may still stop its VPN service because it is assigned a “restricted” battery mode.

Android check order

1. Open system app settings and find the Clash or mihomo graphical client you are using.
2. Open Battery or Battery usage management and move the app out of “Restricted” mode into one that allows background activity. Depending on the system, this may be called “Unrestricted,” “Allow background activity,” or something similar.
3. Check manufacturer-specific options such as auto-start, associated launch, and background pop-up permissions. The goal is only to let the system restore the service normally if it is reclaimed; unrelated permissions do not need to be enabled.
4. Check whether the system power-saving mode disables VPN, restricts background networking, or delays scheduled tasks. Exit extreme power-saving mode during testing.
5. Locking the app in the recent-apps view can help, but it is only a supplementary measure. Some systems still reclaim services according to battery policy, so this cannot replace the app’s battery settings.

If the issue is “the network drops after ten or twenty minutes of screen-off time and returns when the client is opened after unlocking,” first suspect restrictions on background networking or the VPN service. If the proxy remains available but the client shows unusually long background activity, continue checking health checks, subscription updates, log level, and node reconnects instead of immediately disabling background access.

Frequent restarts usually use more power than staying resident

When starting the proxy service, the client must read the configuration, load rule sets, initialize DNS, create a virtual network interface, and connect to a node. If the system reclaims the service periodically, the client repeats all of these operations. If the log repeatedly shows configuration loading, VPN setup, interface creation, and node connection, focus on system background policy or client stability rather than simply trying to shorten background residency.

3. Compare connection modes, node stability, and reconnect behavior

Mobile clients typically use the system VPN interface to take over traffic. Its role is similar to TUN mode in a Clash configuration, although the exact implementation depends on the client and operating system. Compared with letting only selected apps use system proxy settings, VPN or TUN takeover covers more traffic and must handle more connections, DNS requests, and routing decisions, so its fixed overhead may be higher. Use the options actually provided by the mobile client when switching modes.

Why TUN or VPN mode may use more power

• Every connection passing through the virtual interface must be read by the kernel and matched against rules, including traffic from some system services and background apps.
• UDP, real-time communications, and long-lived connections may need to maintain session state and may be re-established after a network change.
• DNS interception, Fake IP, or enhanced DNS modes add local query processing. They do not inherently cause abnormal drain; the key concerns are query loops, timeout retries, and configuration conflicts.
• When switching between cellular data and Wi-Fi, old connections fail and new ones must select an exit again. Slow node handshakes can amplify power use during this phase.

If the client supports proxying only selected apps or bypassing LAN traffic, narrow the takeover scope to what you actually need. Local casting, printing, or network-storage access that does not require a proxy can use a direct connection. Do not exclude system components that need the proxy just to save power, or some apps may lose connectivity, DNS paths may diverge, or connections may leave through the wrong exit.

Unstable nodes are a common hidden cause

High node latency does not necessarily mean high battery use, but frequent timeouts and disconnects trigger retries, proxy-group reselection, and application-level connection rebuilding. Start by fixing one confirmed stable node and temporarily avoid an automatic proxy group that switches frequently. If temperature and background activity fall, then inspect the group’s test URL, test interval, and switching threshold.

url-test tests candidate nodes at the configured interval and selects a qualifying result; fallback focuses on availability and switches when the current node fails; load-balance distributes connections according to its policy. With many nodes and very short test intervals, periodic probing creates extra network wakeups. On mobile, there is no need to put dozens of nodes into a high-frequency test group; start by selecting commonly used regions and consistently reliable nodes.

proxy-groups:
  - name: Automatic selection
    type: url-test
    proxies:
      - Node-A
      - Node-B
      - Node-C
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 100

The example only illustrates how to control the number of candidates and the testing frequency; it does not mean every subscription should use the same values. The test URL must reliably return the expected result. If it cannot be reached consistently on your network, the client will keep receiving failures and repeat tests or node switches.

4. Narrow the scope of checks for rules, DNS, and scheduled tasks

A large number of rules does not automatically mean abnormal battery use. mihomo uses the appropriate matching method for each rule type, and a well-maintained large rule set is usually more stable than the impact of network retries. Focus on frequently updated rule providers, repeated configuration loads, complex scripts, DNS query loops, and continuous log writes.

Check rule-provider update intervals

Remote rule sets and subscriptions periodically request files and reload them. If several rule providers use very short update intervals, the mobile device will wake the network frequently. Domain or IP rule sets that rarely change usually do not need updates every few minutes. First inspect rule-providers, automatic subscription updates, and scheduled refresh options in the client to make sure tasks are not duplicated.

rule-providers:
  direct-list:
    type: http
    behavior: domain
    url: https://example.invalid/rules/direct.yaml
    path: ./ruleset/direct.yaml
    interval: 86400

The address in the example only shows the field structure. Actual configurations should use a valid address provided by the subscription or rule maintainer. After changing the update interval, reload the configuration and check whether the log still shows repeated rule downloads and configuration refreshes within a short period.

Identify DNS retries and resolution loops

Common signs of abnormal DNS configuration include slow first page loads, repeated queries for the same domain in the log, failure to resolve node domains, and long connection delays after switching networks. If an encrypted DNS server itself must be reached through the proxy while the proxy node’s domain depends on that same resolution path, startup dependencies can form. Keep a usable basic DNS path for resolving nodes, and configure default-nameserver, nameserver, and proxy-server domain resolution according to the client and kernel documentation.

Fake IP mode assigns virtual addresses to domains, while the kernel stores the mapping between domains and connections. It can improve rule matching and transparent-proxy compatibility, but some LAN services, specialized apps, or probe domains may need to be added to a filter list. A filter that is too broad reduces the mode’s benefits; one that is too narrow can make incompatible apps retry continuously. During troubleshooting, address the specific domains that repeatedly fail in the log instead of copying an oversized filter list.

Reduce continuous writes caused by debug logging

Verbose logs are useful for short-term diagnosis, not for permanent use. With the log level set to debug, large volumes of connection, DNS, and rule-matching data may be written continuously to storage and increase the cost of refreshing the interface. After diagnosis, return to info, warning, or the client’s recommended daily level. Clearing old logs only frees space; the settings that affect future behavior are the log level and recording frequency.

5. Background-mechanism differences between Android and iOS

Android: focus on whether the VPN service is being reclaimed

Android clients generally establish a local VPN through VpnService. The persistent notification in the system notification shade is usually tied to a foreground service and tells the system that the network service is intended to keep running. Manually disabling notification access, restricting background activity, or enabling a manufacturer’s deep-sleep mode may affect service stability. Exact behavior depends on the system version and client implementation, so compare system battery records with client logs.

Android can also show system information such as app crashes, unresponsiveness, and launch counts. If the client itself exits frequently, first upgrade to a stable version compatible with the current system and verify that the same configuration loads normally. An oversized configuration, syntax error, or memory pressure can cause startup failure, but “the proxy disconnected” alone does not prove a kernel crash.

iOS: distinguish the app interface from the network extension

Compatible clients on iOS usually provide proxy or VPN capabilities through Network Extension. After the app interface enters the background, the network extension may still be managed by the system, so removing the app from the multitasking view is not necessarily the same as tapping Stop inside the client to end the tunnel. Battery statistics may also assign some network activity to the client, system networking services, or the app currently transferring data.

When troubleshooting iOS battery drain, check Low Power Mode, cellular signal quality, on-demand connection rules, and the client’s node-testing schedule. With on-demand connections enabled, changes in network conditions trigger rule evaluation; combined with frequent health checks, switching repeatedly between Wi-Fi and cellular data makes connection rebuilding more noticeable. During testing, keep the network fixed, pause nonessential node tests, and compare the battery curve again.

Regardless of platform, do not copy the other system’s background-setting names literally. Check three facts: whether the proxy tunnel stays continuous, whether the system repeatedly terminates the service, and whether the configuration keeps triggering network tasks. The settings differ, but the diagnostic logic is the same.

6. Troubleshoot mobile battery drain in stages

Stage 1: Confirm whether the proxy is directly involved

1. On the same network, record standby battery use for a period with the proxy disabled.
2. Enable the proxy and fix one stable node. Do not download files, play video, or perform large-scale synchronization.
3. Compare drain, temperature, and background activity. If the difference is small, observe a longer period instead of drawing conclusions from short-term percentage fluctuations.

Stage 2: Rule out repeated system reclamation

1. Allow the client to run normally in the background and exit the system’s extreme power-saving mode.
2. Check whether the proxy is interrupted after the screen locks and whether new startup entries appear in the log after unlocking.
3. If the service keeps recovering, check battery optimization, auto-start, background networking, and VPN permissions.

Stage 3: Reduce periodic network tasks

1. Pause automatic subscription refreshes and high-frequency updates for remote rule sets.
2. Reduce the candidate nodes in automatic proxy groups and lengthen the health-check interval.
3. Return the log level from debug to the normal daily level.
4. Fix one stable node to rule out node timeouts and repeated proxy-group switching.

Stage 4: Check DNS and takeover scope

1. Check the log for consecutive DNS timeouts, repeated queries for the same domain, or failed node-domain resolution.
2. Confirm that basic DNS can perform necessary resolution before the proxy is established.
3. Adjust app bypasses, direct LAN access, and TUN takeover scope as needed, retesting after each change.

Stage 5: Restore features and verify

After identifying a variable that clearly improves battery use, do not end the test immediately. Restore subscription updates, proxy groups, and the original rules one at a time, observing for a while after each change. If the issue returns after one item is restored, narrow the scope further. For example, if heat appears only after enabling one automatic proxy group, inspect that group’s node count, test URL, and interval instead of deleting the entire configuration.

Conclusion: Stable operation beats overly aggressive background restrictions

Abnormal Clash battery drain on mobile is rarely caused by a single switch. It usually results from system battery restrictions, VPN service restarts, reconnects to weak nodes, frequent health checks, subscription refreshes, and DNS timeouts acting together. The most effective approach is to establish a comparison between proxy-disabled and stable-proxy baselines, verify service continuity, then reduce scheduled tasks and validate DNS and node quality.

For devices that need the proxy all day, stable residency is often more efficient than repeatedly terminating and restoring the service. For devices that use a proxy only in specific situations, stop the service deliberately inside the client. After making changes, observe at least one complete normal-use cycle and record Wi-Fi and cellular behavior separately for a reliable conclusion.