Clash Battery Drain on Android and iOS: Background Settings and Troubleshooting

Separate actual battery drain from how usage is attributed

Compare under the same conditions before changing settings. A VPN icon that stays in your phone’s status bar only means the system tunnel is connected; it doesn’t mean the processor is running at full load. Look for more meaningful signs: noticeable heat after locking the screen, increased battery drain while idle, or repeated connection failures and reconnects in the logs.

Clash refers to a core and configuration ecosystem, not one identical app for Android and iOS. Clash Meta later adopted the name mihomo, and clients can differ in their cores, tunnel implementations, and settings. On iOS in particular, being able to import some Clash-format configurations doesn’t mean a client supports every mihomo field. The system paths and checks below are broadly applicable, but refer to your client’s documentation for configuration fields.

Set a baseline with two 30-minute tests

1. Choose a period when your phone isn’t charging and signal is stable. Keep screen brightness, network type, and node the same. Don’t download system updates or sync a large batch of photos during the test.
2. First, disconnect the client, lock the screen, and leave the phone idle for 30 minutes. Note the starting and ending battery levels, network type, and whether the phone feels warm.
3. Then connect the client and repeat the 30-minute screen-locked test under the same conditions. Don’t repeatedly run latency tests or keep live logs open during the test.
4. If the two tests differ by only one percentage point, run a longer comparison. Battery indicators are rounded, so a single short test isn’t enough to identify the cause.

For example, a drop from 80% to 79% versus 79% to 75% is a difference worth investigating further. This is only an example of how to record results, not a measured result for any particular client. Weak signal, background backups, and battery wear can also explain the difference, so don’t draw conclusions from a single battery-usage screenshot.

Keep TUN available without running duplicate tunnels

Android clients typically route traffic through the system VPN service; some call the relevant setting VPN or TUN. iOS clients generally use the system’s Network Extension tunnel. Don’t apply desktop advice like “turn off TUN and use only the system proxy” without checking: on phones, system proxy settings may not cover traffic from every app.

First, check for competing traffic interception tools

• Temporarily disable other VPNs, firewalls, or filtering tools that use a local VPN, then start the client you’re troubleshooting. On a given system user or configuration scope, these tools generally can’t each maintain a separate active VPN tunnel.
• Check whether the client keeps switching from “Connected” to “Connecting.” If it reconnects every few dozen seconds, fix the reconnection issue first instead of adding more keep-alive options.
• Test on a stable Wi-Fi connection, then try cellular. If the phone gets warm only with a weak signal or while switching networks, investigate the network and node first rather than assuming TUN is the problem.

Rule mode only determines how intercepted traffic is routed. A connection matched to DIRECT may still be processed by the client; it doesn’t necessarily bypass the tunnel entirely. If your Android client supports per-app proxying, exclude apps that truly don’t need to be intercepted to reduce unnecessary processing. Check whether the list means “proxy only selected apps” or “bypass selected apps”—the two options work in opposite ways.

Consumer iOS clients don’t necessarily offer Android-style per-app routing for arbitrary apps. Don’t keep changing system settings to hunt for a similarly named option. On managed devices, per-app VPN may also be restricted by organizational policies.

Keep Android apps running in the background—only exempt clients that are actually restricted

A connection drop after locking the screen and high battery drain can be part of the same cycle: the system pauses the client, the app fails to connect, and then it repeatedly reconnects once you unlock the phone. Don’t set every app on your phone to “Unrestricted.” First confirm that the system is actually restricting the client.

Check the relevant settings for your Android version

• Pixel and other near-stock Android devices: Go to Settings → Apps → See all apps → your client → App battery usage, then check options such as “Allow background usage.” Some Android versions offer “Optimized” and “Unrestricted” here.
• Samsung One UI: Go to Settings → Battery → Background usage limits and check whether the client is listed under “Sleeping apps” or “Deep sleeping apps.” On older versions, look under Settings → Battery and device care → Battery.
• Other Android variants: In the app’s settings, look for “Battery,” “Background,” or “Auto-start.” Grant the relevant permission only if you’ve confirmed that the process is being killed or the connection won’t recover after a restart.

After changing one setting, lock the screen for 15–30 minutes, then check the client’s connection duration and logs. If the tunnel stays up and the connection works normally, there’s no need to enable every keep-alive permission. Android VPN clients commonly use a foreground service to keep running; a persistent notification alone isn’t evidence of excessive battery use.

iOS background connections: check on-demand rules instead of force-quitting apps

The iOS proxy tunnel extension and the client’s foreground interface don’t share the same lifecycle. The tunnel may keep running after you leave the app. Background App Refresh also isn’t a master switch for whether every VPN tunnel can run. For that reason, repeatedly swiping the client away isn’t a good everyday battery-saving strategy.

