Clash Android Guide: VpnService and Battery Optimization Settings

When using a Clash client on an Android phone, connection failures or shutdowns after running for a while are not always caused by the subscription. Android’s network permission model, VpnService authorization, battery optimization, manufacturer background controls, and the client’s operating mode can all affect whether the proxy keeps working. After installing the client, confirm the proxy mode and system permissions first, then adjust battery settings. This troubleshooting order is more effective than repeatedly switching nodes.

This guide focuses on Android clients that support the Clash Meta (mihomo) core. It explains how the system proxy, VpnService, and TUN mode work together, then provides a checklist covering first-time authorization through background operation. Menu names vary slightly by phone brand, but the key checks are the same: whether the client has VPN permission, whether Android allows it to run in the background, whether the target app’s traffic passes through the proxy, and whether DNS and rules resolve requests correctly.

1. What Android proxy connections depend on

Android apps typically do not connect directly to Clash’s local ports. A Clash client starts the proxy core locally, then routes app traffic through either the system proxy settings or Android’s VpnService. These methods cover different traffic paths and should not be treated as identical just because a switch is enabled. The right choice depends on the client implementation, whether an app respects the system proxy, and whether you need to handle apps that do not support HTTP proxies.

System proxy vs. VpnService

A system proxy usually exposes an HTTP or SOCKS proxy address to apps. Browsers, some network tools, and apps that honor Android’s system proxy settings send requests to Clash’s local listening port, where rules determine whether traffic is sent directly, proxied, or rejected. System proxy routing is lightweight and usually does not take over every app’s network interface. Some apps, however, ignore the system proxy or use their own network stack for specific requests.

VpnService is Android’s virtual network interface service. After the user grants permission, a client can create a local VPN interface, read traffic passing through it, and hand that traffic to the mihomo core. Here, VPN refers to Android’s local traffic interception mechanism; it does not mean the client automatically provides a remote VPN server. The actual egress is determined by the proxy nodes, policy groups, and rules in the configuration. The first time it is enabled, Android displays a VPN connection permission prompt, and the user must explicitly allow it before the client can establish the tunnel.

VpnService is usually the better choice when the phone has apps that ignore the system proxy or when more TCP and UDP traffic needs to pass through the rule engine. The trade-off is that Android displays a VPN status indicator, and this permission generally conflicts with other VPN apps. Only one app can use the system VPN interface at a time. If another VPN, firewall, or network acceleration tool is enabled, Clash may fail to start or an existing connection may be taken over by the system.

Clash Meta and the local network path

Clash Meta (mihomo) reads YAML configurations, establishes proxy connections, matches rules, and provides DNS, HTTP, SOCKS, and transparent proxy capabilities. The Android client embeds the core, requests system permissions, and provides the graphical interface. If the client is open but a particular app cannot connect, inspect these layers separately: check the core, configuration, and node status first; then check VpnService, background operation, and whether the app’s traffic is excluded.

With only the system proxy enabled, a common local listening address is 127.0.0.1 paired with an HTTP or SOCKS port. With TUN enabled, app traffic first enters the virtual network interface and is then processed by the core according to routing and rules. Do not confuse the remote subscription URL, the node server address, and the local listening port. A subscription provides configuration or node information; the local port is accessed by apps on the phone. They serve different purposes.

2. First installation and VpnService authorization

After installation, follow a consistent sequence so it is easier to identify the source of a problem when variables change. Prepare the configuration first, then start the connection; verify that one node works before testing rules and apps. After importing a subscription, avoid changing many advanced options at once. Keep a basic configuration you can restore, which makes DNS, routing, and policy-group issues easier to isolate.

Check the client source and core support. Open the client’s About or core information page and confirm that the installed version supports mihomo or the relevant Clash Meta capabilities. Also check the Android version requirements. TUN, scripting, and DNS features are not identical across clients.
Import the subscription and run one update. Confirm that the subscription URL is reachable. After the update finishes, review the proxy node list and policy groups. If the update fails, check the network, system time, and whether the subscription URL is complete before treating it as a VpnService problem.
Choose a clear proxy mode. For initial testing, use rule mode and manually select a node in the proxy policy group. Global mode is useful for confirming basic connectivity, but rule-based routing is generally better for long-term use. In direct mode, proxy nodes are not used for most requests.
Start system VPN authorization. Tap the client’s connection switch, and Android will display a VPN connection request. Confirm the app name and choose Allow. If Android reports that a VPN is already active, disconnect other VPNs, traffic firewalls, or similar network tools, then request authorization again.
Verify the local status. Check whether the client shows that it is running, whether the VPN icon appears, and whether core logs continue to update. Then test one site that should connect directly and one that should use the proxy. Do not judge the entire configuration from a single target.

