Clash Meta for Android Guide: VpnService Permissions, Per-App Proxying, and Battery Optimization

Understand the difference between VPN routing, rule-based traffic handling, and background operation

Clash Meta for Android on Android typically involves three layers of settings: Android grants permission to create a VPN interface, the client decides which apps use it, and the core applies rules to determine how connections are routed. Battery settings affect whether the client keeps running in the background; they do not choose a proxy node. These layers interact, but troubleshooting is easier when you check them separately.

Clash Meta and Mihomo are related through their core history, but the client’s name alone does not tell you which core version or features it includes. First, note the app version on the client’s About page, then check the startup logs for the core version. Menu labels vary between builds. This guide uses the common Settings → Network path for traffic routing and access control, and gives Android or manufacturer OS version ranges for system settings.

VpnService permission: What does the prompt allow?

When you first start the proxy service, Android displays a VPN connection request warning that the app may monitor network traffic. Once you approve it, Android lets the client create a local VPN interface and handle packets routed through it. This is not confirmation of a subscription purchase, nor does it connect your phone to a remote VPN server provided by Android. The remote exit is determined by your subscription’s nodes, your proxy group selection, and the rules.

Check these steps in order the first time you connect

1. Import a subscription from a trusted source, make sure the configuration is selected, and check that the proxy page shows proxy groups and nodes.
2. Start the client service, verify the app name in Android’s permission prompt, and approve the connection request.
3. Go to Android Settings → Network & internet → VPN and check which app is connected. On manufacturer-specific versions of Android, search Settings for “VPN.”
4. Open a page you haven’t loaded before in your browser, then check the client’s connection screen and logs. Don’t rely on the VPN key icon in the status bar alone.

The VPN icon only indicates that Android has an active VPN connection. It doesn’t confirm that a node is reachable, DNS is working, or a webpage is using the intended exit. HTTPS content is generally still protected by TLS between the app and the website. However, the client handling your traffic and the remote service may be able to see connection destinations and timing, so assess the app’s source and subscription provider separately.

Other VPNs, always-on VPN, and blocking connections outside the VPN

An Android user or work profile can generally have only one active VpnService at a time. Starting another VPN, firewall, or filtering tool that uses a local VPN may replace the current connection. Work profiles also have separate management policies, so don’t assume that settings for your personal profile apply there.

Android’s VPN details may include “Always-on VPN” and “Block connections without VPN.” The latter changes how failures behave: if the service stops, network access may be blocked entirely. Apps excluded from the VPN may also be blocked instead of falling back to a regular direct connection. First verify basic connectivity and per-app behavior, then decide whether to enable these options.

Per-app proxying: Choose which apps are routed, then check the rules

Per-app access control generally offers two modes: “Allow selected apps” and “Bypass selected apps.” The first is useful when only a few apps should use the VPN; the second when most apps should be routed and only a few should be excluded. What a checked box means depends on the selected mode, so don’t judge by the checkmark alone.

Example: a browser and a maps app

1. In the client, go to Settings → Network and look for “Access control mode” and the app selection screen. Some builds combine these under “Access control.”
2. To route only your browser, select the mode that allows only selected apps, then check the browser. Don’t add the maps app as well.
3. Save your settings, then stop and restart the client service. The app selection often takes effect only after the VPN interface is recreated.
4. Close any existing network sessions in the browser and maps app, then make a new request in each. If needed, force-stop the app and reopen it.
5. Check the connection screen to see whether browser requests appear. If the maps app isn’t routed through the VPN, it usually won’t appear in the client’s connection log.

Being routed through the VPN doesn’t necessarily mean an app uses a proxy node. Even after the browser is routed, its domain may match a DIRECT rule and connect directly. Conversely, an app excluded from the VPN won’t have its exit determined by this client’s domain rules. Check that the request reaches the core before investigating rules and proxy groups.

Common misreadings of app lists and connection logs

