Android Clash Guide: VpnService Permissions and Battery Optimization

Understand VpnService, proxy ports, and TUN mode first

Android Clash clients typically use the system-provided VpnService to capture app traffic. Here, “VPN” refers to Android’s local traffic entry point: the client creates a virtual network interface, passes traffic to a core such as Clash Meta (mihomo), and then follows the configured rules to connect directly, reject the request, or forward it through a proxy node. A key or VPN icon in the status bar only confirms that the system VPN interface is connected; it does not guarantee that the node works or that every domain is being proxied.

This differs from manually entering an HTTP or SOCKS proxy. A manual proxy usually affects only apps that explicitly support proxy settings. Common listening ports include 7890, 7891, or the configured mixed-port; VpnService can receive TCP, UDP, and DNS traffic from ordinary apps. Buttons such as “VPN mode,” “service mode,” or “start” in an Android client usually control this VpnService channel.

Do not duplicate TUN settings with the client switch

Some Android clients create VpnService through a unified interface and automatically send traffic to the bundled core; others let you read the tun section directly from the configuration. Follow the client’s documentation and runtime logs. If startup logs repeatedly show interface creation failures, address conflicts, or duplicate routes, first restore the client’s default service mode instead of stacking multiple TUN switches.

mixed-port: 7890
mode: rule
log-level: info
ipv6: true

tun:
  enable: true
  stack: mixed
  auto-route: true
  strict-route: true
  dns-hijack:
    - any:53

The configuration above shows common mihomo fields; not every Android client requires them to be added manually. In particular, strict-route, IPv6, and DNS hijacking behavior depend on the Android version, core version, and how the client is packaged. For initial troubleshooting, use the configuration generated by the client, confirm a basic connection, and then change settings one at a time.

Handle the VpnService permission prompt correctly

When the service starts for the first time, Android displays a system-generated connection request, usually saying “This app wants to set up a VPN connection.” After confirmation, the system allows the app to call VpnService.Builder and create a virtual interface. This is an app-level permission, not a subscription entitlement or node account login. If permission is denied, the client can still load the configuration and test nodes, but it cannot capture traffic from other apps.

Recommended order for the first connection

1. Import a working subscription or local configuration and wait for parsing to finish.
2. Select a proxy group and an available node in the client. Do not leave it on “Auto” without any completed latency results.
3. Tap “Start,” “Connect,” or “Service mode,” then choose “OK” in the system prompt.
4. After the VPN icon appears in the status bar, open the client log and confirm that the core is listening on its local ports and has initialized the network interface.
5. Visit one site that should connect directly and another that should use the proxy. Check the rule-match records rather than looking only at the latency shown on the home screen.

If the permission prompt never appears, check for floating windows, eye-comfort overlays, auto-click tools, or password-manager overlays on top of the screen. Some Android versions disable security confirmation buttons that are covered by another window. Close the overlay, return to the client, and tap start again. If the button is greyed out, lock and unlock the screen, or remove the client from recent apps and reopen it.

Permission granted, but the connection still fails

• Another VPN is running: Go to “Settings” → “Network & internet” → “VPN,” disconnect other profiles, and then start the client.
• Always-on VPN points to an old app: Open that VPN profile, turn off “Always-on VPN” and “Block connections without VPN,” then select the current client again.
• The work profile has separate restrictions: Enterprise device management may prohibit users from creating VPNs. Check the administrator restrictions in the work profile.
• Permission broke after app-data migration: When a backup is restored to a new phone, VPN permission usually needs to be confirmed again. Uninstalling and reinstalling also clears the previous authorization.
• The core did not start successfully: Check the logs for configuration syntax errors, port conflicts, an empty subscription file, or missing referenced files.

Why battery optimization directly affects proxy stability

After the screen turns off, Android gradually enters App Standby and Doze. The system may restrict background execution, network access, scheduled tasks, and process recovery. Although VpnService usually runs as a foreground service with a persistent notification, device manufacturers add their own background cleanup, autostart, and power-management rules. The result may be a missing key icon, a killed client process, a tunnel that cannot be rebuilt after a network change, or a notification that remains visible while the core has stopped responding.

