Choosing an Android VPN means looking beyond connection speed. Background activity, battery restrictions while the screen is locked, and per-app proxying all affect whether a client works for everyday use. A connection may work with the screen on but drop after locking, or a browser may work while a collaboration app still connects directly. Check each issue separately. First confirm subscription compatibility, then test background operation, and finally check app routing.
Android Client Picks: Check Configuration Compatibility First
Android clients typically use the system VPN service interface to handle device traffic, but they do not necessarily use the same proxy protocols. Shadowsocks, VMess, Trojan and VLESS are different protocol options; Hysteria2 and TUIC use QUIC-based transport. Whether a protocol works depends on the server configuration, client core and network conditions, not just the app name.
A client's graphical interface is not the same thing as its proxy core. Apps based on the same core may offer different app selectors, log access and subscription update methods. Start by checking which configuration formats the service supports. Do not paste a subscription link into an arbitrary client and mistake a parsing failure for a route problem.
| Client type | Suitable needs | What to check | Limits of background operation |
|---|---|---|---|
| v2rayNG | Import compatible node subscriptions and choose apps for proxying | Node protocol, subscription parsing, app list and routing mode | Still subject to system background and battery policies |
| Android clients based on Mihomo | Use compatible configurations and organize traffic by domain and rules | Whether the interface offers app filters, rule sets and DNS settings | A running core does not mean every network session will stay connected |
| sing-box Android graphical clients | Manage routing and DNS settings explicitly | Configuration syntax, core compatibility and app-routing options | Diagnose configuration errors separately from system process termination |
| Service companion clients | Reduce manual importing and configuration | Whether background guidance, app routing and logs are available | Being a companion app does not guarantee an uninterrupted locked-screen connection |
This table compares client types, not connection speeds. Android app filtering is closely tied to the system VPN interface and does not work like process rules in desktop clients. Buttons with familiar names on other platforms may not mean the same thing on Android.
Background Tests: Separate Process Termination from Connection Failure
“Disconnected in the background” can describe several different problems. If the system terminates the client process, its persistent notification and VPN status may disappear too. If the process is still running but cannot recover after a network change, the notification may remain visible. If a node is unreachable or DNS requests fail, the interface may still show a connected state. A screenshot of a connection icon alone cannot identify the cause.
Before testing, record the device model, operating system version, client version, configuration and network type. Keep the node, proxy mode and test apps consistent. First confirm that access works with the screen on, then test while the screen is locked. When comparing clients, do not also change nodes or DNS settings, or it will be hard to tell what caused the difference.
- Establish a screen-on baseline.After connecting, open the target website and the app you actually use. Confirm that the page reloads rather than showing cached content. Note the system VPN status and whether the client logs look normal.
- Observe recovery after locking.Let the device sit idle as it would in daily use, then unlock it and try again. Record whether the notification remains, whether a manual reconnect is needed, and whether existing connections behave differently from new requests.
- Check network changes.Switch between Wi-Fi and mobile data, then make a new request. An existing session ending does not necessarily mean the background process was terminated. What matters is whether the client can restore subsequent access.
- Compare battery settings.Change only the client's background restrictions, then repeat the same steps. An improvement provides evidence that system policies were involved; do not assume the route was at fault.
- Record evidence of issues.Save error messages and note the conditions in which they occur. Before sharing logs, redact subscription URLs, authentication details and other sensitive information. Do not publish the full configuration.
Video meetings and long downloads need separate testing. A web page may recover after a new request, while a meeting's media session or an active transfer may not resume seamlessly. Test with the apps you actually use; “the page opened after unlocking” is not proof that every task maintained its connection.
Battery Settings: Allow Background Activity Without Removing Every Restriction
Android idle and battery-saving features can affect background tasks and network activity. Device manufacturers may also add app sleep, background freezing or startup management. Common options are under an app's system settings, battery usage or background management. They may be called “Unrestricted,” “Allow background activity” or something similar; check the labels on your device.
If the client offers a persistent notification, keep it enabled to monitor its status. Some systems also provide auto-start settings or app locking in the recent-tasks view. These can help with troubleshooting, but they are not universal guarantees of background operation. Do not disable battery-saving features for every app just for one client, and avoid changing system permission boundaries solely to keep it running.
- ✅ Confirm that the client has system VPN permission and that its status and notification look as expected after starting the service.
- ✅ Check battery optimization, background activity and manufacturer startup restrictions only for the client you use.
- ✅ Check whether another system tool is already using the VPN interface. A local filtering tool and proxy client may replace each other.
- ✅ Change one setting at a time, then repeat the lock-screen and network-switch tests and compare the results.
- ❌ Do not treat a persistent notification, app lock or battery exemption alone as proof of an uninterrupted connection.
Per-App Proxy Tests: The Routing Mode Matters More Than List Length
Per-app proxying usually offers two modes: “proxy only selected apps” and “bypass the proxy for selected apps.” The labels may instead refer to include mode, exclude mode or a bypass list. If you check the selected apps without checking the mode, the result can easily be the opposite of what you expect. Some clients also require restarting the VPN service after changing the list.
App filtering is also different from domain-based routing. Even when an app is included in the VPN, its connections may still be controlled by domain, address and fallback rules; not all traffic necessarily goes through a remote node. An excluded app, by contrast, will generally no longer be handled by that client's tunnel. Check the behavior of the specific client and configuration you use.
For a practical test, choose one app that needs a proxy and one that should connect directly. Confirm the routing mode in the client, apply the app settings and rebuild the connection, then reopen each app and make a new request. If the app provides a reliable egress check, verify the result there; otherwise, inspect the client connection logs to see which route handled the request. A page loading on its own does not prove which path it took.
An IP lookup in a browser shows the egress used for that browser's request only; it cannot confirm the route for other apps. An app may use a system download component, an external browser or another process for some operations. If “the main app works, but sign-in or downloads fail,” check the component that made the request instead of continually expanding the proxy list.
On a device where only a few apps need access to international websites, include mode makes the scope easier to define. Where most apps need a proxy and a few need local access, exclude mode may be easier to maintain. Choose the mode you can understand and verify rather than trying to make the list as long as possible.
DNS and Route Troubleshooting: Changing Protocols Is Not a Substitute for Diagnosis
DNS resolves domain names to addresses, and the resolution path may differ from the connection path. A browser's secure DNS, system private DNS, the client's built-in resolver and an app's own DNS behavior may all be involved. Before running a DNS leak check, clarify which resolver should handle requests and then verify what actually happens. The resolver name shown on a test page does not identify the location of the proxy egress.
If only certain domains fail, first check the client's DNS logs, matched rules and browser settings. If every request fails, check node reachability and the system network. Do not disable encrypted DNS blindly just to make a test result look consistent, and avoid changing multiple resolution methods at once in ways that make the problem impossible to reproduce.
Route type and background operation are separate issues. An IEPL line describes a network-link arrangement; a relayed route typically passes through a forwarding entry point, while a direct route emphasizes a connection from the client to the target node. These labels alone do not prove end-to-end latency, packet loss or app availability. Even a stable route cannot handle traffic if the system has terminated the client.
Likewise, UDP traffic used by Hysteria2 or TUIC may be restricted by the current network. Switching to another compatible protocol can help with comparisons, but it cannot fix a frozen system process. Troubleshoot in layers, from the local network and system service to configuration parsing and node connectivity. For specific steps, see the troubleshooting guide; for client setup, see the setup guide.
Recommendations by Use Case
Beginners should start with a client that clearly supports the service's configuration and makes errors easy to understand. Users who need detailed routing should look for ways to compare the app list, matched rules and DNS logs. For frequent screen locking or network changes, test recovery on the actual device before judging the interface or running speed tests.
Bottom line: There is no background-operation winner independent of device and configuration. Choose a client that supports the subscription, then use the same node to test with the screen on, after locking, across network changes and with per-app routing. A suitable daily client is one that recovers reliably, makes its routing understandable and lets you identify failures.
After choosing a client, check the data plans against your usage. VPNLiuLiang monthly subscriptions offer 60GB ¥9.9, 250GB ¥18 and 500GB ¥28, resetting monthly on the activation date. Data packages offer 300GB ¥158, 1000GB ¥358 and 3000GB ¥658; they last until used and never expire. Compare monthly subscriptions for regular use and data packages for occasional use. Do not choose a plan based only on a single speed test.
VPNLiuLiang offers 90+ countries, 180+ routes, unlimited devices and a 30-day no-reason refund. Unlimited devices do not mean every device has the same system settings; background and routing behavior still need to be checked on each one. Create an account without an email address using a username and password. Check plan details on the plans page. For reproducible issues, submit a redacted report through the support ticket system.