Android VPN authorization is a system-level operation, and the client cannot bypass the confirmation step. Some systems offer an “Always allow” or similar option after the first authorization; they may also ask again after a reboot, user switch, or security-policy change. If the authorization prompt does not appear, stop the client, disconnect other VPNs, and remove the old connection record from Android’s VPN settings or select the app again.

When to enable TUN mode

TUN mode receives traffic through a virtual network interface. It is useful for apps that ignore the system proxy or for routing TCP and UDP requests through the mihomo rule flow. It does not make nodes faster and cannot repair an invalid subscription, incorrect DNS, or unavailable nodes. Once TUN is enabled, system routes, DNS interception, and app exclusion lists become more important; a configuration error can make every app appear offline.

Complete the basic connectivity test with the system proxy or the client’s default mode before enabling TUN. Record the current DNS, mode, and selected node first; after enabling TUN, change only that setting and test again. If the internet stops working, check TUN permission, auto-route, DNS mode, IPv6 handling, and conflicts with other VPNs before deleting the subscription.

3. How battery restrictions cause background disconnects

Android limits background processes based on app usage, screen state, charging status, and manufacturer policies. While a Clash client runs in the background, it must keep the core process, VPN service, node connection, and DNS requests alive. If Android suspends the service or reclaims the process, the symptoms may include a missing VPN icon, the client stopping before you return to it, no access after locking the screen, or a connection that still appears enabled while requests time out.

“Android battery optimization” is not a universal menu name. Common locations include Battery, App battery management, Background activity, Auto-start management, Battery optimization, Background pop-ups, and Lock-screen cleanup. Adjust the client itself, not the browser or the app being proxied. Setting the client to “Unrestricted” or allowing background activity reduces the chance that Android will suspend VpnService or reclaim the core process.

Common settings path

Open Android Settings, go to the app list, and find the Clash Android client you use.
On the Battery or battery-management page, set background usage to “Unrestricted,” “No restrictions,” or an equivalent option.
On the Mobile network and Wi-Fi page, allow background data. If the system provides a data-saver exception list, add the client to it as well.
If the system includes auto-start management, allow the client to start at boot or launch its background service. Enable this only when automatic connection after boot is actually needed.
Lock the client in the recent-apps screen. Some manufacturers’ “Clear all” actions terminate unlocked background apps even when battery restrictions have been relaxed.
Wait five to ten minutes with the screen locked, then test again. Testing only while the app is in the foreground will not reveal background restrictions.

Some manufacturers spread the same restriction across several pages. For example, the Battery page may allow background operation while Sleep standby optimization still freezes network access overnight. Or the client may be unrestricted, but its connection status cannot reappear because background pop-up permission is disabled. After changing these settings, restart the client once and observe its actual behavior. If the problem occurs only when the screen is locked, apps are switched, or the network changes, battery and network-switching policies are likely involved.

Battery optimization trade-offs

Allowing background operation gives the client a better chance of keeping its process and network connection alive, but it may increase standby battery use. For long-term troubleshooting, first choose “Unrestricted” to verify stability, then restore restrictions one at a time after confirming the cause. If the device is mainly used at home and does not need proxy access while locked, disable auto-start in the client. If you need instant messaging, synchronization, or remote access, keep background permission for the VPN service.

4. Checking subscriptions, rules, and DNS together

Even with permissions and background settings configured correctly, some apps may work while others do not. This usually requires checking the configuration layer. A subscription update only downloads configuration content to the client; it does not guarantee that every node, policy group, and rule suits the current network. First confirm when the subscription was last updated, then review the current mode, policy-group selection, and rule matches.

Narrowing the problem by symptoms

No apps can access the internet: Check whether the VPN is actually connected, whether the current node works, whether TUN has system authorization, whether another VPN is active, and whether the default policy group points to a usable node.
The browser works, but one app does not: Check whether the app is excluded by the client and whether it uses its own DNS, QUIC, or a specialized network interface. TUN mode can broaden traffic interception, but it still follows the client’s app-bypass settings.
Domains fail to open, while a direct IP sometimes works: Focus on DNS mode, upstream DNS reachability, Fake-IP settings, and how rules handle DNS requests. Do not simply switch proxy nodes.
The connection drops when the screen locks and returns in the foreground: Recheck battery optimization, auto-start, background data, and the recent-apps lock before changing rules.
Only a specific region or service has problems: Check the matched rule, selected policy, and node exit region. The policy group may have selected direct access, or a rule may be sending the destination to an unsuitable policy.