A battery-optimization exemption does not make the app run at high load continuously. It allows the app to maintain the necessary foreground service while the screen is off and Wi-Fi switches to mobile data or back. Continue to monitor actual battery use after changing the setting. Normal idle consumption depends on the number of rules, DNS lookups, connection activity, UDP sessions, and signal quality; a single percentage cannot determine whether the client is malfunctioning.

Stock Android and Pixel

On Android 14 and Android 15, the common path is “Settings” → “Apps” → “See all apps” → select the client → “App battery usage.” Turn on “Allow background usage” and choose “Unrestricted” when available. Some versions show “Settings” → “Apps” → select the client → “Battery” → “Unrestricted.” Then go to “Settings” → “Network & internet” → “VPN” and make sure an old always-on profile has not replaced the current client.

Samsung One UI

In One UI 6 and One UI 7, start with “Settings” → “Apps” → select the client → “Battery” → “Unrestricted.” Then check “Settings” → “Device care” → “Battery” → “Background usage limits” → “Never auto sleeping apps,” and add the client. If it already appears under “Deep sleeping apps,” remove it from that list first.

Xiaomi HyperOS and MIUI

The common HyperOS path is “Settings” → “Apps” → “Manage apps” → select the client → “Battery saver” → “No restrictions.” Then go to “Settings” → “Apps” → “Permissions” → “Autostart” and allow the client to start automatically. Older MIUI versions may show an “Autostart” switch directly on the app-info page. Locking the app in the recent-apps screen only reduces the chance of manual cleanup; it does not replace the battery policy or autostart setting.

OPPO, OnePlus, and realme

Menu names vary by ColorOS and realme UI version. A common path is “Settings” → “Apps” → “App management” → select the client → “Power usage,” then enable “Allow background activity.” Next go to “Settings” → “Battery” → “More settings” → “Optimize battery use” or “App battery management,” and set the client to “Don’t optimize.” Some OnePlus versions use “Settings” → “Apps” → “Special app access” → “Battery optimization.”

vivo and iQOO

The common OriginOS path is “Settings” → “Apps & permissions” → “App manager” → select the client → “Battery” or “Power usage,” and allow “High background power consumption.” Also go to “Settings” → “Battery” → “Background power consumption management,” find the client, and allow background activity. If the system manager provides an autostart list, allow the client to restore the service after the system reclaims its process.

Huawei and Honor

The common HarmonyOS path is “Settings” → “Apps & services” → “App launch management.” Find the client, turn off automatic management, and manually allow “Auto-launch,” “Secondary launch,” and “Run in background.” The corresponding entry on Honor MagicOS is usually also under app launch management or battery optimization. After configuring it, do not use the system manager’s “Optimize” button if it would disable these permissions again.

Manufacturers may rename these menus after system updates. If you cannot find an entry in the table, search the top of Settings for “battery optimization,” “background activity,” “autostart,” or “app launch management.” The goal is threefold: allow background operation, exclude the app from aggressive battery optimization, and let the system restore the service after a reboot or process reclaim.

Use a fixed test procedure to verify background operation

Do not judge the result after only two or three minutes. Android’s idle restrictions often become apparent after the screen has been off for a while, and a network change exposes problems more readily than continued use on the same Wi-Fi connection. Use the 30-minute procedure below and record the client notification, VPN icon, log timestamps, and actual connectivity at every step.

1. Connect to Wi-Fi, start the client, and confirm that the rules mode, active node, and subscription configuration have loaded.
2. Visit one direct-connection target and one proxied target, and confirm that the log shows DIRECT and a match for the corresponding proxy group.
3. Turn the screen off for 15 minutes without opening the client. Unlock it and immediately test a webpage and message synchronization.
4. Turn off Wi-Fi, switch to 4G or 5G, wait 30 seconds, and check whether the service rebuilds the connection automatically.
5. Turn the screen off for another 15 minutes, then restore Wi-Fi and confirm that DNS lookups and new TCP connections complete successfully.
6. Swipe the client away from recent apps, then check whether the VPN continues running as designed. Some clients treat dismissal as a stop command; follow the client’s own documentation.