1. Go to Settings → Battery and compare activity before and after connecting the client, along with the overall battery level. Depending on your iOS version, you may see the past 24 hours or daily usage; use the view available on your device.
2. Go to Settings → General → VPN & Device Management → VPN and check the active configuration. On-Demand settings may be in the configuration details or managed by the client.
3. If the VPN reconnects immediately after you disconnect it manually, check whether On-Demand is enabled. If it keeps switching only on a particular Wi-Fi network, review the On-Demand rule for that network.
4. Start by observing the phone on one network for 30 minutes, then test switching between Wi-Fi and cellular. Don’t change On-Demand rules, DNS, and nodes at the same time, or you won’t know which change helped.

Low Power Mode limits some background activity, but it won’t fix a failed node, incorrect DNS, or a connection policy that keeps triggering. If the phone still gets warm with Low Power Mode enabled, check connection logs and traffic sources instead of looking for more aggressive system battery settings.

DNS queries and retries: look for recurring errors first

Normal DNS queries are usually cached, so seeing DNS resolution entries in the logs doesn’t by itself indicate excessive battery use. Look instead for repeated failures for the same domain, an unreachable upstream DNS server, a resolution loop, or an app repeatedly retrying after connection failures.

Enable logs temporarily and watch for 2–5 minutes

1. In the client’s log screen, search for terms such as timeout, DNS, and failed, and check whether the errors keep recurring.
2. Note when the error occurred, the domain, and the upstream address. One timeout may be a temporary network issue; repeated identical errors are worth investigating first.
3. On Android, go to Settings → Network & internet → Private DNS and note the current setting. If a custom hostname is configured, you can temporarily switch to “Automatic” as a controlled test to check for conflicts with the client’s DNS path. Restore the original setting afterward if needed.
4. On iOS, check for additional DNS profiles or DNS apps. Reduce the number of variables first, then restore any required settings according to your client’s documentation.

Don’t disable certificate verification at random to fix encrypted DNS failures. First check the system date, network reachability, and upstream settings. fake-ip isn’t a “always drains battery when enabled, saves battery when disabled” switch either. Changing it can affect app compatibility, so test it only when logs or reproducible steps point to a DNS issue.

If mihomo’s DNS upstream needs to go through a proxy, make sure bootstrap resolution and node hostname resolution are reachable. Avoid a dependency loop where DNS requires the proxy and the proxy requires the same DNS result. Starting with the basic DNS settings provided by your subscription is usually easier to troubleshoot than combining several configurations from unknown sources. See the configuration reference for more on individual fields.

Latency tests, rule sets, and subscription updates: space out background tasks

Battery drain doesn’t always come from active browsing. Frequent latency tests across multiple proxy groups and repeated rule provider downloads can generate background traffic. On a weak cellular signal, even small, frequent requests can repeatedly wake the radio.

These are starting points for comparison, not ideal values for every device. In mihomo, the interval for a url-test proxy group and the rule provider update interval are generally measured in seconds. The client’s subscription update setting may use a different unit. 600 seconds is 10 minutes; 86400 seconds is 24 hours. Check the units before entering a value.

Check for duplicate latency tests, not just the interval for one group

Suppose a configuration has four automatic test groups, each listing 20 nodes, and each group tests every 60 seconds. That’s 80 test entries per round in theory. The actual request volume also depends on lazy testing, whether a group is in use, and core scheduling, so this isn’t a fixed request count—but it’s enough to warrant checking for duplicate tests. Remove test groups you don’t use, or enable on-demand testing if your client supports it.

Make a copy of your configuration before editing. Changes made directly to YAML downloaded from a remote subscription may be overwritten on the next update. Use the client’s persistent override or merge feature if available. If your iOS client doesn’t support these mihomo fields, adjust its own “Automatic testing” or “Update interval” settings instead of pasting in an incompatible configuration.

Narrow it down by symptom: settings for stable connections and longer battery life

For everyday use, start with this setup: rule mode, one stable active node, less frequent automatic tests, subscription updates at a reasonable interval, and the default or info log level. On Android, lift background restrictions only if the system is actually stopping the client. On iOS, configure On-Demand connections to suit your network needs instead of repeatedly toggling the tunnel manually.

Change one setting at a time and keep at least one test window under the same conditions. If the problem persists, note your phone model, OS version, client version, core version, network type, starting and ending battery levels, and error times, then continue troubleshooting by symptom in the Help Center. Before sharing logs, redact subscription links, tokens, node addresses, and personal browsing records. Don’t upload a complete subscription file publicly.