Android Clash Essentials: VpnService Authorization and Battery Whitelist Setup

VpnService Authorization: The Foundation of Android Proxying

On Android, every Clash client (including ports built on the Clash Meta / mihomo core) relies on the system's built-in VpnService interface to take over traffic when the device isn't rooted. The mechanism works like this: the client asks the system to create a virtual network interface (a TUN device), the system shows a one-time authorization dialog, and once the user taps "OK," the client is granted permission to intercept and forward network traffic — either globally or per app. This authorization has nothing to do with actually connecting to a remote VPN server; it's simply Android's security gate for "which app is allowed to create a virtual network adapter," and any tool that needs transparent-proxy capability has to go through it, regardless of whether it's really tunneling to a remote server.

The first time you launch the client and tap "Start" or "Connect," the system shows a confirmation dialog along the lines of "Allow Clash to set up a VPN connection that monitors network traffic?" You only need to grant this once — the system remembers the authorization until you manually revoke it, clear the app's data, or switch to a different client. If this dialog never appears yet the proxy still isn't working, there are usually two possibilities: either the system silently revoked the client's authorization in the background, or another app is already occupying the VPN interface (Android only allows one active VpnService at a time), in which case you need to disable the other app first.

Troubleshooting authorization issues

• Make sure "Always-on VPN" isn't bound to another app in your settings — that would prevent the new client from taking over the interface.
• Check the system's "VPN" settings page (usually under Network & Internet) to confirm the client currently active there is the one you expect.
• Some Android skins add a separate "VPN permission" toggle on the app's info page, which is tracked independently of the first-run dialog and may need to be re-confirmed after a system update.

Per-App Proxying: Choosing Exactly Which Traffic Goes Through Nodes

On top of TUN mode, most Android clients offer an app allow-list/deny-list setting, which filters traffic by package name at the virtual-adapter level rather than modifying the networking logic inside each app. Once per-app proxying is enabled, there are typically two modes to choose from:

1. Deny-list mode: every app is routed through the proxy by default, and only the apps you check connect directly. This suits cases where you just want a few local apps left untouched — banking or government apps, for instance, often need a direct connection to pass verification.
2. Allow-list mode: every app connects directly by default, and only the apps you check are routed through a node. This suits cases where you only want specific apps proxied, uses less data and battery, and is the recommended approach for most users who proxy selectively.

Keep in mind that per-app proxying only covers user-space network requests — some system-level components (certain system DNS lookups, some OEM-bundled push services) may not respect package-name filtering. That's a difference in how each Android build implements things, not a client bug. Also, after changing the app list, it's best to manually restart the proxy service (disconnect and reconnect) rather than expect the change to hot-apply to connections already in progress.

Why OEM Battery-Saving Policies Cause Disconnects

The Clash client stays resident in memory on Android as a foreground service, continuously maintaining an active TUN virtual adapter. That pattern — long-running background resource usage — is exactly what the battery management policies in heavily customized Android skins from major Chinese phone makers (MIUI, ColorOS, EMUI/HarmonyOS, One UI, and similar) are designed to crack down on. These OEM battery policies typically intervene at three levels:

• Process freezing/killing: after the screen is off for a while, the system marks the app as an "inactive background process" and freezes or kills it outright. The TUN interface goes down with it, and all proxied traffic disconnects.
• Autostart restrictions: a killed process can't restart its own foreground service. Even if the client has reconnect logic built in, that logic can't run once the process no longer exists.
• Background network restrictions: even if the process survives, the system may separately restrict its background network access while the screen is off, so the proxy "looks connected" in the UI but traffic simply isn't flowing.

This is why the same config file and the same client build can run for hours without dropping on stock Android (a Pixel, for example) yet disconnect repeatedly on some OEM skins — the difference isn't the client itself, but how tolerant the system is of long-running background services.

Exactly How to Add the Client to the Battery Whitelist

The core fix for the disconnect issue above is telling the system "don't auto-optimize this app," which removes it from the scope of the battery policy. Every Android skin names this option differently, but the underlying logic is the same. Below are the common paths (menu wording may vary slightly by system version):

Stock Android / near-stock skins

1. Go to Settings → Apps → find the client.
2. Tap Battery, or Battery usage.
3. Change Battery optimization from "Optimized" to "Not optimized / Unrestricted."

MIUI (Xiaomi/Redmi)

1. Settings → App settings → App management → find the client.
2. Set "Battery saver" to "No restrictions."
3. Also check that "Autostart" is enabled for the app, and that "Lock background apps" (sometimes labeled "app lock" in the recent-apps view) has the app's icon locked.

ColorOS / realme UI (OPPO/OnePlus/realme)

1. Settings → Battery → App battery management → find the client.
2. Turn off "Sleep-time freeze" and set the battery policy to "Allow background activity."
3. In the recent-apps view, long-press the client's card and lock the icon so it isn't wiped by "clear all."

EMUI / HarmonyOS (Huawei/Honor)

1. Settings → Battery → App launch management → turn off automatic management for the client and manually enable "Auto-launch," "Secondary launch," and "Run in background."
2. Settings → Battery → More battery settings → confirm in the high-consumption app list that the client isn't restricted.

One UI (Samsung)

1. Settings → Apps → find the client → Battery.
2. Remove the app from the "Sleeping apps" and "Deep sleeping apps" lists.
3. Turn off "Put unused apps to sleep."

After making these changes, reconnect the proxy once and leave the screen off for 20–30 minutes to verify the background-disconnect issue is gone. On some devices, a major system update resets these toggles, so it's worth re-checking them after every OS upgrade.

Everyday Reliability Tips

Beyond the battery whitelist, a few other habits noticeably improve long-term stability on Android:

• Keep the persistent notification (foreground service notification) enabled inside the client — it measurably lowers the odds of the system aggressively killing the process, and it's the normal trade-off for staying alive in the background by design.
• Avoid third-party "one-tap cleaner" apps; they often bypass the system whitelist and force-kill the process anyway.
• If your router or system already handles DNS splitting, prefer allow-list mode for per-app proxying — it reduces the number of connections the virtual adapter has to process, which indirectly saves battery.
• Trigger subscription updates manually instead of relying on a scheduled auto-update; scheduled background tasks tend to fail silently when the system restricts them, leaving your rules out of sync with the actual node list.

Once you understand the authorization flow, configure per-app proxying to fit your needs, and set up the battery whitelist for your specific device, you'll have covered the most common cause of "it just stops working" on Android. If disconnects persist after all of that, it's worth checking whether the issue is actually with a node or subscription, rather than continuing to dig through system settings.