How to Keep a Clash Client Stable on Android: VpnService Authorization and Battery-Optimization Exclusions

Separate the Three Runtime Layers: the Core, VpnService, and the Background Process

Android Clash clients usually consist of three coordinated parts: the Clash Meta (mihomo) core, which matches rules and forwards connections; VpnService, which uses Android system APIs to create a virtual network; and the app process, which handles the interface, notifications, and configuration. A reachable node only proves that the core completed a test; the VPN icon in the status bar confirms that Android is routing the selected traffic through the app.

VpnService is Android’s local VPN interface. After authorization, the client creates a virtual TUN interface. Android writes app traffic to that interface, and mihomo decides whether to connect directly, use a proxy, or reject it according to the rules. This is not the same as connecting to a traditional corporate VPN server: the virtual interface is local to the device, while outbound connections are still established by the client through the proxy nodes in its configuration.

VPN mode and local ports are different things

The Mixed port commonly found in configurations is 7890, the external control port is often 127.0.0.1:9090, and the DNS listener may use 1053. These ports serve manual proxying, the control interface, or DNS forwarding. Once Android VPN mode is enabled, most app traffic is handled by TUN, so you normally do not need to enter 127.0.0.1:7890 separately in every app. Enabling both the system Wi-Fi proxy and VPN mode can create duplicate forwarding, so keep only one entry point enabled while troubleshooting.

What the VpnService Authorization Prompt Means—and What to Do

The first time a client starts VPN mode, Android displays a system-generated connection request. It typically says that the app wants to set up a VPN connection and warns that the app may be able to view network traffic. Tapping “OK” grants that app permission to use VpnService for this session. The prompt is not a subscription login and does not select a node; it only determines whether the app may create a virtual network interface.

Standard startup sequence

1. Import a subscription or local configuration that parses correctly, then finish updating the configuration.
2. On the client’s home screen, choose a configuration and proxy group, and confirm that at least one node completes a latency test.
3. Turn on the “VPN mode,” “Service mode,” or similarly named service switch.
4. When Android shows the VPN connection request, tap “OK” and do not switch apps in a way that covers the prompt.
5. Wait for the VPN icon to appear in the status bar, then visit one site that should connect directly and another that requires a proxy rule.
6. Open the client logs and confirm that the requests match DIRECT and the intended proxy policy respectively.

Android generally allows only one regular VPN connection to be active in the same user space. WireGuard, corporate VPNs, ad blockers, firewalls, and other proxy clients may occupy that slot. Starting a Clash client can disconnect the existing VPN; conversely, starting another VPN can revoke the current VpnService. Work profiles are managed in a separate Android user space, so a VPN in the personal profile may not route traffic from work-profile apps.

What to Do When the Authorization Prompt Does Not Appear

• Check for an existing VPN: Go to Settings → Network & internet → VPN, disconnect the current connection, and return to the client to start the service. Some systems may label the entry Settings → More connections → VPN.
• Check Always-on VPN: Open the settings for the existing VPN and turn off “Always-on VPN” and “Block connections without VPN.” The latter may also be called “Block connections without a VPN.”
• Trigger authorization again: Stop the service in the client, then open the system VPN page and delete the VPN profile left by the app before starting it again.
• Confirm the user space: Dual-app instances, guest mode, and work profiles have separate authorization states. Authorize the connection in the same user space where the client is installed.
• Restart and try again: The system VPN service can occasionally retain a stale session. Restarting the phone is often more effective at clearing the occupied state than repeatedly tapping the start button.

Why Connections Drop After Screen Lock: Doze, App Standby, and Manufacturer Controls

Android’s power-saving behavior is not controlled by a single switch. Stock Android includes Doze, App Standby buckets, battery optimization, and background-execution limits. Manufacturer skins may add auto-start, linked-start permissions, lock-screen cleanup, and background high-power permissions. Even when a client reports a foreground service, the system may restrict its network access after the screen locks, freeze the process, or reclaim it under memory pressure.

A typical pattern is normal operation while the screen is on, followed by delayed messages 5 to 20 minutes after locking the screen; network access returns within seconds after the screen wakes. In another pattern, the VPN icon remains visible but the client logs stop updating until the app is reopened. The first points to restricted background networking; the second usually involves process freezing, service reclamation, or the core exiting.

A Reproducible Screen-Lock Test

The following measurements illustrate the diagnostic method and are not fixed power figures for every device. The test used a Pixel 8 running Android 15, Wi-Fi signal around -48 dBm, and Clash Meta for Android 2.11.14, with Rule mode and TUN mode enabled. The screen stayed off for 30 minutes, while another device sent one message to the test phone every 60 seconds.

The key point is not the 1% battery difference, but whether “Restricted” causes delays measured in minutes. Actual power use depends on cellular signal, node RTT, rule count, DNS requests, and activity from other apps. Test your own device with separate 30-minute Wi-Fi and cellular screen-lock sessions instead of relying only on the instantaneous rate shown in the client.

Battery-Optimization Exclusion Paths by Manufacturer

Menu names vary slightly by system version and region. The paths below reflect common releases from 2025 to 2026. If an item is missing, search Settings for “battery optimization,” “background activity,” “auto-start,” or the client’s app name. After changing these settings, restart the client service and repeat the screen-lock test.

Pixel and near-stock Android devices

1. Go to Settings → Apps → See all apps → select the Clash client.
2. Open App battery usage and set background usage to Unrestricted.
3. Go to Settings → Network & internet → Data Saver → Unrestricted data, and allow the client to use data while Data Saver is on.
4. Confirm that Settings → Notifications → the client’s notifications are allowed, and keep the service-status notification enabled.

Samsung One UI

