Android Clash Client Settings: VpnService, Background Operation, and Battery Optimization

Understand how VpnService takes over traffic on Android

Clash-style Android clients typically use Android's built-in VpnService to create a local virtual network interface. Once the app starts the service, Android sends in-scope network traffic through this virtual interface, where the client core handles connections according to configured rules, proxy groups, and nodes. A key or VPN indicator in the status bar means the system VPN tunnel is active; it does not mean the phone is directly connected to a traditional corporate VPN server.

This process is easiest to understand in three layers. First, Android sends application traffic to the virtual interface. Second, the Clash or mihomo core reads details such as the destination domain, address, and port, then matches them against the rules. Third, it establishes the actual connection based on the result: DIRECT, a proxy node, a rejected connection, or another policy. The nodes and rule configuration supplied by the subscription determine how the third layer works; VpnService provides the traffic entry point for the first layer.

Within a single Android user profile, only one primary VPN service can usually be active at a time. If the system is already connected to a work VPN, another proxy client, a firewall, or a filtering tool that uses VpnService, starting Clash may stop the existing service or prevent the new service from obtaining VPN permission. If the app stops immediately after you tap Start, check the status bar and the system VPN page before repeatedly updating the subscription.

How VpnService differs from a regular system proxy

A standard HTTP system proxy relies on each app obeying the proxy setting. Some apps, UDP traffic, and software with its own networking stack may bypass it. VpnService receives in-scope traffic at the system network layer, so coverage is generally broader and Android clients commonly use this approach. Some clients call it VPN mode, TUN mode, or service mode. The names vary, but the key questions are whether an Android virtual interface was created and which apps are included.

Android VpnService is not exactly the same as manually enabling TUN on a desktop. Desktop systems may require a virtual network adapter, route changes, or elevated privileges; Android completes authorization through its public VPN API. The system confirmation dialog shown on first launch is a normal permission step. The client can create the tunnel only after you approve it.

Key settings to check on first launch

After importing a subscription, do not immediately blame battery management for every problem. First verify that the configuration loads, a node connects, and a proxy group has been selected; then address background keep-alive settings. A consistent troubleshooting order helps separate configuration errors from system restrictions.

1. Confirm that the configuration is enabled. The configuration list may contain multiple subscriptions or local YAML files. A successful update does not mean the new configuration is active. Check the active indicator, update time, and configuration name.
2. Check the proxy group selection. A proxy group may default to an unavailable node or remain in automatic latency testing. Select a node that has completed a latency test and can establish a connection, then test the website again.
3. Approve the system VPN request. The first launch usually displays a connection request. If you dismiss it, the client interface may open normally, but it cannot route system traffic.
4. Confirm the operating mode. Rule mode routes traffic according to the configured rules; Global mode usually sends most traffic through the selected proxy; Direct mode bypasses the proxy. Record the current mode during testing so Direct mode is not mistaken for a failed node.
5. Review the runtime logs. Configuration parsing failures, DNS errors, node handshake failures, and unreachable networks usually produce different log entries. Logs point closer to the fault than simply checking whether a webpage opens.

How to configure the app routing scope

Many Android clients support “Proxy selected apps only” or “Exclude selected apps.” The first is a whitelist approach: only checked apps enter VpnService. The second is a blacklist approach: checked apps stay on a direct connection. Do not infer the behavior from the label alone. Read the current screen's description before changing it, then verify with a browser.

Whether payment, banking, local-network control, casting, and smart-home apps should be excluded depends on your network requirements. An excluded app no longer passes through Clash rules, so its requests will not appear in the logs. If a browser works but one particular app does not, check the per-app routing list first.

Common causes of disconnects after screen lock

“Everything works while the screen is on, but connections fail after a few minutes of screen lock and recover when the client is opened” usually means the configuration itself works, but the background service is restricted, the process was reclaimed, or the network changed during standby. Android's native Doze mechanism, vendor battery management, background-start restrictions, and memory cleanup can all contribute.

Doze limits background activity and network access when the device is stationary, the screen is off, and other conditions are met. A foreground service is generally less likely to be stopped than a regular background process, so clients typically show a persistent notification after starting. If notification permission is disabled or the notification channel is blocked, some systems may still run the service, while others may restrict a foreground service that cannot display its notification properly. Keep the client's status notification enabled and avoid one-tap cleanup tools that terminate it.

First identify what kind of disconnect occurred

