Clash Battery Drain on Android & iPhone: Background Settings and Battery-Saving Tips

First, distinguish battery drain from background disconnections

Start with two checks: review your system’s battery usage and note what happens to the connection after the screen locks. Persistent heat, rising background data use, and a proxy disconnecting when the screen locks point to different problems. The first two call for reducing actual network activity; the last calls for checking background restrictions. Turning off every battery restriction may restore the connection, but it can also leave frequent health checks running and draining power.

Android mobile clients typically route traffic through the system VPN interface, while cores such as mihomo parse the configuration, match rules, and handle connections. iOS clients typically use a Network Extension tunnel. The VPN icon shows that the tunnel is connected; it doesn’t mean your phone is under constant heavy load, and it can’t identify the cause of battery drain on its own.

Set a baseline you can reproduce

1. Record your phone model, OS version, client version, and core version. Core details are usually listed under About or in the client’s runtime logs; menu names vary by app.
2. Use the same Wi-Fi network, node, and rule mode throughout. Pause system updates, photo backups, and large downloads.
3. Lock the screen for 60 minutes. Record the starting and ending battery levels, whether the connection dropped, background data used by the client, and reconnects shown in the logs.
4. Change one category of settings at a time, then repeat the test. Run at least two rounds so you don’t mistake whole-number battery display changes for a definitive result.

For example, one round might go from 80% to 77%, and another from 80% to 78%—drops of 3 and 2 percentage points, respectively. This illustrates how to record results; it isn’t a test conducted by this site. Short-term differences can also reflect signal strength, temperature, and battery estimates.

Keep Clash running in the background on Android—only where needed

Start with the default battery settings. If the connection stays up when the screen is locked, there’s no need to grant unrestricted background access. Check the client’s battery optimization settings only if the service is stopped after locking, the VPN icon disappears, or the logs show the process restarting.

Find the battery settings for your device

• Pixel / near-stock Android 14: Long-press the client icon → “App info” → “App battery usage” → check “Allow background usage.” Some systems also offer “Unrestricted,” “Optimized,” and “Restricted.”
• Samsung One UI 6: “Settings” → “Apps” → select the client → “Battery” → “Unrestricted.” Then check “Settings” → “Battery” → “Background usage limits” and make sure the client isn’t on the deep sleeping apps list.
• Other Android versions: In the app info screen, look for options such as “Battery management,” “Background activity,” or “Auto-start.” Menu names vary by manufacturer and OS update. Follow the labels on your device rather than copying steps for another phone.

Auto-start controls whether an app can launch at startup or after its process is stopped. Battery optimization controls background activity limits. Locking an app in Recents only affects cleanup behavior on some devices. These are separate settings. Change and test them one at a time; don’t add every app that uses the network to an allowlist.

Always-on VPN isn’t a battery-saving setting

Android’s “Always-on VPN” setting is mainly for maintaining the VPN connection policy. “Block connections without VPN” restricts other network access when the tunnel is unavailable. Neither is a battery optimization setting, and neither can fix an unstable node. Enable these options only if you need all traffic routed continuously, and first test how the VPN recovers after a restart, network switch, or screen lock.

iOS Background App Refresh: configure it separately from the VPN tunnel

On iOS 17 or iOS 18, check app permissions under “Settings” → “General” → “Background App Refresh.” This setting mainly controls background refresh opportunities for regular apps; it isn’t a master switch for the VPN tunnel. The tunnel extension carrying traffic runs differently from the client’s main app. Turning off Background App Refresh won’t necessarily disconnect the VPN, and turning it on doesn’t guarantee the tunnel will stay active indefinitely.

• If you import configurations and update subscriptions manually, try turning off Background App Refresh for the client’s main app, then check whether the tunnel still works as expected.
• If you rely on automatic subscription updates, check whether the client supports them, whether they require Background App Refresh, and what conditions iOS actually allows.
• Review activity under “Settings” → “Battery.” Then try Low Power Mode and see whether it affects refresh tasks or connection recovery.

Don’t apply Android “background locking” advice to iOS. Also, don’t repeatedly swipe the client away in the app switcher as a battery test: force-quitting the main app may affect later background tasks, while tunnel behavior depends on the client’s implementation. Use the client’s own connection toggle for a clear on/off comparison.

Use on-demand connections to reduce unnecessary uptime

If the client offers on-demand connections, trusted Wi-Fi, or network-change triggers, decide which networks need the proxy before setting them up. On-demand rules determine when the tunnel connects, not how often nodes are checked. Too many rules or conflicting conditions can trigger repeated connections during network changes. Start with one condition and test Wi-Fi-to-cellular switching before adding more.

Health check intervals: reduce batch probes and duplicate tasks

Start by checking health checks for automatic proxy groups and proxy providers. Probing 40 nodes every 60 seconds works out to about 2,400 probes per hour if every node is checked each round; at 600 seconds, that’s about 240. These are estimates of scheduled requests, not fixed counts: lazy checks, retries, and implementation details affect the actual total. They also can’t be converted directly into a specific amount of battery use.