1. Go to Settings → Apps → select the client → Battery, then choose Unrestricted.
2. Go to Settings → Battery → Background usage limits → Never auto-sleeping apps, and add the client.
3. Check the “Deep sleeping apps” list and remove the client if it appears there.
4. Go to Settings → Connections → Data usage → Apps allowed to use data, and confirm that background data is available.

Xiaomi HyperOS and MIUI

1. Go to Settings → Apps → App management → select the client → Battery saver, then choose No restrictions.
2. Go to Settings → Apps → Permissions → Autostart management, and allow the client to start automatically.
3. Open Recent apps, long-press the client card, and choose Lock to reduce the chance of the service being ended by a one-tap cleanup.
4. Open the client’s Data usage section and allow WLAN, mobile data, and background data.

OPPO, OnePlus, and realme

1. Go to Settings → Apps → App management → select the client → Battery usage.
2. Allow background activity, and disable automatic optimization for the app or choose No restrictions.
3. Go to Settings → Apps → Auto-launch, and allow the client to start automatically.
4. Lock the client in Recent apps so that Clear all does not stop the service.

vivo and iQOO

1. Go to Settings → Battery → Background power consumption management → select the client, and allow high background power usage.
2. Go to Settings → Apps & permissions → Permission management → Autostart, and allow the client to start automatically.
3. Open Recent apps and lock the client.
4. If Super power saving mode is enabled, exit it and restart the VPN service.

Huawei and HONOR

1. Go to Settings → Apps & services → App launch, find the client, and turn off Manage automatically.
2. Manually allow Auto-launch, Secondary launch, and Run in background.
3. Go to Settings → Battery → More battery settings and check the network connection option during sleep.
4. Lock the client in Recent apps and keep its service notification enabled.

Coordinating TUN, DNS, and App-Bypass Settings

Android clients commonly generate TUN parameters in the interface, so same-named fields in the configuration file may not have final control. Some clients expose “VPN service,” “TUN mode,” and “Service mode” as separate switches. Check the client settings before editing YAML; setting the same option in both the interface and configuration may cause the interface value to override the file.

mixed-port: 7890
external-controller: 127.0.0.1:9090

tun:
  enable: true
  stack: mixed
  auto-route: true
  strict-route: true

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip

This configuration shows a common structure and does not mean that every Android client requires manual entries. auto-route automatically configures routes, while strict-route reduces the chance of traffic bypassing TUN. Some mobile wrappers manage routing themselves, so rely on client logs and real traffic tests.

Two Approaches to Per-App Proxying

• Proxy only selected apps: Suitable when you know exactly which apps should use Clash. Newly installed apps are not added automatically, so review the list regularly.
• Bypass selected apps: Route most apps by default and exclude only banking apps, local-network casting apps, or apps that are sensitive to VPNs. This requires less day-to-day maintenance.

When an app is excluded from the VPN, its DNS requests and connections may bypass mihomo as well. During troubleshooting, do not compare only the web-facing IP; check the client logs for domains and connections initiated by that app. Android’s Private DNS uses encrypted DNS. Some clients can take it over at the TUN layer, while other combinations may cause resolution timeouts. If IP addresses work but domain names do not, temporarily go to Settings → Network & internet → Private DNS and switch it to Automatic for comparison.

Troubleshooting Drops: From System Status to Rule Logs

Changing the node, DNS, TUN, and battery settings all at once makes the cause difficult to isolate. A more efficient approach is to verify one layer at a time and record when the drop occurs. The sequence below applies to three common cases: working immediately after startup but failing after screen lock, failing to recover after switching Wi-Fi, and showing a VPN icon while web pages remain inaccessible.

1. Confirm the system VPN: Check the status-bar icon, then go to Settings → VPN and verify that the active connection belongs to the intended client.
2. Confirm that the core is still running: Open the client logs and check whether new entries still match the current time. If the logs stop completely, address background survival first.
3. Switch networks and retest: Turn off Wi-Fi, wait 20 seconds on cellular data, then turn Wi-Fi back on. Under normal conditions, the core should rebuild its connections.
4. Check the node: Run a latency test for the current proxy group. The latency value only shows that the test address is reachable; verify with a real webpage as well.
5. Check DNS: Visit a known IP address and a domain separately. If only the domain fails, inspect Private DNS, Fake IP, and the DNS listener status.
6. Check the rules: Find the target domain in the logs and confirm whether it ultimately matched DIRECT, a proxy group, or REJECT.
7. Disable conflicting features: Temporarily stop other VPNs, ad blockers, firewalls, and the system Wi-Fi manual proxy.
8. Re-establish the service: Stop the client, wait 5 seconds, and start it again. If it still fails, delete the system VPN profile and authorize it again.

Quick Diagnosis for Three Common Symptoms

Final Stability Checklist

• The system VPN page keeps only the connection currently needed; no other Always-on VPN is taking over.
• The client’s battery usage is set to Unrestricted, or to the equivalent option on the manufacturer’s system.
• Auto-start, background activity, and background-data permissions are all allowed.
• The service-status notification remains enabled and confirms that the service is still running.
• The system Wi-Fi manual proxy is not enabled alongside TUN mode.
• The per-app proxy list matches your intent; newly installed apps have been included or excluded as needed.
• After 30 minutes with the screen locked, the VPN icon remains visible and message delays stay within an acceptable range.
• After switching between Wi-Fi and cellular data, the connection recovers within about 20 seconds.
• The logs show direct and proxied requests matching the correct policies instead of relying only on latency-test results.

Stable Android operation comes down to two essentials: the system must let the client create and retain VpnService, and background policies must allow the foreground service and mihomo core to keep running. Resolve authorization conflicts first, configure battery exclusions second, and only then investigate nodes, DNS, and rules. This sequence usually cuts troubleshooting time significantly.