Clash Android Client Guide: VpnService Authorization & Battery Whitelisting
On Android, proxy clients rely on the system VpnService interface, and authorization, background persistence, and battery-saving policies all interact — miss any one of them and the proxy will "disconnect for no reason" after a while. This article walks through each step in the order you'd actually troubleshoot them.
VpnService Authorization and the Key Icon
Android doesn't let apps take over global network traffic directly. Every TUN-based proxy client (including Clash for Android, ClashMeta for Android, etc.) must request authorization through the system's VpnService interface. The first time you enable the proxy, the system shows a standard dialog saying "This app wants to set up a VPN connection" — this is the same system component used when authorizing any third-party VPN app, not something drawn by the client itself. Once you tap Allow, the system creates a virtual network interface for the app, and only then can traffic be intercepted and routed according to rules.
After authorization, a key-shaped icon appears in the status bar (some customized systems show a lock icon or a "VPN" text bubble instead). This is a mandatory Android system notice telling the user "an app is currently handling your network traffic." Any VpnService app triggers this icon, and it has nothing to do with the client's own security. Battery drain increases slightly while the icon is present — that's just the normal cost of the virtual interface continuously forwarding packets, not an abnormal state.
Authorization only needs to be granted once, at first launch or after a system update. If the authorization dialog pops up every single time you enable the proxy, the system has likely marked the client as "untrusted" in the app list, and you'll need to manually trust it in the app details page in system settings.
Some heavily customized ROMs add an extra "Always-on VPN" option on top of standard VpnService authorization. Enabling it gives the app's virtual interface higher priority, making it less likely to be interrupted by other background cleanup mechanisms — it's worth turning on alongside the base authorization.
Why the System Kills the Background Service
To control overall power usage, Android applies multiple layers of restriction to background processes, and the newer the system version, the stricter these get. This is the root cause behind the common complaint that "the proxy stops working a while after the screen locks." Three mechanisms are typically at play:
- Doze mode: after the device sits idle and unplugged for a while, the system enters a low-power state, sharply restricting network access and background task scheduling — only high-priority foreground services stay active.
- App Standby buckets: the system groups apps into Active, Working Set, Frequent, and Rare buckets based on usage frequency. The further down the bucket, the smaller the background execution quota.
- Manufacturer-specific battery management: beyond native Android mechanisms, most customized OEM systems layer on their own background cleanup policies, which are often more aggressive than stock Android and are the main source of "random" proxy disconnects.
A properly implemented proxy client registers its core forwarding process as a foreground service with a persistent notification. Foreground services carry higher survival priority in the system's ranking and, in theory, shouldn't be killed directly by Doze or App Standby. But OEM battery-saving policies frequently ignore the foreground service flag and force-freeze or outright kill the process — which is exactly why manual whitelisting is necessary.
Battery Whitelist and Autostart Allowlist Setup
Keeping the Clash client stable in the background requires two types of authorization in system settings — both are required:
| Setting | Purpose | Typical location |
|---|---|---|
| Battery optimization whitelist | Stops the system from throttling the app's CPU and network scheduling in the background | Settings → Battery → Battery optimization → find client → set to "Don't optimize" |
| Autostart management | Allows the app to relaunch its service on boot or after being cleaned up | Settings → App management → Autostart / Permission manager |
| Background activity permission | Some systems control "allow background activity" separately from battery optimization — these are two independent toggles | Settings → App details → Battery / Permissions |
| Lock in recent-tasks list | Long-press the client card in the multitasking list and choose lock/pin, so one-tap memory cleaning won't reclaim it | Recent apps list |
Menu naming varies between manufacturers, but the logic is consistent: any option labeled "Smart management," "Battery saver," or "Auto management" restricts background activity by default, and needs to be manually switched to "Allow" or "Unrestricted." Check things in this order:
- In battery settings, switch the client from "Smart battery saving" to unrestricted;
- Check whether autostart permission is enabled — otherwise the proxy won't automatically resume after a device reboot;
- Finally, lock the app card in the recent-tasks list to keep "one-tap clean memory" from taking out the foreground service along with it.
Even after whitelisting the client, the system may still restrict background networking under extreme low-battery conditions or after unusually long idle periods — this is a hardware/system-level fallback policy, not a missed configuration step. Simply reopening the client restores the connection.
Per-App Proxy Configuration
Android clients generally support "per-app proxy," letting only selected apps route through the virtual interface while the rest connect directly. This is common in two scenarios: routing only browsers and messaging apps through the proxy while keeping banking and payment apps on a direct connection, or excluding apps that are sensitive to a VPN environment and misbehave when one is active. The setting is usually found under "Network" or "App list" in client settings, offering two modes:
- Whitelist mode: only checked apps' traffic goes through the proxy; unchecked apps connect directly. Suited to cases where you know exactly which apps need the proxy.
- Blacklist mode: everything except the checked apps goes through the proxy, and only checked apps connect directly. Suited to "proxy everything by default, with a few exceptions."
Note that per-app proxy still relies on the system VpnService's addAllowedApplication / addDisallowedApplication interfaces, so changes usually take effect only after the VPN connection is restarted — they don't hot-reload. Also, some system components (like DNS resolution services) may not appear in the app list at all; that's system-level behavior and doesn't affect rule-based routing decisions for regular apps.
FAQ
Can the key icon be turned off?
No. This is a mandatory Android system notice for all VpnService apps, meant as a security disclosure. No client can hide it at the system level — this is normal behavior.
The client is already whitelisted — why does it still disconnect occasionally?
Extreme low battery, extended idle time triggering deep Doze, or autostart permission being reset by the system after a reboot can all temporarily suspend the background service. Reopening the client's interface restores the connection — no reconfiguration is needed.
Is per-app proxy the same thing as rule-based routing?
No. Per-app proxy is a system-level switch that decides whether a given app's traffic enters the virtual interface at all. Rule-based routing (matching by domain, GEOIP, etc.) decides which proxy node handles traffic once it's inside the interface. They operate at different stages and can be used together.
Why do some apps report a network error after enabling the proxy?
A small number of apps detect an active VPN connection and deliberately refuse to work, which is common in apps sensitive to network conditions. You can set these apps to connect directly in per-app proxy settings without affecting others still using the proxy.