Using a VPN on Android comes down to a four-step chain: install the client → import the subscription link → approve the system VPN prompt → add the client to the battery whitelist. Skip any one of the four and the symptoms look almost identical — the client says “Connected” but pages won't load, or the connection drops on its own after ten-odd seconds. Below we take each step in order: where to tap in that system dialog on first connect, why a subscription link should never be forwarded, whether a dropped connection is the node's fault or the system's, and how to confirm with your exit IP that traffic is really going through the route. None of it requires root, and you won't need to modify any system files.
Before Installing: Gather Three Things First
There's no shortcut that makes Android work the moment you install it. Preparation comes down to three items, but missing one will stall you halfway:
- A complete, working subscription link. It isn't a node password — it's the address the client uses to pull the node list and routing rules. Copy it from the panel; it looks like
https://…/summit-web/client/subscribe?token=…. The link is equivalent to your account credentials, so forwarding it to someone else is the same as sharing your account. If you suspect it has leaked, reset it once in the panel and the old link stops working immediately. - An Android 7.0 or newer device. Android 10 and above also supports per-app proxy, so you can route only chosen apps through the connection; earlier versions have no such switch and can only proxy everything.
- About ten minutes, and one tap in a system dialog. On first connect, Android forces a VPN authorization dialog. That's system behavior — no client can get around it.
Your Account and Your Client Are Two Different Things
Signing up for VPNDX doesn't require an email address. Once you have an account, copy the subscription link straight from the panel and import it into your Android client. Client and subscription are independent: the client builds the connection, the subscription tells it where to connect and how to route traffic. Switching clients doesn't mean switching subscriptions, and updating a subscription doesn't mean reinstalling the client. That's why the first troubleshooting step is always to check whether the subscription updated successfully — not to reinstall the app.
Get the client only from the download page in the panel. Installers from forum attachments, cloud-drive shares, or group chat files have no verifiable packager — don't install an APK of unknown origin on a device you use every day.
Import the Subscription: Five Steps to Your First Connection
From zero to your first connection takes five actions. Don't skip around:
- Install the client. Download the Android package from the panel's download page. On first install you'll need to allow “install from unknown sources” in system settings. Once it's installed, don't rush to tap Connect.
- Find the subscription entry. Open the client, go to the “Subscription” or “Profiles” page, and choose “Add subscription.” If the link is already on your clipboard, most clients will offer “Import from clipboard” right away.
- Paste the link and save. Name it after its purpose, e.g. “Daily-Hong Kong.” The link is one long line — when copying, don't lose the token parameter at the end. A single missing character will make the fetch fail.
- Update the subscription once, manually. After saving, tap “Update” and the client will pull the node list and routing rules. On success you'll see the update time and node count; on failure you'll usually get “subscription parse failed” or “network error.”
- Pick a node and connect. Choose a region from the list and tap connect. Android will show a “VPN connection request” — confirm it with “OK” and a VPN icon appears in the status bar.
Subscription name: VPNDX
Subscription URL: https://…/summit-web/client/subscribe?token=…
Auto-update: every 24 hours
Routing rules: updated with the subscription
Updating the subscription is the step most often overlooked. The client stores the node list from its last fetch; when the panel adds or adjusts routes, the client has no way of knowing. Tap “Update subscription” once and the list refreshes. Most clients let you set an auto-update interval — 24 hours is common — but tapping it manually before you head out is safer.
The subscription link is a read endpoint: anyone who has it can pull the same node list you get. Don't post it in public comment sections, tutorial screenshots, or group chats.
System Authorization and Background Keep-Alive: Will Your Connection Drop?
Once the connection is up, Android's background management is the real test. The system limits background network and CPU use by default; when battery policy kicks in and the VPN service gets reclaimed, the symptom is “it suddenly stopped working while the client still says Connected.”
The Authorization Dialog: Your Only Option Is “OK”
The “VPN connection request” on first connect is Android's system-level authorization, not an interface the client drew itself. Tapping “Cancel” won't throw an error — the client just sits at “Connecting,” and the next tap brings the dialog back. Authorization stays valid until you uninstall the client or clear its app data.
Battery Whitelist: Set It Once, It Lasts
- ✅ System VPN authorization granted; VPN icon visible in the status bar
- ✅ Client battery policy set to “Unrestricted” (Settings → Apps → Battery)
- ✅ Notification permission granted; on Android 13 and above this keeps the persistent status notice alive
- ✅ The system's own “Smart battery” / “Deep sleep” auto-management is turned off for this app
- ❌ Don't use “one-tap boost” tools to clean background apps — they'll kill the VPN service too
- ❌ Don't run a second VPN-type client at the same time; Android allows only one VPN service at a time
Per-app proxy is an Android 10 and above feature. Turn it on and you can route only your browser and meeting apps through the connection while banking, delivery, and map apps stay on the local network. Two benefits: unrelated apps don't reconnect when the route switches, and local apps aren't slowed down by the route. The switch usually lives under “Settings → Per-app proxy” in the client; some clients also let you limit the app scope in Android's system VPN settings.
Verify It's Working: Three Checks
“Connected” is the client's status — it doesn't mean traffic is actually going through the route. Confirm with the three steps below; each one reaches a conclusion on its own:
- Check the exit IP. Open the site's My IP page and note the exit IP and region shown. Disconnect, refresh, and compare — the two results must differ. If they're the same, your traffic never went through the route.
- Check DNS. The same page shows where DNS resolution comes from. If the exit IP is already overseas but DNS still points to your local network provider, that's a DNS leak. The classic symptom: the homepage loads but images and video don't.
- Test per-app routing. In per-app proxy, tick only the browser, then open the browser and an unticked app side by side. Confirm that only the ticked app goes through the route.
Pass all three before you settle into daily use. Working backwards, troubleshoot in the same order: authorization → whitelist → exit IP → node. It's far more effective than swapping nodes over and over.
Choosing a Node: How the Three Route Types Differ
The node list often has several entries for the same city; the difference is the type of route carrying them. Understanding the three types saves you a lot of trial and error over “why is it so slow at peak hours.”
| Route type | How data travels | Peak-hour behavior | Best for |
|---|---|---|---|
| IEPL dedicated line | Runs over a dedicated cross-border channel, away from shared public international gateways | Low jitter, stable speed | Video meetings, long always-on sessions |
| Relay route | Connects first to a relay server in mainland China, which then carries traffic abroad | Moderate; depends on relay load | Everyday browsing, short videos |
| Direct route | The client connects straight to an overseas node | Noticeably affected by international gateway fluctuations | Occasional use, backup nodes |
Keep your node-picking order fixed: filter by region first — pick the region that serves the service you need; then within that region prefer dedicated lines; only then compare latency numbers. The latency shown in the client is a live probe value and will change at peak hours, so there's no need to switch back and forth over a few milliseconds.
Routing rules decide which traffic goes through the route and which connects directly, and they update along with the subscription. The usual approach judges by domain and IP ownership: domestic sites connect directly, overseas sites go through the route. If a site gets misjudged, add a custom rule for it in the client, or temporarily switch to global mode to check whether the rule is the culprit. Remember to switch back to rule mode afterwards — global mode sends all traffic the long way and slows down local apps too.
Common Errors: Symptom, Cause, Fix
The errors you'll hit on Android cluster into a few groups. Match the symptom, locate the layer, then change settings:
| Symptom | Common cause | Fix |
|---|---|---|
| Tapping connect does nothing; no icon in the status bar | System VPN authorization was denied | Tap connect again and choose “OK” in the dialog |
| Disconnects by itself ten-odd seconds after connecting | Battery policy reclaimed the background service | Set the client's battery policy to “Unrestricted” and turn off smart battery saving |
| Node list is empty in the client | Subscription didn't update, or the link was copied incompletely | Paste the full link again and tap “Update subscription” manually |
| Shows Connected, but the browser can't open pages | Routing rules classified the browser as direct, or DNS isn't resolving through the route | Check whether the browser is ticked in per-app proxy; compare with global mode |
| Only some apps go through the route | Per-app proxy has only some apps ticked | Tick the rest as needed, or switch to global mode |
| Slow speeds, video stutters | Node is under heavy load, or you picked a direct route | Try other nodes in the same region, preferring IEPL dedicated lines |
Keep the troubleshooting order fixed: confirm system authorization first, then check the battery whitelist, then the exit IP, and only then touch the node. The first three are “set once, lasts” items; only the node is something you'll adjust repeatedly. Reverse the order and you'll spend the whole evening swapping nodes while the problem sits in the system layer.
Setup Habits That Keep Working Long-Term
- Keep only one subscription in the client, so multiple profiles don't overwrite each other or mix up node lists.
- Set subscription auto-update to 24 hours, and tap update manually before a long trip.
- In per-app proxy, tick only the apps that truly need the route — fewer unnecessary reconnects.
- When something breaks, run the three checks first instead of uninstalling and reinstalling — a reinstall wipes authorization and the whitelist, undoing all the setup you already did.
Bottom line: the full Android chain is just four steps — install the client, import the subscription, approve the system prompt, add it to the battery whitelist. The first two decide whether you connect; the last two decide whether you stay connected. Lock those four in and daily use comes down to switching nodes by region. Skip any one of them, and the symptom is always the same: “it says connected, but nothing works.”