How to Reduce Clash Battery Drain on Mobile: Background Running and Power-Saving Settings

First confirm whether the battery drain comes from the proxy or foreground activity

A phone reporting high battery use by the Clash client does not necessarily mean the proxy core is consuming significant CPU continuously. Android may attribute VPN interface forwarding, background services, and some network activity to the client; iOS may attribute Packet Tunnel network extension activity to the associated app. Keeping the screen on, repeatedly opening the log page, running continuous speed tests, and refreshing subscriptions can all inflate short-term usage figures.

Before drawing conclusions, run a controlled idle test. Charge the battery above 80%, turn off the screen, keep the network conditions unchanged, and record the battery change over two hours with the proxy enabled and disabled. Do not download large files, stream video, or switch between Wi-Fi and mobile data during the test. The battery percentage shown in system settings can be misleading: it represents the app’s share of total usage during that period, not independently measured milliamp-hours.

Why health checks keep waking the network

More nodes mean denser health-check traffic

A proxy provider’s health check periodically accesses a test address through each node, then marks nodes as available or unavailable based on the response. If a subscription contains 80 nodes and the interval is set to 300 seconds, the client may establish dozens of connections every five minutes. Each request transfers little data, but handshakes, TLS negotiation, wireless wake-ups, and retries after failures all add power consumption.

A phone usually does not need a full check every 300 seconds. For everyday browsing, increase the interval to 900–1800 seconds and enable lazy checks. `lazy: true` reduces proactive testing when a provider is not actually being used, although the exact trigger behavior depends on the mihomo version and client settings. For configurations that use only a few fixed nodes, 900 seconds usually balances failure detection with idle battery use.

proxy-providers:
  mobile-subscription:
    type: http
    url: "subscription URL"
    path: ./providers/mobile.yaml
    interval: 86400
    health-check:
      enable: true
      lazy: true
      url: https://www.gstatic.com/generate_204
      interval: 900
      timeout: 5000

Here, `interval: 86400` is the subscription update interval, measured in seconds; `interval: 900` under health checks is the node testing interval. They serve different purposes. Setting subscription updates to every 24 hours does not stop nodes from being checked every 15 minutes. If the client offers separate “auto-update” and “auto-speed-test” options, check both independently.

Automatic speed tests use more power than availability checks

An availability check only confirms that a test address responds; latency sorting measures response times across multiple nodes; a bandwidth test transfers substantially more data. On mobile, avoid automatically testing every node every few minutes. Keep availability checks enabled, run full speed tests manually, and use them when the node list changes or the current route becomes noticeably slower.

• Fewer than 20 nodes: set health checks to 900 seconds.
• 20 to 100 nodes: use 1800 seconds and enable lazy checks.
• More than 100 nodes: trim the subscription groups first, then consider extending the interval to 3600 seconds.
• Weak cellular signal: pause bulk speed tests to avoid repeated retries from failed connections.

The real impact of DNS queries and rule matching

In Fake-IP mode, Clash receives DNS queries from apps, stores the relationship between domains and mapped addresses, and lets rules match by domain. This process is usually not the main source of battery drain. The real concerns are repeated requests after failed lookups, too many remote DNS upstreams, connection rebuilding after network changes, and apps continuously making telemetry or sync requests in the background.

Reduce ineffective upstreams and timeout retries

A mobile configuration does not need a long list of DNS servers. Keep two stable upstreams per group. If several encrypted DNS servers respond slowly or cannot be reached on the current network, queries wait for timeouts and then try other upstreams. One failure has little impact, but repeated timeouts from background apps keep the wireless radio active longer.

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  ipv6: false
  nameserver:
    - https://223.5.5.5/dns-query
    - https://1.12.12.12/dns-query
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "time.*.com"

`ipv6: false` is appropriate only when the current proxy nodes, rules, and network do not depend on IPv6. If your home broadband or mobile network needs IPv6 resources, do not disable it solely to save power. First check the logs for repeated AAAA lookup failures, unreachable routes, or connection fallback, then decide whether to change the setting.

The Fake-IP filter list should not grow without limit. Too many filters do not directly cause obvious battery drain, but they can make some apps bypass the intended domain mapping and trigger extra lookups and connection attempts. Add local network device names, time-sync domains, and app domains that explicitly require real addresses; keep everything else lean.

Where TUN mode and system VPN battery use meet

Clash-style clients on Android and iOS typically take over traffic through the system VPN interface. With TUN enabled, app traffic enters a virtual network interface, where the core handles DNS, rule matching, and proxy forwarding. Compared with an HTTP proxy configured for a single app, TUN covers more traffic and therefore handles more background connections.

TUN does not automatically mean high battery use. With a sound configuration and stable nodes, the added overhead is usually limited. Abnormal drain is more often caused by repeated node reconnections, rules that create connection loops, many long-lived connections on a weak signal, or the system repeatedly stopping and restarting the VPN service. Rebuilding a tunnel repeatedly often uses more power than maintaining a stable tunnel.

Android: allow necessary background activity

On stock Android 14 and Android 15, for example, open “Settings” → “Apps” → “Clash client” → “App battery usage” and enable “Allow background usage.” Some manufacturers label this “Unrestricted,” “Allow background activity,” or “Don’t optimize.” The wording varies, but the goal is the same: prevent the system from ending the VPN service after the screen is locked.