• VPN icon disappears: This most likely means VpnService stopped, the app process was cleaned up, or another VPN service took over the system tunnel.
• VPN icon remains, but all connections fail: The upstream network may have changed without restoring old connections, or the node, DNS, or virtual interface may be in an abnormal state.
• Only some apps fail: First check the app routing scope, rule matches, IPv6, DNS, and the target app's own background restrictions.
• Failure after switching from Wi-Fi to mobile data: Check whether the client can rebuild connections after a network change and whether mobile data access is permitted.
• Opening the client immediately restores connectivity: This usually points to a background restriction. Once the interface returns to the foreground, the system allows execution again and the service or core recovers.

Use a repeatable test during troubleshooting: keep the same configuration and node, open a page that refreshes continuously, lock the screen for ten minutes, then unlock it and check the VPN icon, client status, and log timeline. Repeat separately on Wi-Fi and mobile data. Change only one setting at a time so you can identify which battery policy is affecting the connection.

If the logs stop completely during screen lock and resume only after unlocking, focus on process keep-alive and battery restrictions. If requests continue to be logged but timeouts become frequent, investigate node availability, network switching, and DNS instead. When the system stops the service, some clients record service destruction or core exit messages at the end of the log; if the process is killed outright, there may not be enough time to record the full reason.

Battery optimization whitelist and background settings

Menu names vary by phone manufacturer, but the goal is broadly the same: let the client run continuously in the background, disable battery optimization for it, and permit necessary background network activity. The settings may be under App info, Battery, App launch management, or Special app access.

Recommended adjustment order

1. Set battery usage to unrestricted. Open the client's App info, find the battery settings, and choose “Unrestricted,” “Allow background activity,” or a similar option. On stock Android, this is commonly found under battery usage management in App info.
2. Turn off automatic management. Some systems provide switches for auto-start, associated start, and background activity. Disable automatic management, then follow the page instructions to allow the client to start itself and run in the background.
3. Keep the foreground-service notification enabled. Allow the client to show its running notification. The notification displays status and is also tied to Android's foreground-service mechanism.
4. Allow background data. Check mobile-data and WLAN permissions to ensure background data is not blocked. When Android's Data Saver is enabled, add the client to the “Unrestricted data” list.
5. Lock the app in recent tasks. Some vendor systems let you lock a task card, reducing the chance that a one-tap cleanup ends the app. This does not replace the battery whitelist, but it can supplement it.
6. Restart the client service. After changing permissions, stop and restart VpnService. If necessary, restart the phone, then retest screen locking and network switching.

Removing the client's battery-optimization restrictions usually increases background battery usage because the core must maintain the virtual interface, handle DNS, and preserve necessary connection state. Actual consumption also depends on traffic volume, rule-set size, log level, node protocol, and whether apps continue making network requests. Stabilize the connection first, then reduce unnecessary high-cost settings one at a time instead of disabling every background permission at once.

Will the client reconnect automatically after boot?

Whether the client can start at boot depends on whether the app supports it, whether the system permits auto-start, and whether VPN authorization and system policies remain valid. Some Android versions offer an “Always-on VPN” option that lets you select an app in system VPN settings. Whether it is appropriate for a particular client depends on that client's documentation.

“Block connections without VPN” is a stricter system-level option. If the selected VPN service has not been established, the device may lose network access. This makes failures more obvious while debugging the configuration, switching clients, or dealing with an unavailable subscription node. Consider enabling it only when traffic must always pass through the VPN, and first confirm that the client can start and restore its service reliably.

DNS, Private DNS, and network switching

A healthy background service does not guarantee that the name-resolution path is working. Android's Private DNS uses a system-wide encrypted DNS setting, while a Clash configuration may enable built-in DNS, Fake-IP, or rule-based DNS handling. These can take different paths depending on the client and configuration. If an IP connects but a domain does not open, or some apps spin indefinitely, investigate DNS separately.

For testing, temporarily set Android Private DNS to Automatic, then restart the client service. If the problem disappears, the specified Private DNS hostname, current network, or configured DNS path may have a compatibility issue. Do not rely on random switching as a long-term fix. Check whether DNS is explicitly enabled, whether the listener is suitable for an Android client, and whether the rules require specific domains to be resolved.

Fake-IP mode returns a mapped address from a reserved range for each domain; the core then restores the domain and matches the rules. This helps preserve domain information and keeps rule matching consistent, but some local-network services, specialized apps, or workflows that depend on real addresses may need exclusions. Other modes such as Redir-Host use a different resolution flow, so their filtering settings cannot be copied directly.

