Android Clash Stability Guide: VpnService Permissions & Battery Whitelist Setup

Why Android Clients Depend on VpnService

On desktop systems, the Clash core can spin up a virtual network adapter through TUN mode, then route all traffic into the proxy process via the system routing table. Android's sandbox model blocks ordinary apps from touching the routing table or creating a raw TUN device directly — the only sanctioned entry point is the system's VpnService API. The client requests a "virtual VPN connection" from the system, which triggers a one-time authorization dialog. Once you approve it, the app receives a file descriptor it can read from and write to, effectively simulating a network adapter at the software level.

This is why Android Clash clients (such as Clash Meta for Android, FlClash, etc.) usually label the control simply "Start VPN" rather than "Start TUN" — the underlying mechanism is the same either way: traffic matching global or per-app rules gets intercepted and handed to the mihomo core, which routes it to the appropriate node based on your rule set. Understanding this layer matters later on, since it tells you whether a "tap start and nothing happens" or "icon flashes then disconnects" issue points to a permissions problem or a battery-policy problem.

Keep in mind that Android only allows one active VpnService per device. If your phone has another VPN app installed, or a browser with a built-in "secure browsing" feature, make sure it's fully closed before launching Clash — otherwise the two apps will fight over the virtual adapter, triggering repeated authorization prompts while the connection never actually goes through.

First-Launch Permissions and Network Setup

After a fresh install, work through the following steps in order to avoid gaps that cause headaches during later troubleshooting:

1. Open the client, import your subscription link, and confirm the node list loads correctly. Run a latency test inside the app first to rule out subscription-side issues.
2. Tap the start button — the system will show a dialog asking whether to allow the app to create a VPN connection. Tap "OK" or "Allow." This prompt only appears on first launch or after the system resets permissions; once granted, a persistent key or gear icon appears in the status bar, confirming the VPN tunnel is up.
3. Go to the client's "Notification permission" setting (Android 13 and above require this to be granted separately) and make sure the persistent notification is allowed to display — this is one of the key safeguards against the system killing the background process by mistake.
4. If the client offers a shortcut for "Ignore battery optimization" or "Autostart management," use it directly from within the app rather than hunting through nested system settings menus, where it's easy to miss a step.

Battery Optimization and Whitelisting: Settings Paths by Manufacturer

Android's default battery management restricts network access and CPU wake-ups for apps that have been backgrounded for a while, and VPN apps are especially prone to being flagged as "abnormal background drain." To keep Clash running reliably in the background, you need to remove it from the system's battery optimization list and, on most custom skins, add it to an additional power-saving whitelist. The paths below reflect common system versions — exact menu names may shift slightly with system updates:

• Stock Android / some brands: Settings → Apps → find the client app → Battery → choose "Unrestricted" instead of the default "Optimized."
• Some manufacturer skins: Settings → Battery → App launch management / Smart battery saver — manually enable all three toggles (autostart, secondary launch, background activity) for the client app instead of leaving them on automatic management.
• Another manufacturer skin: Settings → Battery & performance → More battery settings → App smart control — find the client and turn off smart control for it specifically.
• Yet another manufacturer skin: Settings → App management → client app → Permission management — enable "Display pop-up windows in background," "Autostart," and "Secondary launch" permissions together, then add the app to the "Unrestricted" group in battery settings.

After whitelisting the app, lock the screen and leave it idle for ten to fifteen minutes before checking the connection, rather than judging it "fixed" right after saving the settings. The system's background-reclaim policy is usually delayed, so a quick test can easily give a false positive.

Troubleshooting Checklist: Background Disconnects and Missing Notifications

If disconnects still happen after completing the steps above, work through this checklist in order:

1. Check whether the persistent notification representing the VPN connection is still showing. If the notification is gone but the key icon is still in the status bar, the notification permission was likely revoked separately by the system — just re-enable it in notification settings, no need to restart the app.
2. Check whether the system's "Recent apps" list has a per-app lock option (some systems show a lock icon on the recent-apps card). Locking the app prevents the system from sweeping it away along with everything else during a background cleanup.
3. Check whether a system-level "deep sleep" or "ultra power saving" mode is enabled. These modes can pause network access for all non-whitelisted apps under certain conditions (screen off for a set duration, battery below a threshold), overriding your battery whitelist entry — you'll need to add the client to that mode's exception list separately.
4. If you're using the system's built-in memory cleaner or a third-party security app, check whether it has its own "process protection" list. These tools' cleanup logic usually runs independently of the system's battery settings, and it's a common hidden cause of disconnects even after the official whitelist is set up correctly.
5. Double-check your routing mode. If you're toggling between "Global" and "Rule-based" proxy modes to test, fully quit and relaunch the app after switching instead of relying on a hot switch — on some versions, the virtual adapter isn't rebuilt after a mode change, leaving some app traffic with no route at all.

Differences from Desktop: Why Synced Rules Can Behave Differently

Many users import a configuration file that works flawlessly on desktop straight into the Android client, then notice rule matching doesn't behave quite the same way. This usually isn't a configuration mistake — mobile networking is inherently more complex. The system automatically switches between Wi-Fi and mobile data, and each switch requires the virtual adapter's routing state to be rebuilt, during which a handful of requests may briefly bypass the proxy and connect directly. On top of that, some manufacturers' "multi-network optimization" features actively probe for the faster link, which can briefly conflict with VpnService's traffic interception. If things stop working right after a network switch, it usually resolves itself within a few seconds once routing is rebuilt — no need to re-import your configuration.