Installing an app on Android takes a couple of minutes. What actually trips newcomers up is everything after that: system prompts nobody recognises, the client getting killed by battery optimisation, and a connection that looks up while DNS still resolves locally. This Android VPN guide splits the process into five steps, each with the exact settings path and a checkpoint you can compare against.
Android has shipped the VpnService interface since 4.0. A third-party client uses it to create a virtual network adapter inside the system: packets sent by apps are intercepted there first, and the client then decides, according to its rules, whether to push them into the encrypted tunnel or hand them straight to the local network. Once that layer makes sense, every prompt and toggle further down has an explanation. The system needs to know who is taking over traffic, so you have to grant it yourself — and after reinstalling an app you will usually be asked to confirm again.
Compared with desktop, two Android-specific differences are worth remembering. First, only one VPN app can be active at a time: run two clients and the second displaces the first, which shows up as a connection that "randomly" drops. Second, the system manages background processes far more aggressively — the UI may still say connected while the underlying connection has already been reclaimed. The first affects installation and coexistence, the second affects keep-alive; later sections deal with each.
The protocol a client and a route use to talk to each other determines the handshake and how sensitive the connection is to the surrounding network. The table below lists the common ones on Android; when a node won't connect, check the symptoms against it first instead of blindly switching nodes.
| Protocol | Transport characteristics | Android notes |
|---|---|---|
| Shadowsocks | Lightweight forwarding over TCP / UDP | The cipher must match the list the client supports |
| VMess | Carries a user ID; time is checked during the handshake | A large clock skew makes the handshake fail outright |
| VLESS | No encryption of its own; relies on the outer transport | Usually paired with TLS or Reality |
| Trojan | Disguised as ordinary HTTPS traffic | A wrong SNI or password shows up as a connection timeout |
| Hysteria2 / TUIC | QUIC-based, runs over UDP | Some networks restrict UDP; keep a fallback route |
Every route on this service uses military-grade encryption; the protocol you pick in the client affects the handshake, the transport characteristics and, on some networks, whether the connection gets through at all. Don't confuse the two: encryption is guaranteed by the service, while the protocol only decides how you connect.
There aren't many parameters that actually matter when picking a route. These are the figures this service publishes, and you can check them directly:
120+
Countries / regions covered
240+
Total routes
Unlimited
Simultaneous devices
14 days
No-questions-asked refund
There's no cap on devices, so a tablet, a spare phone and an old handset can all share one account — no need to buy a second plan just to add one more device. The refund terms leave room to experiment: get one device working with the steps below, then decide whether to roll it out.
Get the Android client from the download page on this site; you'll need to sign in first. The page doesn't offer a static direct link to the installer — what you get after signing in is the build and subscription information tied to your account. During installation Android may warn about apps from unknown sources; that's the normal sideloading prompt, so just let the current file manager finish the install.
Don't rush to hit Connect once it's installed. Android shows a system-level authorisation dialog the first time you connect, so setting up the subscription beforehand saves you one round trip.
A subscription link is an address starting with https that the client polls periodically to pull the node list. When routes are added or removed on the server, one tap on "Update subscription" in the client fetches the new list — no adding nodes by hand one at a time. That's the biggest difference between a subscription-based client and manual configuration.
Some clients also let you enter the server address, port, password and protocol parameters by hand. The upside is independence from the subscription service; the downside is that whenever routes change on the server you have to edit each one yourself. Unless your client can't import subscriptions, prefer the subscription: less work, and far fewer chances to mistype a parameter.
The first time you tap Connect, the system shows a "Connection request" dialog listing the client's name and the scope it will take over. That dialog doesn't come from the client — Android is checking on your behalf. You have to tick "I trust this application" and then tap OK before the connection is established. Tap Cancel and the client sits on "Connecting" indefinitely, and the prompt may not reappear next time.
Most Android clients support per-app proxying: only the apps you tick go through the tunnel, everything else connects directly. Set banking apps, the corporate intranet and local services to direct so they don't trip risk controls when the exit region changes, and tick the apps that need an international route separately. These rules live on the device — they don't sync to a new phone, so you'll set them up again.
Android's battery policies restrict background networking once the screen goes off, which cuts long-lived connections. The symptom: lock the phone for ten minutes, pick it up, the client still says "Connected" but no web page loads — and only a manual disconnect and reconnect fixes it. That isn't a route quality problem; the system has taken the process's network access away.
Once these are done, turn the screen off for a few minutes and come back: check whether the client is still connected and whether pages open straight away. If traffic still stalls, try another route — some networks reclaim UDP sessions that sit idle too long, and QUIC-based protocols are hit harder than TCP-based ones.
"Connected" only means the client thinks it's connected; it doesn't prove traffic is actually leaving through the route. Run the four checks below in order — they cover the vast majority of "connected but unusable" cases.
Open any IP lookup page in the phone's browser and look at two things: whether the address shown belongs to the region of the route you picked, and whether the carrier or ASN matches the route type. If it still shows a local address, traffic isn't entering the tunnel — go back a section and check permissions and split-tunneling rules.
Open a DNS leak test page; it lists the DNS servers currently in effect. Ideally those servers sit near the route's exit rather than at your local carrier. If local DNS servers still show up, check in order: whether Private DNS is pinned to a fixed hostname, whether the client's DNS mode is set to remote resolution, and whether "bypass LAN" was switched on by mistake.
Turn on airplane mode, wait ten seconds, turn it off and watch whether the client recovers on its own. If it does, your keep-alive settings are working; if you have to tap Connect manually, the background is still being restricted — go back and finish the whitelist.
Open one app set to direct and one that goes through the tunnel, and look up the exit address in each — they should differ. If both show the same address, the split-tunneling rules aren't taking effect; check whether global mode is on.
The table below is organised as symptom → likely cause → fix. Check it first when something goes wrong. Most cases don't need a different route — one toggle is simply out of line.
| Symptom | Likely cause | Fix |
|---|---|---|
| Spinner keeps turning after tapping Connect, no system dialog | Cancel was tapped earlier, so permission was never granted | Disconnect and reconnect, then tick trust in the system dialog and confirm |
| Shows connected, but pages won't load | DNS isn't going through the tunnel, or Private DNS pins a hostname | Set Private DNS to Automatic and run a leak test after reconnecting |
| Traffic stalls a few minutes after the screen locks | Battery policy cut off background networking | Set battery optimization to Don't optimize and enable the vendor ROM's autostart |
| A few apps don't use the route | They aren't ticked in the per-app proxy list | Tick that app individually in the split-tunneling settings |
| Nodes don't change after updating the subscription | The client is using a cached list | Trigger an update manually, or delete the subscription and import it again |
| Handshake fails on several routes in a row | The device clock is too far off the server's | Set the system time to sync automatically and try again |
If you've tried everything in the table and still can't connect, check whether the same account works on desktop. Desktop fine and Android not: the problem is almost certainly in the phone's system settings. Both failing: the route or the account itself is the issue.