Best Android VPN: Background Keep-Alive, Battery Policy and Per-App Proxy, Tested

The most common mistake in Android VPN recommendations is treating node count as the only metric. In real use, dropped connections, tunnels that die the moment the app goes to the background, and an app that never seems to go through the proxy almost always come from the system layer: the background process gets cleared by battery policy, the VpnService gets reclaimed by the system, or the per-app list is inverted. Below we compare all three, then give the full order from importing a subscription to verifying the connection.

Three variables decide how an Android phone actually performs

On desktop, as long as the process stays alive the connection is basically stable. Android isn't like that: when memory is tight, the screen locks or the phone sits idle for a long time, the system reclaims background processes — and once the VpnService a VPN depends on is reclaimed, the connection drops and the status bar icon disappears with it. To work out which layer the problem sits in, start with three variables.

Background keep-alive: VpnService and the notification you can't get rid of

Android VPNs don't work by editing the routing table. The client asks the system for a VpnService, the system creates a virtual network interface, and traffic is fed into the tunnel according to rules. The system requires apps like this to run as foreground services, so a notification stays in the status bar for as long as the connection is up. That notification isn't an ad: it's also how the system knows the process is still working. Swipe it away and you are usually telling the system to reclaim the connection.

Always-on VPN and Block connections without VPN

System settings give every VPN profile two switches: Always-on VPN (connect at boot) and Block connections without VPN (cut all traffic when the tunnel drops). The first suits a phone you use every day; the second suits situations where exit consistency matters, but be clear about the cost — when the tunnel misbehaves the whole device briefly has no network, and system updates stall too.

Battery optimization needs its own exemption

Settings → Apps → App info → Battery, then change optimization to Unrestricted. This is the stock Android mechanism, and it is a separate thing from the vendor battery policies covered below — both need to be allowed, and changing only one can still get the connection killed.

Vendor battery policies, brand by brand

Stock Android has a single battery optimization entry; Chinese phone makers layer their own background management on top. The table below lists where to change things on common custom ROMs — names shift between versions, but the locations stay roughly the same.

Once all three are allowed, verify: connect, lock the screen for ten minutes, unlock and check whether the VPN icon is still in the status bar, then check the IP again to confirm it still shows the node's location. This step does more good than reinstalling the client over and over.

Per-app proxy: allowlist or blocklist

Per-app proxy is implemented by the client at the VpnService layer and doesn't need root. In common clients it is called 'Per-app proxy' or 'Access control'; there are only two models — proxy only the selected apps (allowlist), or proxy everything except the selected apps (blocklist). Both work; the difference is what happens by default when you install something new.

• Allowlist saves data: newly installed apps stay outside the tunnel until you add them.
• Blocklist is less work: everything goes through the tunnel by default, and you only exclude local services, screen casting and intranet work apps.

Setup order

1. Connect once in global mode and confirm an IP lookup shows the node's location.
2. Turn on per-app proxy, choose allowlist mode, and tick the browser plus one app to use as a control.
3. Disconnect and reconnect, open the ticked and the unticked app, and check the IP in each.
4. Keep system settings, app stores and other apps that need the local network off the list so updates don't fail.

Protocols and clients: first confirm which protocol will run

A subscription link is just a set of node configs; whether it works depends on which protocols the client's core supports. Before choosing a client, look at what the subscription actually contains.

• Shadowsocks: lightweight, supports both TCP and UDP, simple to configure — a good starting point.
• VMess: uses time-based validation, so a large clock drift on the phone makes the handshake fail outright. If it connects but carries no traffic, sync the clock first.
• VLESS: no encryption of its own, so security comes from the outer TLS layer; low overhead, a good match for relays and dedicated lines.
• Trojan: disguises traffic as ordinary HTTPS; needs a domain and a matching certificate.
• Hysteria2 / TUIC: built on QUIC over UDP, steadier on lossy networks, but sensitive to whether the local network passes UDP.

On the client side, the Xray core covers Shadowsocks, VMess, VLESS and Trojan; Hysteria2 and TUIC need a QUIC-capable core such as sing-box. The same subscription link imported into different clients may show a different number of usable nodes — that is not the subscription's fault.

From subscription import to a verified connection: seven steps

The order below works for most Android clients, and each step says what you should see. If a step gives the wrong result, stop and troubleshoot there rather than carrying on.

1. Create an account and copy the subscription link. VPNSJ asks only for a username and password — no email address — and the link is waiting in the panel once you are done. Treat it like a password and don't forward it to anyone.
2. Install a client. Download it from the client's own release channel, not from an installer package of unknown origin.
3. Import the subscription. Paste the link into the client's subscription or profile page and update. On success the node list fills with specific regions; on failure the link is usually truncated, or local DNS can't resolve the subscription domain.
4. Choose a node and connect. For the first connection, pick a region near you. Once connected, a VPN icon appears in the status bar and the client's home screen starts showing upload and download traffic.
5. Verify the exit. Open an IP lookup page in the browser; the country and city shown should match the node you picked.
6. Verify DNS. Open a DNS leak test page; lookups should go to the DNS in your subscription profile, not to your local ISP. If they still hit the ISP, set DNS to remote resolution in the client, or turn off the system Private DNS and try again.
7. Verify per-app routing. Tick and exclude apps as described in the previous section, check the IP in each, and confirm the list is taking effect.

Stuck? Where to look first: the troubleshooting order

Work through the items below in order; most problems can be pinned to a specific layer.

• ✅ VPN icon in the status bar and the IP lookup shows the node's location: the tunnel is working, move on to per-app testing.
• ❌ Icon present but the IP hasn't changed: check whether per-app proxy excludes this browser, then whether routing rules send the target domain out directly.
• ❌ Disconnects a few minutes after the screen locks: battery optimization isn't exempted; go back to the vendor battery section and enable each item.
• ❌ Only one or two apps fail: that app may use its own network stack or make its own judgement about VPN environments — test with another app as a control.
• ❌ Client says connected but pages won't load: wrong DNS settings, or the system Private DNS is interfering. Set DNS to remote resolution first.
• ❌ Subscription update fails: the link has expired or DNS resolution is being tampered with. Connect to a working node first, then update.

Route types: dedicated lines, relays and direct connections

Same phone, same client — peak-hour performance can differ a lot, and the route type is usually why.

• Direct: the client connects straight to an overseas server. Shortest path, but it swings noticeably when cross-border public peering is congested.
• Relay: connect to an entry point first, which forwards traffic to the overseas exit. The path is controllable, and entry bandwidth sets the ceiling.
• IEPL dedicated line: runs over carrier private lines rather than the public internet exit, so it holds up better at peak hours and costs more.

There is no need to swear by one route type: direct or relay is enough for everyday browsing, and dedicated nodes are worth it where stability matters. VPNSJ currently covers 110+ countries and 150+ routes, and the node list shows the region and route type for each, so you can pick what you need.

Conclusion: how to choose on Android