Mobile Proxy Apps Draining Your Battery? Android Background Settings & iOS VPN Tips

First, distinguish proxy battery use from network activity and background disconnections

If a proxy app accounts for a larger share of battery use after you enable it, that doesn't necessarily mean the proxy core is working hard continuously. Android VPN services and iOS network extensions handle connections from other apps, and how the system attributes that activity varies by OS version and device. Check overall battery drain, actual data use, and heat before deciding whether the proxy is behaving abnormally; app rankings alone don't tell the whole story.

Another common mistake is treating background suspension as successful battery optimization. If messages arrive late after the screen locks and nodes reconnect when you unlock it, battery drain may appear lower simply because the network service was stopped. The goal is to reduce unnecessary wakeups and retries while keeping essential connections available.

Choose your first step based on the symptoms

• Noticeable heat continues while the screen is locked: Check for ongoing uploads or downloads, repeated node reconnects, health checks, or excessive error logging.
• High battery drain occurs only on cellular: Compare signal strength and how often the network switches. Wireless communication under a weak signal can use more power than proxy processing itself.
• The connection drops after the screen has been locked for a while: Check Android battery restrictions or iOS VPN extension disconnect logs first; don't start by changing DNS.
• The app shows high battery use, but overall standby drain is normal: Leave your settings as they are and compare the total battery used under the same conditions.

Run a 60-minute comparison instead of tuning by battery percentage

Record your phone model, OS version, client version, core version, network type, and current node. Get version numbers from the client's About page rather than noting only “latest.” Keep Wi-Fi, node, screen state, and background apps the same for each test. Pause OS updates, photo backups, and large downloads, and change only one setting per round.

1. Update your subscription and rules, then wait 5 minutes for the initial load and connection setup to finish.
2. Leave the phone idle with the screen locked for 60 minutes. Record the starting and ending battery levels, proxy data use, disconnections, and whether the phone feels warm.
3. Change one variable—for example, increase the automatic health check interval from 60 to 600 seconds—then repeat the same test.
4. Repeat at least twice. If the difference is only 1 percentage point per hour, extend the test to 3 hours to avoid misleading results from rounded battery readings.

For example, going from 80% to 77% means the phone used 3 percentage points in that hour; it does not mean the proxy used 3%. The table below is an example record, not a measured result for any particular phone.

Turning off the proxy changes which apps can connect. Some background requests may stop, while others may keep retrying, so the first test is a baseline—not a controlled measure of proxy overhead. Don't include subscription URLs, node passwords, or full browsing records in logs you share publicly.

Reduce automatic health checks and repeated rule updates

First, identify which features initiate connections

Automatic proxy group selection, node provider health checks, and latency refreshes on the home screen may each trigger probes. A single check usually transfers little data, but probing hundreds of nodes at short intervals creates many connections and can keep the cellular radio active more often. Turning off scheduled checks in the client UI does not necessarily disable health checks configured in the profile.

• Health check interval: Start with 600 seconds and observe the results; if the network is stable, try 1800 seconds. Longer intervals can delay detection of failures.
• Number of nodes: Limit automatic checks to the regions or proxy groups you actually use. There's no need to probe every node in a subscription each time.
• Manual checks: Use them when troubleshooting. Avoid repeatedly checking every node, which can make the test itself an extra source of load.

In mihomo node providers, health-check.interval is measured in seconds. health-check.lazy can avoid routine checks when provider nodes aren't in use, but it doesn't disable all probes. The url-test policy group has its own interval, so check that too. Some mobile clients don't expose these fields in their UI.

Tell subscription updates, rule downloads, and health checks apart

Subscription updates fetch node configuration; rule provider updates download routing rules; health checks test whether nodes are reachable. These are separate tasks with separate settings. Updating nodes and rules once a day (86400 seconds) is a reasonable starting point for typical use. Use a shorter interval only if your provider requires it.

Don't refresh every 60 seconds just to “keep rules up to date,” but don't disable all updates either. Check whether scheduled updates are enabled both in the app and in configuration providers. If subscriptions change frequently and each update reloads the core, check the logs for periodic reconnects. Save changes as overrides, then verify the effective configuration after the next subscription refresh.

DNS and connection retries: fix errors before tuning the cache

DNS lookups alone are rarely the only cause of sustained high battery use. Check for repeated requests after resolution failures, unreachable upstream servers, unresolved proxy server hostnames, or DNS requests incorrectly routed back through the proxy, creating a loop. These issues often show up as repeated requests for the same domain within a short time, along with timeouts, connection failures, or frequent node switching.

1. Open the logs and temporarily set the level to info. Observe them for 2–5 minutes. Stop monitoring once you identify the problem; don't leave verbose logging on indefinitely.
2. Test the same website once on Wi-Fi and once on cellular. If it fails on only one network, first check whether that network can reach the DNS upstream.
3. Check whether DNS upstream traffic goes direct or through the proxy, and verify the bootstrap resolution path for node hostnames. In mihomo, proxy-server-nameserver resolves proxy node hostnames; it is not the DNS server for all regular domains.
4. Fix loops or timeouts before comparing battery use. Don't change upstream servers, switch DNS modes, and adjust routing all at once.

DoH and DoT encrypt DNS queries, but they aren't inherently more power-efficient than every other option. Connection reuse, upstream latency, and failed retries all affect the result. More upstreams don't automatically mean greater reliability either: implementations that query multiple upstreams concurrently may increase the number of requests.

Android background operation: remove restrictions only where needed

