The Clash Android client typically uses Android’s VpnService to handle device traffic. When the first launch shows a “Connection request” prompt and a VPN key icon appears, Android is routing the app’s traffic through a local virtual network interface. This does not mean the phone has connected directly to a traditional remote VPN server. The Clash core reads that traffic and uses the configured rules, proxy groups, and node selection to decide whether each connection should use a proxy, connect directly, or be rejected.
This setup covers most apps that do not actively use the system proxy, but it is also more susceptible to Android’s background restrictions. Disconnects after the screen locks, failures to recover after switching Wi-Fi, and services that disappear when notifications are disabled are often caused not by the subscription itself, but by the combined effects of VpnService, foreground services, battery policies, and network changes. The right order is to verify the configuration first, handle system permissions second, and then test standby and network switching.
How VpnService Handles Android Traffic
After receiving system authorization, the client creates a virtual TUN network interface. Android sends IP packets from selected apps to that interface, and the Clash or mihomo core handles DNS, matches rules, and forwards connections through the proxy. In rule mode, traffic is generally matched against the configuration from top to bottom. Once a domain, IP address, process, or rule set matches, the connection enters the corresponding proxy group. Unmatched connections are usually handled by the final fallback rule.
Here, “VPN” primarily refers to the traffic entry point provided by Android. Proxy nodes are still defined by the Clash configuration; VpnService does not provide nodes and cannot replace a subscription. After importing a subscription, you still need to update the configuration, choose a proxy group, and confirm that the selected node works. If a subscription contains only rules and proxy groups but no valid proxy, the VPN icon may still appear while external connections that require a proxy fail.
| Component | Primary role | Common sign |
|---|---|---|
| Android VpnService | Creates a virtual interface and sends app traffic to the client | A VPN indicator appears in the status bar |
| Clash or mihomo core | Parses the configuration, handles DNS, matches rules, and forwards connections | Logs show matched rules and proxy-group results |
| Subscription configuration | Provides nodes, proxy groups, rules, and related parameters | Nodes and proxy selections may change after an update |
| Foreground service notification | Tells Android that the proxy service is still running | The notification shade keeps an entry showing the running status |
Android normally allows only one enabled VPN service per user space. Other VPN clients, work-profile VPNs, ad blockers, and some firewall apps may also use VpnService. Starting a new service can stop the existing one immediately. When troubleshooting why Clash Android will not start, first check whether another connection is already active in the system VPN settings instead of repeatedly tapping the start button.
Setup Order for First Launch and Subscription Import
For the first setup, follow a consistent order so node failures, rule issues, and system-permission problems do not get mixed together. Import the configuration and finish the update first, then open the proxy or strategy page and choose a specific node. If the proxy group is set to automatic selection, you can run a latency test first, but the result only describes the response from the test endpoint—it does not guarantee that every website will work.
- Import the subscription: Make sure the subscription URL works and that the configuration update completes without parsing errors. Incorrect YAML indentation, failed downloads of referenced rule sets, or an expired subscription can all prevent the configuration from loading.
- Choose a proxy: Open the main proxy group and select a currently reachable node. A configuration update may reset the contents of a proxy group, so check the selection again afterward.
- Start the service: Turn on VPN or TUN mode, read Android’s connection request, and allow the client to establish a VPN.
- Keep the running notification: Confirm that the client’s foreground-service status appears in the notification shade. If notifications are restricted, open the app’s notification settings and check the relevant category.
- Verify the connection: Open one site expected to connect directly and another expected to use the proxy, then check the client logs for the matched rules.
If the app supports per-app proxying, choose “Proxy only selected apps” or “Bypass selected apps.” The first option suits users who want only a small number of apps to go through Clash; the second is useful for excluding banking apps, LAN management tools, or apps with compatibility issues. After changing the per-app list, fully close and reopen the target apps, because existing connections may not move to the new network path immediately.
DNS settings can also affect the first connection. The mihomo core commonly uses enhanced modes such as fake-ip or redir-host to handle domains. If the configuration already defines DNS servers, fallback rules, and domain policies, avoid overriding them arbitrarily in multiple places. Android’s “Private DNS” uses encrypted DNS, which can behave differently from the client’s DNS interception on some networks or configurations. If domains fail to open while IP addresses work, temporarily set Private DNS back to Automatic for comparison instead of reinstalling the client right away.
mode: rule
dns:
enable: true
enhanced-mode: fake-ip
nameserver:
- 1.1.1.1
- 8.8.8.8
The snippets above only illustrate how common fields relate to one another; an actual subscription may already include a complete DNS configuration. Back up the original configuration before editing it, and remember that a later remote subscription update may overwrite local changes. The VPN switch in an Android client usually creates the system virtual interface and should not be treated as equivalent to every tun field in the configuration file.
Background Operation, Battery Optimization, and Notification Permissions
Android restricts background processes based on battery level, usage patterns, and manufacturer policies. Although Clash normally starts a foreground service while running, it can still be restricted during long periods with the screen locked, in low-power mode, or under memory pressure. Typical signs include a connection that works with the screen on but times out after several minutes of lock screen time, a connection that returns after reopening the client, or a VPN icon that disappears when the system clears recent apps.
Set battery usage to Unrestricted
Open a page such as “Settings → Apps → Clash client → Battery” and set background battery usage to “Unrestricted,” “Allow background activity,” or the equivalent option on your device. Names vary across Android versions; some phones place the setting under “App battery management,” “Battery optimization,” or “Special app access.” After changing it, lock the screen and wait for a while before testing. Do not judge the result based only on a few minutes of foreground browsing.
A battery optimization exemption essentially tells the system to reduce standby restrictions for the app. It will not fix a dead node or increase node bandwidth. If the connection already fails in the foreground, check the configuration, node, and DNS first. Battery policy should be the focus only when the foreground works but the background does not.
Allow auto-start and background activity
Some devices offer switches such as “Auto-start,” “Associated launch,” “Display over other apps in the background,” or “Background operation.” If you need the proxy to resume after boot, allow the client to auto-start. If you enable the proxy only manually, there is no need to grant every startup permission. The client must also support boot recovery or Always-on VPN; granting auto-start alone does not guarantee that the service will start.
Some systems terminate background services when clearing recent apps. If your device offers a recent-app lock, keep the client locked in the task list. This is only an additional manufacturer feature and cannot replace VpnService authorization, the foreground-service notification, or battery optimization settings.
Check notifications and foreground-service status
Android 13 and later versions ask for notification permission separately. The persistent notification shown while the client runs displays the service status, traffic information, or a stop control. If notification permission is denied, Android may present the foreground service differently, making it difficult to tell whether the service is still running. In the app’s notification settings, allow the category related to running status and avoid setting it to a highly intrusive level that rings frequently.
Also check Data Saver. When Data Saver is enabled, allow the client to use mobile data in the background; otherwise, after switching from Wi-Fi to cellular data, the foreground service may remain present while new proxy connections fail to establish. On dual-SIM devices, confirm that the selected data SIM is connected. After switching SIMs, wait for the system’s default network to stabilize before checking whether Clash reconnects.
Always-on VPN and “Block connections without VPN”
Android’s VPN settings usually include “Always-on VPN.” After selecting the Clash client, Android will try to keep its VpnService enabled and may request that it resume after the device boots. This is suitable for users who want everyday traffic to remain under the rule system, provided the client, configuration, and node can all load correctly during startup.
“Block connections without VPN” is a stricter system option. When enabled, device traffic may be blocked whenever VpnService has not been established. A crashed client, failed configuration load, unfinished rule-set download, or the period immediately after boot can all temporarily leave the device offline. Before enabling it, make sure you know how to return to the system VPN page and disable the option, and first verify stable operation on Wi-Fi, mobile data, and after recovering from the lock screen.
Strict blocking can also affect per-app bypass rules, LAN access, and apps that need to discover devices directly. For printers, casting devices, and router admin pages that depend on the local network, confirm that LAN access is allowed and check whether the traffic matches DIRECT. Even with a direct rule, traffic may first enter VpnService and then be sent through the local route by the core, so incorrect routing, DNS, or strict restrictions can still affect the result.
Traffic shared through an Android hotspot usually does not automatically pass through Clash just because VpnService is running on the phone. Hotspot forwarding depends on the client implementation, Android version, and device permissions, so the phone’s own browsing results cannot prove that tethered devices are using the proxy. If sharing is required, check whether the client offers dedicated hotspot, LAN listening, or forwarding settings, and pay attention to which local ports are exposed.
Recovery Order After a Network Switch
When switching from home Wi-Fi to mobile data, joining a public Wi-Fi network that requires a web login, or returning from an area without signal, Android’s default network changes. Existing TCP or UDP connections usually cannot be reused as-is, so Clash must reconnect to the node over the new network. A brief interruption is normal. If service does not return after waiting, check the layers from the outside in.
- Check the basic network first: Temporarily stop Clash and verify that the current Wi-Fi or mobile data connection can access the internet on its own. On public Wi-Fi, complete the captive-portal login first.
- Restart VpnService: Turn off the client’s running switch, wait until the VPN icon disappears, and turn it on again. Avoid rapid repeated taps that can leave the state out of sync.
- Change the node: Select another known-working node and test again. An unreachable node does not necessarily mean that Android’s background settings are wrong.
- Update the subscription: Confirm that the subscription has not expired and check whether the update reports network, certificate, or configuration-parsing errors.
- Check the system clock: Incorrect automatic date, time, or time zone settings can cause TLS failures, often appearing in logs as handshake errors or certificate time problems.
- Compare DNS behavior: If only domain names fail, check Private DNS, the DNS configured in the profile, and possible interference from the current network. If both IP addresses and domains fail, continue checking the node and routing.
- Check other VPNs: Disable firewalls, filters, or work VPNs that also use VpnService, then authorize Clash again.
Logs are the main way to identify the failure layer. Repeated connection timeouts usually call for checking the node address, port, network reachability, and firewall. Domain-resolution failures point to DNS or network authentication. Configuration-parsing errors mean you should return to the subscription and YAML content. If the service disappears without new network errors in the log, background process restrictions or system termination are more likely.
| Symptom | Check first | Recommended action |
|---|---|---|
| VPN icon disappears after locking the screen | Battery optimization, background activity, and foreground service | Set battery usage to Unrestricted and keep the running notification enabled |
| Persistent timeouts after switching to mobile data | Background data, node reachability, and stale connections | Restart the service and test with another node |
| Only domain names fail to open | Configured DNS, Private DNS, and public-network authentication | Compare with Private DNS set to Automatic and inspect DNS logs |
| Another service immediately replaces Clash at startup | Other VPNs, filters, or work profiles | Keep one VpnService active and authorize Clash again |
| No automatic connection after rebooting the phone | Always-on VPN, auto-start, and the client’s recovery options | Enable each option separately and verify after one reboot |
Daily Checklist for Stable Operation
For long-term use, there is no need to repeatedly clear the app’s data or reinstall it. Clearing data removes granted permissions, imported configurations, and local selections, adding more steps to the troubleshooting process. A better approach is to keep a simple checklist and review it after system updates, client upgrades, or subscription updates.
- The configuration loads normally, and the main proxy group contains selectable nodes.
- Android VPN authorization is still valid, and the status bar shows the corresponding running status.
- Battery usage matches your needs; set it to Unrestricted for long-term operation.
- The running notification is visible, and the system has not completely disabled its notification category.
- Data Saver allows the client to use background mobile data when needed.
- No other app is using Android VpnService at the same time.
- After switching between Wi-Fi and mobile data, the service recovers within a reasonable time.
- Enable Always-on VPN and strict blocking only after stable operation has been verified.
Clash Android stability depends on three layers: a working network and node underneath, a correct Clash or mihomo configuration in the middle, and Android’s management of VpnService and background processes on top. Troubleshooting in this order prevents battery restrictions from being mistaken for subscription failures and avoids repeatedly changing system permissions when the node itself is down. After completing an ordered setup and standby test, ongoing maintenance usually comes down to subscription updates, proxy-group selection, and permission changes introduced by system updates.