Best Android VPN 2026: Keep-Alive, Battery Settings & Per-App Proxy Tests

On Android, Fix Dropouts First, Then Talk Speed

A VPN client on Android isn't an ordinary app. It runs on top of the system's VpnService and has to keep a foreground service alive for as long as the connection lasts. Since Android 8, a foreground service requires a persistent notification — and that notification isn't ad space, it's the credential that keeps the process alive: clear the notification or revoke notification permission, and the system has grounds to reclaim the process, taking the connection down with it.

The system applies restrictions in three layers. Leave any one of them in place and the symptom is always the same: the connection drops a few minutes after it connects.

• Doze: after the screen has been off and the phone left still for a while, the system defers background network access, and deep Doze cuts the network entirely;
• App Standby: apps that haven't been opened for a long time get demoted and their background job quota tightened;
• Vendor battery policies: custom ROMs add another layer on top of the stock mechanisms, including autostart restrictions, background high-power-drain limits and one-tap boost whitelists.

So the order of checks should be: first confirm the connection holds with the screen off, then compare route speeds. If keep-alive isn't solved, a faster route only pushes the moment of disconnection a little later.

Keep-Alive: Three Triggers to Check One by One

Breaking “will the system kill it?” into three observable triggers is far more useful than a vague claim of “stable”. These three are where problems surface first when you put candidate clients on the same device and the same network and check them item by item.

Trigger 1: The Doze Window After the Screen Goes Off

Everything works with the screen on, then the connection drops five to ten minutes after the screen goes off — this is almost always the cause. The check is simple: turn the screen back on and look at the client's connection timer. If it starts from zero, the connection broke in between; if it keeps counting, the foreground service survived.

Trigger 2: Background Cleanup and One-Tap Boost

Swiping the client out of Recents, or tapping the system's one-tap cleanup, makes some ROMs kill the foreground service along with it. Whether it recovers on its own depends on whether the client implements reconnect and autostart; retest this step after you've finished the whitelist settings.

Trigger 3: Low Battery and Long Idle Periods

Once the battery drops below a threshold, the system freezes background processes; connections with no traffic in either direction for a long stretch are also reclaimed first — you'll hit this most often when leaving a livestream running or waiting only for push messages.

• ✅ After 30 minutes with the screen off, the client still shows connected, with an unbroken connection timer.
• ✅ Swipe the client out of Recents and open it again — the connection recovers on its own, with no manual reconnect.
• ✅ The connection isn't frozen when the battery drops below 20%, and the persistent notification stays in the status bar.
• ✅ When switching between Wi-Fi and mobile data, the client re-establishes the connection within seconds.
• ❌ It only connects with the screen on and drops a few minutes after the screen goes off: fix the battery whitelist first, don't rush to change routes.

Battery Whitelists: Where to Look on Major ROMs and Which Switches Matter

A whitelist isn't about granting every permission — it's about finding the right three switches: background running, autostart and unrestricted battery. The table below lists approximate paths for common ROMs; menu names vary by system version.

Per-App Proxy: Sort Your Traffic Into Three Tiers

Per-app proxy (some clients call it app-based routing) is more useful on Android than on desktop: only the apps you pick go through the proxy, while everything else stays direct. Before you start, sort the apps you use every day into three tiers by purpose.

• Through the proxy: browsers, tools that need to reach international sites, overseas streaming services, AI tools;
• Direct: banking and payment apps, local services and transport, corporate intranets, smart home and car apps;
• Case by case: social apps (text messages are usually fine through the proxy, test voice calls separately), download apps (it depends on whether the target resource is hosted abroad).

Keeping banking and payment apps on a direct connection isn't superstition: they check the login environment, and an exit IP that changes often tends to trip risk controls, which makes the verification process noticeably longer. Corporate intranets are even more clear-cut — once traffic goes through a proxy, internal addresses simply don't resolve.

1. Turn on per-app proxy in the client and prefer the “proxy only selected apps” mode over “exclude selected apps”;
2. Start by ticking the browser and the tools that need international routes, then connect and verify each target site one by one;
3. Leave banking, payment and local services unticked and confirm they still log in normally;
4. Run the same route for a full day, note which apps misbehave, then go back and fine-tune the list.

One more thing that's easy to overlook: DNS. If domain resolution still goes to a local DNS server while traffic is proxied, it both leaks what you're visiting and can resolve requests to a distant CDN node. If your client offers a “remote DNS” or “proxy DNS” switch, turn it on.

Routes and Protocols: Three Things to Check on Mobile Networks

• 220+ total routes, including IEPL dedicated lines
• 120+ countries and regions covered
• Unlimited devices online at the same time
• 30 days no-questions-asked refund window

Protocols: Can You Switch With One Tap?

Shadowsocks, VMess, Trojan and VLESS are primarily TCP-based, work almost anywhere and are stable enough on networks without heavy packet loss. Hysteria2 and TUIC are built on QUIC and run over UDP, which makes them more resilient when a mobile connection hops between cell towers, the signal fluctuates or packets get dropped. The trade-off is that some networks rate-limit or outright drop UDP, so the client needs one-tap protocol switching — when a connection fails, switch protocols first instead of tapping reconnect over and over.

Route Types: Direct, Relay and IEPL Dedicated Lines

With a direct route the client connects straight to the exit server — the shortest path, but fully exposed to public-internet fluctuations. A relay adds an entry server that forwards traffic, making the path somewhat more predictable. IEPL dedicated lines run end to end without touching public internet exchanges, so they show the least jitter at peak hours. On mobile networks, prefer dedicated lines; the difference is especially clear on subways and high-speed trains, where the phone switches cell towers constantly.

Subscriptions and Updates: Less Manual Work When You Switch Devices

Import the subscription link once and the route list is maintained server-side — routes added or retired don't require editing configs one by one. When you switch devices or reinstall the client, importing the subscription again restores everything; if the client supports automatic subscription updates, set the interval to once a day — anything more frequent makes no practical difference.

Recommendations by Device and Usage

FAQ