If you need the proxy to stay connected, open “Settings” → “Network & internet” → “VPN,” tap the settings button beside the client, and enable “Always-on VPN.” Enable “Block connections without VPN” only after confirming that all required traffic works correctly. A bad node or configuration can leave the entire device without network access when this option is enabled.

More background permissions are not always better. Notifications, startup launch, and VPN background activity may be needed to keep the connection alive; floating windows, continuous location access, and nearby-device scanning should be enabled only when the client actually requires them. In system battery settings, avoid conflicts between “allow background activity” and a third-party phone manager’s “clean up when screen is locked” rule.

iOS: Low Power Mode and network extensions

iOS clients run proxy tunnels through Network Extension. Open “Settings” → “General” → “VPN & Device Management” → “VPN” to confirm the configuration status; battery records are under “Settings” → “Battery.” When viewing “Last 24 Hours” and “Last 10 Days,” distinguish background activity from foreground screen-on time.

Low Power Mode limits background refresh for some apps, but an established VPN tunnel is managed by the system; repeatedly opening the client should not be necessary to keep it alive. If the tunnel disconnects frequently after the screen is locked, first check the client’s on-demand rules, node stability, and system logs instead of repeatedly turning the VPN off and on. Each toggle rebuilds the interface, DNS state, and proxy connection.

Three practical power-saving profiles

Profile 1: Always online

1. Set automatic subscription updates to once every 24 hours.
2. Set the health-check interval to 900 or 1800 seconds and enable lazy checks.
3. Choose a node with stable latency instead of a strategy that triggers a full-group speed test every time it selects a route.
4. Keep TUN or the system VPN enabled and allow the client’s necessary background activity.
5. Keep live logs and connection lists closed; open them temporarily only when troubleshooting.

Profile 2: Connect only when needed

1. Turn off the system’s always-on VPN.
2. Add the client’s quick toggle to Android Quick Settings or the iOS Control Center.
3. When finished, use the client’s stop button to end the VPN instead of merely leaving the interface.
4. After starting it next time, check the subscription’s last update time before refreshing manually.

Profile 3: Prioritize battery life on weak signals

1. Avoid running node speed tests on the subway, in elevators, or at the edge of coverage.
2. Extend the health-check interval to 1800–3600 seconds.
3. Pin one recently stable node to reduce automatic switching.
4. Pause unnecessary cloud-drive sync, photo backups, and background video playback.
5. Run subscription updates and node availability checks only after the network becomes stable again.

Validate the optimization with reproducible data

One reference test used these conditions: Pixel 8, Android 15, Wi-Fi signal around -48 dBm, normal battery health, and the screen off for two hours. With 76 nodes and full health checks every 300 seconds, battery use fell by 3% in two hours; at 1800 seconds with lazy checks enabled, it fell by 1%. The same device with VPN disabled also fell by 1%. These figures illustrate the test method and do not represent results for every phone.

In one four-hour idle test on an iPhone 15 running iOS 18.6, battery use fell by 2% with a stable node and on-demand connection rules; it fell by 5% when frequent automatic speed tests were enabled and Wi-Fi and cellular data were switched several times. iOS reports battery levels as whole percentages, so tests shorter than two hours have greater error; four-hour or overnight comparisons are more useful.

Change only one variable per test round. Adjust the health-check interval first, DNS in the next round, and then compare the TUN setting. If five settings change at once, even a lower battery drain cannot show which change helped. Also record room temperature, signal type, node, download activity, and screen time.

Troubleshooting order when battery drain remains abnormal

Step 1: Pause automatic tasks

Disable automatic speed tests, temporarily set health checks to 3600 seconds, and pause automatic subscription updates. Lock the screen and test for two hours. If battery use drops noticeably, restore features one at a time. If nothing changes, the cause may be the node connection, another background app, or the system network environment.

Step 2: Check for repeated errors

Open the runtime log for three to five minutes and look for `timeout`, `network is unreachable`, `connection reset`, and repeated DNS failures. The same target reporting errors every few seconds suggests that the connection may be retrying continuously. Switch to a stable node first, then verify the DNS and IPv6 settings.

Step 3: Compare Wi-Fi and mobile data

Run one test on stable Wi-Fi, then run a test of the same length on 4G or 5G. If the problem occurs only on mobile data, first check signal strength and network-mode changes. Frequent switching between 5G, 4G, and no service can drain significant battery even with the proxy disabled.

Step 4: Check configuration size

An oversized rule set increases startup parsing time and memory use, but after the client is stable, actual network activity is usually the main burden. Temporarily use a minimal configuration with one proxy group, a small number of rules, and one DNS setup. If it behaves normally, add rule providers and proxy providers gradually.

Step 5: Update the client and core

Confirm that the client uses a maintained version, then check its core version and release notes. Different mihomo versions may fix mobile network switching, DNS caching, or TUN connection issues. Export the current configuration before upgrading; afterward, retest with the original configuration instead of changing many parameters at once.

Power-saving settings: the bottom line

Saving battery on mobile Clash is not about disabling every background capability; it is about reducing pointless wake-ups and reconnections. Keeping health checks at 900–1800 seconds, enabling lazy checks, stopping high-frequency full-node speed tests, and using stable DNS and nodes is usually more effective than repeatedly force-stopping the client.

On Android, address conflicts between system battery optimization and the VPN background service; on iOS, check on-demand connections, network extension status, and behavior in Low Power Mode. TUN can stay enabled long term if nodes are reliable, rules do not create connection loops, and the network is stable. After making changes, verify the result with a two- to four-hour idle comparison before adjusting anything else.