Check whether the battery drain is real or a reporting artifact
First measure battery loss with the screen off, then adjust keep-alive settings. Seeing Clash near the top of your battery list doesn't necessarily mean the proxy core is at fault. When downloads, video playback, or background sync run through a VPN tunnel, the system may attribute some network processing to the VPN app. Check overall battery loss, background activity time, data usage, and whether the phone gets warm—not just one percentage.
Android clients typically use VpnService to route traffic, while iOS clients may use the Network Extension Packet Tunnel extension. Clash and Clash Meta (mihomo) refer to related cores and ecosystem components; not every mobile client offers the same settings. On iOS in particular, identify the app and core you're using before following any advice—Android battery optimization guides don't apply as-is.
Keep a troubleshooting log
- Note your phone model, OS version, client version, and core version. The app version is usually under Settings → About; you may need to check the startup logs for the core version.
- Record the starting and ending battery levels, test duration, Wi-Fi or mobile data, signal strength, and whether the screen stayed off.
- Note the proxy mode, selected proxy group, number of subscription nodes, and whether automatic latency tests, verbose logging, or auto-reconnect are enabled.
- Save your current configuration. Make changes to subscription overrides in the client's supported override or merge configuration so the next subscription update won't overwrite them.
Narrow down the cause with two screen-off tests
Choose a location with a stable signal and observe each test for 60 minutes. Keep the network and starting battery level as similar as possible, and pause large downloads, system updates, and photo backups. If you just charged the phone, updated the OS, or notice it getting warm, wait for things to settle before testing. The 60-minute window below is for troubleshooting, not a battery-life guarantee.
- Test 1: Set a baseline. Temporarily stop the proxy service, confirm the system VPN is disconnected, and leave the screen off for 60 minutes. Record total battery loss and background data usage. If an app needs a constant connection, run this test during a quiet period.
- Test 2: Keep your usual settings. Start the proxy and use your regular rule mode and node. Keep the conditions the same and observe for another 60 minutes. Note any disconnects, reconnects, or persistent warmth.
- Change one variable at a time. If Test 2 uses noticeably more battery, run another test with only periodic speed tests disabled or only one stable node selected. Don't change DNS, routing, battery exemptions, and keep-alive settings all at once—you won't know what made the difference.
- Repeat before drawing conclusions. Battery indicators update in whole-number increments, so short tests can be misleading. If the difference is small, extend the test to 2–3 hours and repeat it on another day.
If the battery still drains quickly with the proxy stopped, first check for a weak signal, other apps running in the background, or system sync. If the problem only occurs with the proxy on, investigate tunnel traffic, probe tasks, and reconnects. Apps that need the proxy may keep retrying during Test 1, skewing the baseline; if so, disable their background tasks for both tests.
Android battery optimization: exempt only clients that need to stay connected
A battery optimization exemption reduces the chance that the system will restrict background tasks; it doesn't reduce the core's own processing load. A common sign of background restrictions is that the connection works at first, drops after the screen has been off for a while, and comes back when you wake the phone. Check background limits first in that case. If the phone stays warm or data usage keeps climbing, setting the app to “Unrestricted” may simply let a problem task run longer.
Check background permissions by system
- Near-stock Android 14: Go to Settings → Apps → See all apps → your client → App battery usage to check background usage permissions. Manufacturer-customized interfaces may call this “Battery” or “Battery usage,” with options such as “Unrestricted,” “Optimized,” and “Restricted.”
- Manufacturer-customized Android: Also check the app details for “Auto-start,” “Background activity,” or “Battery policy.” Even if auto-start is allowed, check for separate restrictions on background data.
- Locking the app in Recents: Some systems let you lock an app in the recent-apps screen. This usually only affects cleanup behavior and doesn't replace battery or background permission settings.
Start with the system's default optimization settings. Exempt only the proxy client, and only after confirming it's being restricted with the screen off. There's no need to exempt every app that uses the internet. After changing the setting, leave the screen off for 30–60 minutes and test whether the connection recovers when switching from Wi-Fi to mobile data. Being able to connect once after waking the phone doesn't prove the background connection stayed healthy the whole time.
Persistent notifications and Always-on VPN are separate settings
Android foreground services typically require a persistent notification. It lets both the system and the user know the service is running, and usually isn't a major source of battery drain. Hiding the notification doesn't stop the proxy; seeing one doesn't guarantee the node is connected either.
On Android 13 and later, notification permissions and foreground service requirements are separate. Denying notification permission doesn't exempt a foreground service from system management. Keep the service notification visible while troubleshooting and check its connection status directly; that's more useful than hiding it in the hope of saving battery.
Under Settings → Network & internet → VPN, some devices offer “Always-on VPN” and “Block connections without VPN.” The first keeps the selected VPN active; the second blocks other network access when the tunnel is unavailable. The latter can leave every app offline if the connection drops, so don't use it as a battery-saving setting. Menu names and availability depend on the OS and client.
Health checks and automatic speed tests: reduce frequency, then narrow the scope
Node health checks send requests proactively. Each request may use little data, but frequent network wake-ups, connection timeouts, and encrypted handshakes add background overhead. On mobile networks, battery use also isn't directly proportional to bytes transferred. With large subscriptions, check health checks for proxy providers, probes from proxy groups, and the client's own scheduled speed tests separately.
| Setting | What it means | What to try |
|---|---|---|
health-check.interval |
Health-check interval for proxy providers that support it, in seconds | If it's set to 300, try 900 and see whether node switching is still fast enough |
Proxy group interval |
Interval for periodic probes in groups such as url-test and fallback |
Check this separately from provider health checks to avoid setting both to 60 seconds |
lazy |
For supported health checks or proxy groups, controls whether probes can be deferred while unused | Check the core documentation for support before trying true |
| Client automatic speed tests | Additional latency or download tests started by the app interface | Disable scheduled tests first; keep manual tests for when you need them |
| Subscription update interval | Fetches nodes and configuration again; it doesn't test node speed | If you don't need frequent updates, try an interval of 12 or 24 hours |
For example, with 80 nodes and one probe every 60 seconds, probing every node each round would mean about 4,800 node probes per hour. At one round every 900 seconds, that drops to about 320. These figures illustrate scheduling volume; they aren't measured battery results and don't account for retries, lazy checks, or other proxy group tasks. The point is to check frequency and scope first, rather than focusing on a few kilobytes used by one speed test.
Manually selecting a single node can provide a useful comparison, but it doesn't guarantee that provider-level background health checks will stop. If the interface is set to manual selection but the logs still show batches of periodic probes, check scheduled tasks at both the provider and client levels.
Reconnects, DNS, and TUN: look for loops instead of disabling features blindly
On phones, the interface may not call VPN-based traffic routing “TUN mode,” or expose the same switches as the desktop version. Look for abnormal activity loops: repeated reconnects after a network change, ongoing DNS timeouts, or a background app repeatedly failing to connect. Normal traffic routing and rule matching do use resources, but TUN being enabled alone doesn't mean it's the cause.
- Rule out node issues first: Stick to one known-good node and observe for 30 minutes. If reconnects drop noticeably, check the original node's stability and automatic switching conditions.
- Then check for DNS timeouts: Temporarily inspect the logs for repeated resolution timeouts, connection failures, or retries to the same domain. A DNS timeout can make the app keep retrying, using network and processing resources.
- Review network settings: If you've manually configured Android Private DNS or another DNS tool, note the current settings first, then check the client documentation for potential conflicts. Don't change multiple DNS settings at random.
- Find the source of background traffic: Check the client's connection panel for high data use or connection counts. Look for tasks such as cloud uploads, photo backups, and video preloading. The proxy is only the route; another app may be generating the sustained traffic.
Rule mode is useful for everyday split tunneling, but “Direct” doesn't necessarily mean traffic completely bypasses VPN processing on the device: if traffic has already been routed through the tunnel, the core may still inspect and forward it. Global mode won't automatically reduce all background processing either. Don't switch modes back and forth as a battery-saving tactic; check actual connections and rule matches instead.
Collect logs only briefly. Temporarily set the log level to debug, reproduce the issue for 2–5 minutes, then switch back to info or the client's default. Keeping verbose logs on, leaving the live connections panel open, or refreshing it frequently adds extra work. Before sharing logs, remove subscription URLs, tokens, node credentials, and other sensitive information.
iOS background keep-alive: distinguish the app interface from the tunnel extension
iOS doesn't have a general battery exemption that directly corresponds to Android's “Unrestricted” setting. In clients that support Packet Tunnel, the extension typically handles the tunnel, so sending the app interface to the background doesn't necessarily stop it. Enabling Background App Refresh doesn't give a VPN extension unlimited background time either. Check the system VPN status and the client's connection history to confirm whether it stays connected.
Check these three places
- Battery usage: On iOS 18, go to Settings → Battery, select “Last 24 Hours” or “Last 10 Days,” and check activity for the relevant period. Other iOS versions may have different reporting periods and menus.
- VPN configuration: Go to Settings → General → VPN & Device Management → VPN and confirm which configuration is active. This helps avoid attributing another app's connection to the client you're troubleshooting.
- Connect On Demand: If the client offers “Connect On Demand” or automatic connection rules, check whether they repeatedly trigger when switching between Wi-Fi and mobile data. Temporarily turn them off for a comparison test, then decide whether to restore them.
Low Power Mode changes some background behavior, but that doesn't prove the VPN will disconnect or use less battery. If you need a persistent connection, test with the screen off and while switching networks with Low Power Mode enabled. Force-quitting the app repeatedly isn't a reliable way to keep a connection alive; the effect depends on the client and OS implementation.
If the app doesn't offer probe intervals, log levels, or per-app settings, don't apply YAML from another platform. Check which settings the client actually supports, then compare results using the options available: a fixed node, fewer scheduled speed tests, and Connect On Demand settings.
Choose keep-alive settings for your use case
| Use case | Suggested starting point | Trade-off to consider |
|---|---|---|
| Occasional web browsing | Connect as needed and keep the system's default battery optimization to start | You may need to connect manually before use |
| All-day messaging and sync | Exempt the Android client from background limits as needed, and keep health checks moderate | A persistent connection has baseline overhead; check that it stays stable with the screen off |
| Frequent network changes while commuting | Choose a stable node and check auto-reconnect and on-demand rules | Retries and network switches on a weak signal can increase battery use |
| Use only on specific networks | Use network-condition rules supported by the client | A change in network conditions may re-establish the tunnel |
Keep just three results: battery loss with the screen off under the same conditions, whether the connection drops while the screen is off, and whether it recovers after a network switch. Reduce repeated probes and failed reconnects first, then grant more background permissions if needed. If the connection is already stable, there's no need to keep changing DNS or rewriting rules just to improve its battery-list ranking.
If you still can't identify the cause, provide your phone model, OS and client versions, core version, test period, network type, and a short, redacted log. “The connection stops after 40 minutes with the screen off and immediately recovers when I wake the phone” is more useful than “it uses a lot of battery” for distinguishing background restrictions, node failures, and tunnel issues.