Keep Clash Running in the Background on Android: VpnService, Battery Optimization & Autostart

First, tell whether the service stopped or the connection failed

If Clash for Android disconnects after the screen has been off for a while, the system may not be killing the app. A stopped process, another VPN taking over, an unavailable server, or a switch from Wi-Fi to mobile data can all make websites unreachable. Check the client’s status before changing battery settings or troubleshooting your configuration.

This guide covers Android clients that use VpnService to route traffic, including the original Clash for Android and clients powered by mihomo that use Android’s VPN interface. The core determines protocol and rule support; background operation mainly depends on the client’s Android implementation and system policies. Switching cores does not automatically exempt an app from background restrictions.

Before testing, note your phone model, Android version, system version, and client version. Find the first two under Settings → About phone, and the app version on the client’s About page. The original Clash for Android is no longer maintained. If you encounter ongoing compatibility issues on a newer version of Android, use the client comparison to evaluate actively maintained options instead of repeatedly loosening every system restriction.

What the VpnService permission prompt allows

When you first start a proxy, Android usually displays a system prompt such as “Connection request” or “Set up a VPN connection.” After you approve it, the client can create a virtual network interface and pass selected traffic to its local core, which then routes it directly or through a proxy according to your rules. Here, VPN refers to Android’s traffic-routing interface; it doesn’t mean the client necessarily connects to a traditional corporate VPN server.

1. Import a valid configuration, select an available server, then tap the client’s start button.
2. Check that the app named in the system prompt matches the client you installed, then allow the connection.
3. Search for “VPN” in Settings and check which app is connected. Some devices also show a key icon.
4. Visit one site that should connect directly and another that should use the proxy, then check the client’s connection log to confirm the routing.

Why can’t two VPN apps run at once?

Usually, only one VPN service can be active for an Android user or profile at a time. Starting another proxy, a VPN-based ad blocker, or a packet capture tool may replace the current connection. Work and personal profiles have separate management boundaries, so the notification shade alone may not show the full picture. To troubleshoot, close other VPN apps in the same profile and test Clash on its own.

Desktop guides for authorizing a TUN service don’t apply directly to phones. Android commonly routes traffic through VpnService, usually without root. Whether a client offers a separate “TUN” toggle, per-app routing, or a bypass-LAN option depends on its implementation. Don’t copy desktop tun settings just to keep an app running in the background.

General settings: battery, notifications, and background activity

Start by setting battery usage to unrestricted

Long-press the client icon, then open App info → Battery or App battery usage and look for options such as “Unrestricted” or “Allow background activity.” On Pixel and other near-stock Android devices, the usual path is Settings → Apps → See all apps → your client → App battery usage. Names vary by Android version. The key is to allow background activity and avoid setting the client to “Restricted.”

Some systems still have a Special app access → Battery optimization list. Open it, change the filter from “Not optimized” to “All apps,” find the client, and select “Don’t optimize.” “Unrestricted” and “Don’t optimize” may be separate options, or may appear in different Android versions. Set the options available on your device; there’s no need to search for a setting that isn’t there.

Keep the running notification enabled to see service status

Android clients typically use a foreground service for an ongoing VPN connection and display a notification while it runs. Android 13 and later also require runtime permission for notifications. Denying that permission doesn’t necessarily prevent a foreground service from running, but it can change where and how prominently its notification appears. Allow client notifications, at least for service status, so you can tell when the service stops.

• Notification permission: Open App info → Notifications and allow the service-status notifications you need. There’s no need to enable unrelated categories.
• Background data: If Data Saver is on, check the client’s background data permission under Mobile data & Wi-Fi. Allow unrestricted data usage if needed.
• System Battery Saver: Test first in normal battery mode, then test Battery Saver separately so restrictions don’t overlap.
• Force stop: Don’t use App info → Force stop as a routine way to clear apps. It’s not the same as returning to the home screen.

Swiping an app away from Recents isn’t the same as force-stopping it. Whether the first action also ends a service depends on the manufacturer’s policy and the app’s implementation; the second explicitly stops the app. Some Android 13 and later devices also offer a “Stop” control for active apps. After you stop an app yourself, don’t expect a battery-optimization exemption to restart it immediately.

Battery exemptions and autostart settings by manufacturer

These are common menu paths, not universal labels. System updates, regional versions, and device management policies can move or rename settings. If you can’t find one, search Settings for “autostart,” “background power usage,” or “sleeping apps,” or open the client’s App info page. Adjust settings for the client only; don’t disable system-wide battery management.

Autostart and locking an app in Recents do different things