• Same display name: A beta, release, or work-profile app may be a different installation. If you can view the package name, check that too.
• App redirects: If an app opens a link in an external browser, the browser—not the original app—may be making the connection.
• Existing connections: After changing the app list, existing sessions may continue using their previous route for a while. Test with a new request instead of just refreshing a cached page.
• System components: Downloads, push notifications, and sign-in flows may involve other processes. Don’t allow every system app just to make one connection appear in the log.

Start with a minimal test using one browser, then add apps one at a time. This makes it easier to identify which change caused a sign-in issue, local network access failure, or loss of connectivity in an app.

Battery optimization exemptions by Android version

Background disconnects often happen when the screen turns off, battery saver starts, or the device has been idle for a long time. Allowing background activity can reduce the chance that Android restricts the service, but it won’t fix an unavailable node, an expired subscription, or a disconnect caused by switching Wi-Fi networks. The paths below are based on the listed OS versions; labels can vary by region, device, and software update. If you can’t find a setting, long-press the app icon and open App info.

Check two more settings beyond battery permissions

• Background mobile data: Open the app’s data usage or mobile data settings and make sure background data is allowed. If Data Saver is on, allow unrestricted data usage for the client if needed.
• Service notifications: On Android 13 and later, allow notifications if you want to monitor the app’s status. Notification permission is not the same as background execution permission, and denying notifications does not necessarily prevent a foreground service from starting.

Some manufacturers let you lock an app in the recent apps screen. This can help prevent it from being removed during manual cleanup, but it doesn’t replace battery settings. Android’s Force stop has a stronger effect than swiping an app away; after force-stopping, reopen the client and start the service manually rather than expecting an exemption to restore the connection.

Step-by-step tests for disconnects when the screen is off

During testing, record “service stopped” separately from “service still running, but requests fail.” The steps below provide a repeatable check; they are not results from device testing. The test durations standardize the observation period and don’t mean every system restricts background apps after the same amount of time.

1. Establish a baseline: Use the same Wi-Fi network, node, and rules mode throughout. Record the start time, app version, core version, and whether battery saver is on.
2. Test with the screen on for 2 minutes: Make a new browser request and check the matched rule and exit in connection details. If it already fails, troubleshoot the configuration before changing battery exemptions.
3. Test with the screen off for 10 minutes: Leave the client service running. When you wake the phone, first check whether the service is still running, then request a new page and review the logs for that period.
4. Test network switching separately: With the screen on, switch from Wi-Fi to mobile data and retry once the connection is stable. Don’t combine network switching and screen-off behavior in a single test.
5. Retest after one change: Change only this app’s battery restriction, then repeat the 10-minute test. If it passes, run another 30-minute test.

Choose the next check based on what you see

If you suspect Android Private DNS is incompatible with the client’s DNS resolution path, note the current setting, then temporarily select “Automatic” under Settings → Network & internet → Private DNS and compare the results. One test only shows what happened with those settings; it doesn’t prove that all Private DNS configurations cause conflicts. On manufacturer-specific versions of Android, search Settings to find this option.

Minimal checklist for a reliable connection

A stable mobile setup doesn’t require turning on every available option. First confirm that the subscription is active and the proxy group works, then check VpnService permission, which apps are routed, and background permissions. Frequent health checks can also increase wakeups and network activity. If your configuration uses an automatic health-check proxy group, check its interval and the provider’s requirements instead of increasing the check frequency just to keep the app alive.

• Android’s VPN page shows the expected client, and no other local VPN tool has replaced it.
• You know whether you’re using Allow selected apps or Bypass selected apps, and you’ve restarted the service after changing the app list.
• Check the matched rule and final exit in connection details. Don’t treat the VPN icon as proof that proxying works.
• Allow this client to run in the background, and configure autostart, background data, and notifications as needed.
• Test with the screen on, the screen off, and a Wi-Fi-to-mobile-data switch separately before considering additional options such as Always-on VPN.

When asking for help, provide your OS and client versions, the time of the disconnect, and redacted logs. Don’t share full subscription URLs, node passwords, or access tokens in screenshots or public posts. A specific report such as “the service stops after 10 minutes with the screen off” or “the service is still running, but DNS times out” is more useful for troubleshooting than “connected but not working.”