In rule mode, rules are matched from top to bottom, and the first match is passed to the corresponding policy. The final MATCH rule usually provides fallback handling. After importing subscriptions from different sources, rule-set names, policy-group names, and DNS behavior may vary. Save and reload the configuration after changing rules or policy groups, then send the request again. The client’s connection log can show the domain, matched rule, and final policy, providing a more accurate view of the path than a browser error page alone.

Fake-IP and Android app compatibility

Fake-IP mode assigns virtual addresses to domains, then restores the domain through the mapping during later connections before applying the rules. It can reduce some DNS lookup delays, but it is not suitable for every local-network discovery service, banking app, game, or program that requires a real LAN address. If only one category of app has problems, try adding the relevant domains to the Fake-IP filter or using the compatibility mode provided by the client. Follow the configuration documentation supported by the current core for the exact fields.

DNS configuration should align with the TUN and rule design. With TUN enabled, DNS requests that bypass the core can make rule decisions differ from the actual resolution path. If the upstream DNS server is unreachable on the current network, every domain may time out. During troubleshooting, temporarily use the client’s recommended basic DNS settings, confirm connectivity, and then restore a custom upstream. Change one parameter at a time and record the results before and after each change.

5. A standard troubleshooting process for dropped connections

Break troubleshooting into four layers: system, client, configuration, and target app. This prevents background process termination, node failures, and incorrect rules from being conflated. The following process works for disconnects after locking the screen, failures after switching between Wi-Fi and mobile data, and cases where Android shows the VPN as connected but apps cannot access the internet.

Check the system layer. Look for the VPN icon in the status bar and open Android’s VPN settings to confirm that the current app is still connected. Check for other VPNs, proxies, Private DNS, or traffic firewalls.
Check the client layer. Open the client and review its running status, core logs, and active connections. If the process has stopped, restart it and check battery restrictions. If it is still running, continue with the configuration checks.
Check the configuration layer. Check whether the subscription has expired, whether the node works, whether the policy group points to a usable node, whether the current mode is rule or global, and which rule matches the request.
Check DNS and routing. In TUN mode, check auto-route and DNS settings. In system proxy mode, confirm that the target app honors the system proxy. If necessary, temporarily disable IPv6 or Fake-IP options for comparison testing.
Check the target app. Clear the target app’s network state and try again. Check for its own proxy, certificate validation, regional restrictions, or login-session issues. When only one app fails, do not immediately conclude that Clash as a whole is broken.

If restarting the client restores access immediately but another screen lock causes a disconnect, focus on background policies. If access fails after switching Wi-Fi networks, check whether the VPN was re-established and whether the new network blocks the subscription or node port. If the VPN icon remains visible but every domain fails to resolve, focus on DNS. If domains resolve but connections time out, inspect the node, rule policy, and transport protocol. Identifying the affected layer by symptoms reduces unnecessary subscription reimports.

Troubleshooting order:
1. VPN authorization and conflicts with other VPNs
2. Client background operation and battery optimization
3. Core status, subscription update time, and node availability
4. Mode, policy groups, rule matches, and DNS
5. The target app’s independent network behavior

6. Android configuration habits for long-term use

For long-term operation, keep a working baseline configuration and export or copy the current configuration before making changes. Subscription updates, core upgrades, Android updates, and manufacturer security policies can all change network behavior. After an update, test your usual browser, messaging apps, and apps that require sign-in. Then enable advanced features such as TUN, Fake-IP, IPv6, or custom rules one at a time.

For node selection, start with nodes that have stable latency and pass repeated tests, then observe real-world access. A latency test reflects only part of the path between the test target and the node; it does not prove that every service will work. Keep one clearly defined default node in the policy group to avoid an update automatically selecting an unavailable or unsuitable node. Keep rule-based routing readable so you can quickly find the policy associated with a domain when something goes wrong.

After an Android system update, recheck four settings: whether VPN authorization is still valid, whether the client is allowed to run in the background, whether battery optimization was enabled again, and whether the client is still locked in recent apps. If you use a work profile, cloned apps, or multiple users, confirm that the user space running the client has its own VPN permission. Some systems manage network services separately for work and personal profiles, so checking only one is not enough.

After completing the setup, run a full verification: start the client in the foreground and confirm that the VPN icon appears; in rule mode, test both direct and proxied destinations; lock the screen for several minutes and test again; switch once between Wi-Fi and mobile data; then check the logs for persistent connection errors. This covers the most common permission, background, and configuration issues when using Clash on Android and helps distinguish system restrictions from node failures.