Autostart permission mainly affects whether an app can launch at startup or after certain events, and only if the client supports those actions. Check the client for options such as “Start on boot” or “Auto-connect.” System autostart permission can’t add a startup flow the app doesn’t implement. You may also need to unlock the device once after a restart.

Locking an app in Recents mainly helps prevent it from being closed by a “Clear all” action. On some devices, long-press the app card or open its menu in Recents and select “Lock”; others use a swipe-down gesture on the card. A lock icon doesn’t prevent the system from reclaiming a process, and it won’t override a manual stop, system restart, or severe memory pressure. If your device has no such option, focus on battery and background activity settings.

Choosing between Always-on VPN and blocking connections without VPN

Some clients support Android’s “Always-on VPN” setting. Search for “VPN” in Settings, tap the gear next to the client, and look for “Always-on VPN” and “Block connections without VPN.” The first tells Android to try to maintain or restore the VPN service; the second blocks traffic when the VPN is unavailable. Neither is another name for a battery-optimization exemption.

• To avoid forgetting to reconnect after a restart: First confirm the client supports it, then enable “Always-on VPN” and test with a restart.
• If you’d rather lose internet access than disconnect: Consider enabling the blocking option, but first test what happens when the server is unavailable, the client stops, or the network changes.
• If some apps need to bypass the VPN: Check whether the blocking policy prevents excluded apps from connecting. Don’t assume every bypass method will keep working.

System-level blocking and Clash’s DIRECT rules are different. Connections routed through the VPN interface and sent direct by the core take a different path from traffic belonging to apps excluded from VPN routing. If enabling blocking makes a work app, LAN device, or sign-in page unreachable, check app exclusions, routing, and system policies separately.

First verify a regular connection, then enable Always-on VPN, and test connection blocking last. Otherwise, an unavailable server can make the whole phone appear offline, which is easy to mistake for a system fault. Keep a way to return to VPN settings and turn blocking off, especially on public Wi-Fi that requires a sign-in page.

Verify the settings with a screen-off test

Don’t rely on the toggles in Settings alone. After changing them, run a repeatable test with the same configuration and server. The 5- and 30-minute intervals below are suggested observation windows, not universal test results. Change one setting per round so you can identify which restriction made a difference.

1. Screen-on baseline: Start the client, confirm the system shows the VPN as connected, visit both a direct and a proxy-routed site, and note the time.
2. Screen off for 5 minutes: Don’t play music or download files. After unlocking, check the system VPN status and client status before revisiting the sites.
3. Screen off for 30 minutes: Leave the phone idle, then check it. If only the first request after waking is slow, distinguish network recovery from the service actually stopping.
4. Switch networks: Switch from Wi-Fi to mobile data and back, then check whether new connections work. An interrupted download or session doesn’t mean the background process has stopped.
5. Restart test: Unlock the phone after restarting and check whether it connects as expected. Don’t count “autostart allowed” alone as proof that it worked.

Just record five things: time, network type, whether the VPN is connected, whether the client is running, and whether the server is reachable. If possible, also run a longer idle test. Android idle restrictions and manufacturer cleanup may not kick in during the first 30 minutes, so passing a short test doesn’t guarantee the connection will last all night.

If the service is still running, check the configuration and network

If the VPN stays connected, look in the logs for DNS failures, connection timeouts, and authentication errors. After updating a subscription, confirm that it actually contains usable servers; a successful update only means the configuration was fetched, not that every server works. In rule mode, also check whether the target matched a proxy group or a direct rule. If needed, follow the Getting Started guide to verify each step.

When you hit a timeout, don’t change DNS, enable every sniffing option, and alter traffic routing all at once. First switch to a known working server, then try another network, and finally adjust the configuration based on the logs. This keeps the test comparable and helps separate carrier network changes from local configuration issues.

Maintenance checklist

• After a system update: Check that battery, autostart, and notification settings are still in place, then run a short screen-off test.
• After switching clients: Authorize the new app to use VPN and set up its battery exemption again. Permissions don’t transfer from the old app.
• If battery life drops noticeably: Check system battery stats and client connection logs for frequent reconnects or sustained traffic instead of blaming background operation alone.
• When reporting an issue: Include system and client versions, when it happened, and steps to reproduce it. Before sharing logs, redact subscription URLs, access tokens, and personal browsing history.

A sensible order is to grant VpnService permission, relax the client’s background battery restrictions, enable autostart and lock it in Recents if your device supports them, then consider Always-on VPN and connection blocking. Verify the connection after each step. This can reduce system-initiated disconnects and make it easier to tell whether a future problem lies with Android’s background management, the client service, or the subscription or network.