The real sticking point for a first-time VPN user usually isn't “can it connect” but the handoffs between the four steps: picking the wrong plan at checkout, copying the subscription link incompletely, importing it into the client without updating nodes, or connecting and then finding pages won't open. Below, the four steps in the order they actually happen, with what you should see at each one and where to look first when you don't.
Checkout: three things to confirm first
Before you start comparing prices on your first subscription, confirm three things. Get them settled before you pay and you'll rarely have to redo anything later.
The first is coverage. The service covers 110+ countries and 250+ routes, with nodes in the regions people use most — Japan, Singapore, the United States, Hong Kong, Germany. Routes come in three types: IEPL dedicated lines, relays and direct connections. The same region often has several of them, and that's where your room to choose a route comes from later.
The second is device count. Simultaneous connections are unlimited: phone, tablet and computer can all be online together, with no second subscription needed for one more device.
The third is the refund terms. A full, no-questions refund can be requested within 30 days of your first payment — that's what caps the cost of trying the service out.
Plans are tiered by data: the monthly subscription is ¥9.9 for 60GB, ¥18 for 250GB and ¥28 for 500GB. Data resets each month on your activation date, and upgrading mid-cycle is charged pro rata for the remaining days. Data packs are ¥158/300GB, ¥358/1000GB and ¥658/3000GB — use them until they run out, they never expire, which suits lighter use. For a first run, one tier matched to your actual monthly usage is enough; there's no need to go all in.
Account and payment: just a username and a password
At sign-up the service asks only for a username and password — no email address required. One less email on file is one less entry point for credential stuffing and phishing, and no inbox to watch for a verification mail.
Let a password manager generate the password, and don't reuse it from your email or social accounts. Avoid a real name or a familiar nickname for the username — it shows up in the client and on support tickets.
Payment is accepted via Alipay, WeChat Pay and USDT. Once payment goes through, return to the account page and check three things first: plan tier, data allowance and expiry date. If all three match, go and get the subscription link; if they don't, stop there, so you don't later mistake an account issue for a route issue.
Getting the subscription link: where mistakes happen most
The subscription link is a URL the client uses to pull the node list from the server and refresh it on a set schedule. It works as your credential: anyone holding the link can spend your data allowance.
Two things matter when copying it. First, completeness — no leading or trailing spaces, and don't let a chat app wrap it onto a second line; one extra space in the middle and the pull fails. Second, secrecy — a screenshot, a post in a group chat or a support ticket all hand over the credential.
The subscription link is a credential; don't share it publicly. When describing a problem to support, give the symptoms and the error text only, not the full link. If you do need to send it to someone for troubleshooting, generate a new subscription address once you're finished.
The import isn't complicated: copy the link, open the client, find the subscription or profile entry, paste, hit update, and the node list appears. Region names and route types in the list mean the pull succeeded; an empty list means going back a step to check the link is complete.
Protocols are usually detected automatically by the client from the link contents — Shadowsocks, VMess, Trojan, VLESS, Hysteria2 and TUIC all need no manual fields. Only when adding a single node by hand do you enter the server address, port, password or UUID. If a QUIC-based protocol such as Hysteria2 or TUIC won't connect, switch back to a TCP-based protocol first to work out whether the node itself is the problem.
Client import: how the platforms differ
The same subscription takes much the same action to import on all five platforms, but the snags differ: desktop has to deal with system network permissions, mobile with system prompts and battery-saving policies, and Linux leaves DNS and routing rules to you.
| Platform | Client type | Import action | Common snags |
|---|---|---|---|
| Windows | Desktop client | Paste the subscription link, then click update manually | First run requires allowing the app network access |
| macOS | Desktop client, lives in the menu bar | Same as above, then pick a node after updating | The system network extension needs manual approval |
| Android | Mobile client | Import the subscription, then pull the node list | Battery optimisation may kill it in the background — add it to the allowlist |
| iOS | Mobile client | Import the subscription; confirm the system prompt on first connect | You must tap Allow when the “Add VPN Configuration” prompt appears |
| Linux | GUI or command-line client | Import via subscription link or config file | DNS and routing rules must be configured by hand |
Node lists change. Most clients offer a scheduled subscription update — turn it on. If nodes disappear or connections fail, update the subscription manually once before deleting and re-importing. Re-importing won't fix a problem with the route itself; it just costs you ten minutes.
Verifying the connection: five checkpoints
Connected doesn't mean working. Run the five checks below — each has a clear result, and when you're done you'll have a baseline of your own.
- Check the exit IP. Open an IP lookup page and see whether the country and region shown match the node you picked. If they don't, your traffic isn't going through the tunnel: check the routing rules rather than rushing to switch nodes.
- Open an international site. If it loads, the path is working. If it spins or throws a certificate error, check DNS and whether the system clock is accurate.
- Check for DNS leaks. Domain lookups should go through the DNS inside the tunnel. If your local carrier is still resolving them, your browsing intent is exposed and you may be sent to unsuitable addresses — which shows up as “it connects but pages won't open”.
- Confirm the routing rules. Local sites direct and international sites through the proxy is the usual setup. Rules that are too aggressive will proxy LAN devices and payment callbacks as well, and the symptom is intranet pages and local devices becoming unreachable.
- Retest at peak hours. Between 20:00 and 23:00, run the first four steps again and note whether you were on a dedicated line, a relay or a direct route, and whether the protocol was TCP- or UDP-based.
Bottom line: after these five steps you have a baseline — which node, which protocol, which hours are stable. When something goes wrong later, compare against that record; it's far faster than switching nodes on a hunch.
Troubleshooting: won't connect, connects but no internet, drops
What you'll hit most on day one isn't a total failure to connect but a set of half-working states. The table below lists where to look first for each symptom, in the order to check them.
| Symptom | Check first | What to do |
|---|---|---|
| Client says connected, but pages won't open | DNS resolution and routing rules | Send lookups to the in-tunnel DNS, or switch to global mode temporarily to test |
| Node list is empty after updating the subscription | Whether the subscription link is complete and still valid | Copy the full link again, strip leading and trailing spaces, then update |
| Some apps get online, others don't | Whether routing rules exclude by app or by domain | Bring the app into the proxied range, or compare against global mode |
| Frequent disconnects at peak hours | Route type and protocol family | Move from a relay to an IEPL dedicated line; switch UDP protocols back to TCP |
| Connects but loads very slowly | Node distance and protocol choice | Try a nearby region; on a lossy path, try Hysteria2 or TUIC |
Route type sets the ceiling on stability
In the same region, different route types behave very differently at peak hours. IEPL dedicated lines run over carrier private circuits and don't compete for public internet egress, so latency and packet loss stay steadier — good for long meetings and live streams. A relay adds one hop between entry and exit and costs less than a dedicated line, which is enough for everyday browsing. A direct route connects straight to the exit server: shortest path, but the most sensitive to your local network quality.
At the protocol level, Hysteria2 and TUIC run over QUIC/UDP and are usually steadier than TCP-based protocols on lossy paths; the trade-off is that some networks restrict UDP, which shows up as “it looks connected but no traffic flows”. When that happens, switch back to Shadowsocks, VMess, Trojan or VLESS first, then work out whether the node is at fault. Encryption is bank-grade across the service, so there's nothing to choose in the client.
Day-one habits
You don't need the client in an ideal state on day one. Get it running reliably first, then talk about tuning.
- ✅ Keep the subscription link in your password manager only — no screenshots, no group chats.
- ✅ Turn on the client's scheduled subscription update, and update manually once if the node list looks wrong.
- ✅ Run the default routing rules for a week, note which sites need special handling, and only then start editing.
- ✅ Connect once on each device you use, to confirm the unlimited simultaneous connections really apply.
- ❌ Don't log into the account panel and change your password on public Wi-Fi unless the tunnel is already up.
- ❌ Don't switch nodes and protocols ten times a day — too many variables, and you won't find the cause when something breaks.
Bottom line: choosing a plan, getting the subscription, importing it into a client and verifying the connection can all be done in half an hour; the time really goes into tuning for your own network afterwards. Within the 30-day money-back window, test your usual hours and usual devices before making a long-term decision.