A latency figure is not the same as real-world availability

Latency tests in a node list usually request a specific URL and show only the connection-establishment time to that test address at that moment. A node showing 80 ms may still fail to load webpages because of DNS, UDP, rule selection, or a connection problem at the destination. A timeout does not necessarily mean the node is unusable either; the test URL may be blocked by the node or network. When troubleshooting disconnects, follow the timeline in the connection log. Pay particular attention to core exits, interface closures, DNS timeouts, or missing proxy-group nodes before and after a network change.

A layered checklist for frequent proxy disconnects

Layer 1: Confirm that Android has not stopped the service

• Check whether the VPN icon disappears after the screen turns off.
• Check whether the persistent notification has been disabled. On Android 13 and later, notification permission affects status visibility, and some clients also rely on the foreground-service notification.
• Confirm that Battery Saver, Extreme Battery Saver, and sleep modes have not temporarily overridden the app’s battery exemption.
• After a system update, check whether options such as “Unrestricted” and “High background power consumption” have reverted to their defaults.
• Make sure scheduled cleanup, game acceleration, or a system manager task has not ended the client process.

Layer 2: Distinguish a stopped core from a failed node

If the local log stops updating and the client home screen cannot load traffic statistics, the local core may have exited. If the log continues to show connection records but repeatedly reports timeouts, refused connections, or failed TLS handshakes, the problem is more likely the node, route, or subscription parameters. Switching to another node in the same proxy group is more informative here than repeatedly restarting VpnService.

If connectivity suddenly fails after a subscription update, confirm that the client has reloaded the configuration. A proxy group that references a nonexistent node name may have no usable exit when a rule matches it. In the logs, identify the proxy group that actually matched and the final node used; do not check only the node count shown on the subscription page.

Layer 3: Check DNS and IPv6

When some apps work but some domains do not load, check DNS first. Fake-IP mode requires the client to capture DNS requests correctly and maintain mappings between domains and virtual addresses. Android Private DNS, a browser’s secure DNS, and an app’s built-in DoH may bypass the expected path. Temporarily set Android “Settings” → “Network & internet” → “Private DNS” to “Automatic,” restart the client, and test again.

IPv6 should also be tested separately. Mobile networks may assign IPv6 while the configuration or node reliably supports only IPv4. Do not permanently disable IPv6 at the outset. Test both address families on the same network with the same node, inspect the destination address family and failure type in the logs, and then decide whether to adjust ipv6, DNS response behavior, or TUN routes.

Layer 4: Check per-app proxying

Android clients commonly offer two opposite modes: “Proxy selected apps only” and “Exclude selected apps.” Restart the service after switching modes because the app list is usually written into the allowed or denied range when the VpnService interface is created. If only one app cannot connect, first confirm that it is in the correct list, then check whether it runs in a work profile, app clone, or another Android user profile.

Layer 5: Handle phantom connections after a network change

When switching from Wi-Fi to mobile data, the source address used by existing connections is no longer valid. The client should receive the system network change and rebuild necessary connections, but some long-lived connections will not recover immediately. Wait 30 seconds and open a new webpage first. If there is still no traffic, stop and start the client once. Only if every network change requires a manual restart should you continue checking background restrictions, system VPN settings, and client logs rather than treating it as a node-latency problem.

Minimum settings for stable operation

Keeping a Clash client stable on Android does not require enabling every system permission. The minimum setup is: grant the VpnService permission; keep only one active VPN; allow the client to run in the background and exclude it from aggressive battery optimization; enable autostart if needed; confirm that the persistent notification and foreground service are working; and use a fixed procedure to test screen-off behavior and Wi-Fi/mobile-network switching.

Keep the configuration simple at first. Use a valid subscription, one clearly defined proxy group, a readable info log level, and the client’s default service mode. After that works, add Fake-IP, per-app proxying, custom rules, or TUN parameters one at a time. When disconnects recur, troubleshoot in this order: system process → local core → node and route → DNS and routing → per-app scope. This prevents every failure from being blamed on battery settings.