Recovering after switching between Wi-Fi and mobile data

When a phone leaves Wi-Fi, the underlying network, public address, and DNS environment all change. The client must detect the default-network change and use the new network for subsequent connections. If the VPN icon remains but access fails after switching, wait a few seconds, then stop and start the service in the client. If every switch requires a manual restart, check the client version, background-network permissions, and system VPN restrictions.

The situation becomes more complex with dual SIM, Data Saver, hotspot sharing, or local-network access enabled. Whether hotspot traffic passes through the phone's VpnService depends on the Android version, vendor implementation, and client capabilities. A phone using a proxy does not prove that hotspot traffic is also routed through it. Test the public address and DNS separately on the phone and the tethered device.

Log-based diagnosis and the full troubleshooting sequence

Logs from an Android Clash client commonly include rule matches, connection targets, selected policies, DNS handling, and error messages. You can temporarily raise the log level to Info or Debug while troubleshooting, but verbose logging increases processing and write activity when left on. Restore the normal level after collecting the evidence.

Common log clues

• timeout or connection timeout: the destination is unreachable, the node is slow to respond, the network switch has not recovered, or the DNS request did not complete.
• connection refused: the destination port explicitly rejected the connection, or a local listener or upstream service is not running.
• Configuration parsing error: check YAML indentation, field formats, subscription-conversion output, and settings unsupported by the current core.
• Repeated DIRECT matches: the current rule set classifies the traffic as direct; check rule order, operating mode, and destination domain.
• No logs for the target app: the app may be excluded from VpnService, or its traffic may not be entering the current client.

To confirm whether the system is stopping the process, you can use Android developer tools to inspect device logs, though this is an advanced method. After connecting a computer and authorizing debugging, filter for the app package name, VPN service, and process state. Package names vary by client; confirm yours in App info or the installed package details rather than reusing another app's package name.

adb shell dumpsys vpn
adb shell dumpsys deviceidle
adb shell dumpsys activity services

dumpsys vpn can help inspect the current VPN state, while dumpsys deviceidle shows device-idle and Doze conditions. The service list can help confirm whether the target process and service still exist. Output varies by Android version, so use these commands to verify symptoms rather than treating one fixed line as universal.

Recommended troubleshooting workflow

1. In the foreground, use one verified node and confirm that access works in Rule mode.
2. Confirm that the system VPN icon is present and that no other VPN, firewall, or proxy tool is using the tunnel.
3. Check whether the target app is included in the per-app proxy scope.
4. Turn off the screen for a timed test, recording the VPN icon, the time logs stop, and how connectivity returns.
5. Add the client to the battery-optimization whitelist and allow background activity, background data, and the running notification.
6. Test Wi-Fi, mobile data, and switching between them separately.
7. If only domain requests fail, check Private DNS, the configured DNS mode, and Fake-IP compatibility settings.
8. If the problem persists, back up essential settings, update to a maintained client version, and retest with the same subscription.

If a client update prevents the configuration from loading, do not copy every field from the old configuration into the new core. Clash Meta (mihomo) extends traditional Clash configuration support with additional rule and protocol capabilities, but core versions, supported fields, and defaults can vary between client packages. Read the client error log first, identify the specific field, and then adjust it using the documentation for the relevant core.

Reducing battery use after stability is achieved

Once the connection is stable, reduce battery use by reviewing logs, latency-test frequency, and unnecessary background requests. Testing latency across every node frequently creates many connections at once; very short subscription-update intervals also increase wakeups. Set the interval for automatic test groups according to actual usage instead of probing every node continuously for the newest result every minute.

The rule count itself is usually not the only source of battery drain. Pay closer attention to continuously active apps, connection retries, repeated DNS failures, and verbose logs. If a failed node remains selected by a policy group, background apps may reconnect repeatedly, hurting both usability and battery life. When logs show dense, repeated errors, switch nodes or correct the rules first.

The purpose of a battery-optimization whitelist is to let VpnService run reliably when needed, not to keep the client highly active forever. With sensible settings, the core can reduce work when there is no traffic and handle routing and forwarding when connections appear. A full day's battery statistics are more useful than watching a momentary percentage for a few minutes.

A simple final baseline is enough: one stable configuration, a clearly defined rule mode, the required app-routing scope, permission to run in the background, a visible foreground notification, and a record of the Private DNS and client DNS combination. If screen-lock disconnects return, reproduce the issue from this baseline before deciding whether a system update, client version, or subscription configuration changed.