A starting point for url-test on mobile

Here’s a mihomo proxy group snippet; time values are in seconds. Node names must match those in your existing configuration. Don’t replace your entire subscription with this snippet. Make changes through the client’s supported override or merge feature where possible, so the next subscription update doesn’t undo them.

proxy-groups:
  - name: Mobile Auto Select
    type: url-test
    proxies:
      - Daily Nodes
      - Backup Nodes
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 100
    lazy: true

• interval: 600: Set the scheduled health check interval to 10 minutes as a starting point for a battery-use comparison. This isn’t the best value for every configuration.
• tolerance: 100: Set a 100 ms switching tolerance to avoid switching over small latency changes. This is not a connection timeout.
• lazy: true: Reduce scheduled probes while the group is unused. Exact behavior depends on your mihomo version.
• url: This is the health check URL, not a subscription URL. Make sure it’s reliably reachable on your current network so a failed check target isn’t mistaken for every node being down.

If you use just one reliable node, try a manual selection group as a comparison. Don’t shorten the automatic health check interval while also enabling periodic checks for every node in the client. Also check health-check under proxy-providers: it may create a second set of probes alongside the proxy group. After removing duplicate tasks, adjust the interval to suit your recovery needs; longer intervals can mean slower detection of failures.

Subscriptions and rule sets: set update intervals based on how often they change

Subscription updates, proxy provider updates, rule set updates, and node health checks are four different tasks. A subscription may contain the entire configuration; a proxy provider mainly supplies nodes; a rule provider loads rules; and a health check tests whether nodes are reachable. Running all four every minute usually brings no matching day-to-day benefit.

These values are starting points for comparison, not universal requirements. Shorten the update interval for subscriptions whose nodes change often; rule sets that rarely change can be updated daily. For mihomo HTTP-type rule-providers, interval: 86400 means 24 hours. Automatic full-subscription updates in client apps may use minutes or hours, so check the unit shown in the interface before entering a value.

Keep only the logs you need to diagnose problems

For everyday use, log-level: warning is usually sufficient. Temporarily switch to info to investigate a disconnection, then switch back after reproducing the issue. Keeping debug enabled adds log generation and processing overhead, and leaving a live connection dashboard open can increase UI refresh activity. Save relevant error entries before reducing logging; otherwise, you won’t be able to tell whether the cause was an authentication failure, DNS timeout, or tunnel restart.

TUN, DNS, and weak signals: find out where the traffic comes from

A mobile VPN tunnel isn’t simply the same thing as a desktop system proxy toggle. Per-app bypass options and the availability of TUN settings depend on the client and platform. Some Android clients support per-app routing, letting you bypass the proxy for apps that don’t need it. Standard personal VPN setups on iOS don’t support the same app exclusion lists as Android.

First find out which app is using the most data, then check which rules match its traffic. Video autoplay, cloud sync, and system downloads can keep using the wireless network even when the client isn’t running health checks. Routing traffic through DIRECT can avoid an unnecessary remote proxy route, but it doesn’t mean the traffic bypasses the VPN tunnel entirely or stops transferring.

Don’t treat DNS mode as a standalone battery-saving switch

• Look for repeated resolution failures, DNS timeouts, and connection retries before changing DNS settings. Don’t disable a working Fake-IP mode just because the client ranks high in battery usage.
• Keep the DNS resolution path clear. If core DNS, encrypted system DNS, and other VPN tools are used together, check for unreachable DNS targets or forwarding loops.
• Occasional reconnections after a network switch are normal. Repeated retries on the same network call for a closer look at node reachability, DNS results, and log timestamps.

A weak cellular signal increases wireless communication overhead. At the same location, compare Wi-Fi with cellular and then compare two nodes, so you don’t mistake a signal problem for a proxy protocol issue. The node with the lowest latency isn’t necessarily the most power-efficient: stable transfers, fewer retries, and fewer switches are usually more meaningful than a low number from a single speed test.

Find the right balance between background reliability and battery life in three rounds

1. Round 1: Reduce background tasks. Keep the node fixed, set health checks to 600 seconds and rule set updates to once a day, turn off continuous debug logging, and leave the system battery settings unchanged.
2. Round 2: Test background restrictions. If the connection drops when the screen is locked, and only then, loosen the Android client’s battery restrictions. On iOS, check Background App Refresh for the main app separately from the tunnel connection status.
3. Round 3: Check real-world use. Resume your usual apps, note video playback, sync, and cellular data use, and see whether battery drain increases alongside that activity.

Keep only the background tasks needed for a reliable locked-screen connection, recovery after network changes, and everyday browsing. If the phone stays hot, uses a large amount of data in a short time, or restarts repeatedly every minute, pause the connection and save a redacted log before visiting Troubleshooting. Remove subscription URLs, tokens, node passwords, and identifying personal information before sharing logs.

Before switching clients, confirm compatibility with your OS and core. Don’t change the client, node, and every rule at the same time. If you need to set things up again, follow the Getting Started guide step by step, and keep a verified stable configuration for comparison.