Android proxy apps typically use VpnService to create a local VPN interface. A persistent connection usually displays a foreground service notification; that doesn't mean the app is transferring data heavily. Doze, app standby restrictions, and manufacturer-specific background controls can still affect connectivity. The details depend on the Android version, client implementation, and manufacturer policies.

Android 14 and 15 settings to check

On a near-stock Android device, go to Settings → Apps → See all apps → your proxy client → App battery usage. Check “Allow background usage” and options such as “Unrestricted,” “Optimized,” or “Restricted.” Labels and menus can vary by Android version. You can also long-press the app icon, tap App info, and search the page for “battery.”

• Connection is stable: Leave the app on “Optimized” for now; there's no need to grant every permission preemptively just to keep it running.
• You can reproduce disconnections after locking the screen: Set the proxy client to “Unrestricted” and repeat the screen-lock test to confirm that it helps.
• The app doesn't start automatically after a reboot: Check the client's auto-start setting and any manufacturer-specific permission for auto-start or background activity.
• Problems occur in Battery Saver mode: Test with Battery Saver both on and off and note the difference, rather than disabling every system power-saving feature at once.

Excluding an app from battery optimization can ease some background restrictions, but it won't reduce the processing required to handle traffic. Adding every app to the exemption list can increase background activity and overall standby drain. Locking an app in the recent apps screen is a manufacturer-specific aid, not a substitute for checking that the service is running.

What “Always-on VPN” and “Block connections without VPN” do

Some devices let you enable “Always-on VPN” under Settings → Network & internet → VPN → the VPN's settings. This is available only if the client supports it. “Block connections without VPN” is a kill switch: if the VPN service fails, the entire device may lose internet access. It's not a battery-saving option. Before enabling it, make sure you know how to restore connectivity if the VPN disconnects.

If you have debugging tools available, you can use Android platform tools to check device status. These commands only read information; they don't change battery settings:

adb shell dumpsys deviceidle
adb shell dumpsys battery

The first command checks information related to device idle state; the second returns a battery status snapshot. Neither gives the exact power consumption of a specific proxy core. Connecting a USB cable can change charging and idle conditions, so don't treat results from a wired debugging session as representative of normal standby.

iOS background behavior: check the VPN extension and on-demand rules

On iOS, the main app typically handles configuration, while a VPN extension in Network Extension handles network traffic. The VPN extension can keep running when the main app isn't in the foreground; keeping the app onscreen is not necessary to keep the VPN alive. Extension crashes, configuration reloads, and system resource limits can all interrupt service, so check the client logs to find the cause.

Start with the iOS battery report

On iOS 18, go to Settings → Battery and compare “Last 24 Hours” with “Last 10 Days.” Tap a time period that looks unusual and check screen activity alongside background activity. If the spike coincides with Personal Hotspot use, weak signal while traveling, or heavy video streaming, control those factors before changing proxy settings.

• Background App Refresh: This isn't the same as permission for a VPN extension to run. Turning on the system-wide setting doesn't guarantee the extension will never stop.
• Low Power Mode: It changes several background behaviors, but that doesn't mean it always stops the VPN. Test whether it affects the connection on your device.
• On-demand connection: Check whether the client's on-demand rules repeatedly connect and disconnect as you switch between Wi-Fi and cellular networks.
• Other VPN configurations: Check Settings → General → VPN & Device Management. On managed devices, follow your organization's policies and don't remove management profiles without authorization.

iOS doesn't have a general-purpose battery optimization exemption equivalent to Android's “Unrestricted” app setting. If a client's extension keeps restarting with a large rule set, try removing nonessential rule providers, turning off verbose logging, and updating to a maintained release, then check the restart logs. Memory usage alone doesn't prove what's draining the battery.

TUN, split routing, and final checks

A local VPN on a phone and the TUN toggle in a desktop client aren't interchangeable switches. Android and iOS clients usually already handle traffic through a virtual network interface; don't add another VPN service just to follow a desktop tutorial. On most personal devices, the OS also won't let two independent VPNs take over the same user's traffic at the same time.

Rule mode can decide which connections go direct and which use the proxy, but direct traffic may still pass through the client's VPN data path. A DIRECT rule therefore doesn't mean zero processing overhead. Some Android clients can exclude apps from the VPN; that's different from routing traffic direct in the rules. Before excluding an app, make sure it doesn't need the proxy and that bypassing it fits your network access requirements.

Use this order for your final checks

1. Restore normal traffic: First rule out syncing, downloads, weak signal, and frequent network switching.
2. Reduce scheduled tasks: Start with a 600-second health check interval, and set rule and subscription updates to match your needs—for example, once a day.
3. Fix repeated failures: Check DNS, node reachability, and error logs. Don't rely on automatic switching to hide persistent timeouts.
4. Address only background restrictions you've observed: On Android, remove battery restrictions only if needed. On iOS, check extension logs and on-demand connection conditions.
5. Test connectivity again: Leave the screen locked for at least 30 minutes and confirm that messages, web access, and switching between Wi-Fi and cellular still work. Then run a longer battery comparison.

A useful battery-saving change should meet two conditions: lower overall battery drain under the same usage conditions, and reliable access to the network services you need. If battery life improves only because the service stops or app requests fail, restore connectivity first. Keeping a record of settings before and after each change makes it easier to identify what actually matters than applying a “battery-saving profile” all at once. For rules and override fields, see the configuration reference. If you run into connection problems, follow the Troubleshooting steps one at a time.