VPN for Beginners: 10 Questions, Answered

The ten questions VPN beginners ask most cluster around the same few points: multiple devices at once, how data is counted, whether you get throttled, and whether to leave it running all the time. They are ordered below by how often they come up and answered in one pass, with a step-by-step order for starting from zero at the end. Where possible the answers give you criteria to judge by rather than adjectives.

Devices, data and throttling: four questions we hear most often

How many devices can use one account at the same time?

As many as you like. The same subscription can be imported onto several devices — desktop, phone and tablet can all be online at once with no extra charge and no separate account for each one. The real limit isn't the device count but the bandwidth of the route you pick: put a few devices on one route at full tilt and it will feel noticeably worse.

With several devices, a more practical approach is to split routes by purpose — one for meetings and work, another for downloads and streaming — instead of piling every device onto the same one. Switching costs little: one tap in the client.

How is data counted, and what happens when it runs out?

There are two billing models with different rules, so work out which one you're on before you order:

• Monthly subscription: ¥9.9/month for 60GB, ¥18/month for 250GB, ¥28/month for 500GB. Data resets every month on the activation date; if you upgrade mid-cycle, the difference is prorated across the remaining days.
• Data packs: ¥158 for 300GB, ¥358 for 1000GB, ¥658 for 3000GB. Use them until they run out — they never expire and don't reset with the month.

The test is simple: if your monthly usage stays under 60GB, the monthly subscription works out cheaper; if usage swings wildly, or you only need it for a few weeks a year, a data pack fits better — whatever you don't use doesn't vanish at month end.

Will I be throttled?

First work out where the slowness comes from. There are usually three bottlenecks: congestion on the international direction of your local broadband at peak hours, the user density on the route you picked, and how the protocol behaves on a weak network — when UDP is QoS'd, QUIC-based protocols drop off sharply.

The test is plain: at the same time of day, switch to a route in a different region and measure again. If only one route is slow, it's the route; if every route is slow at once, it's most likely your local connection; if things recover after a protocol switch, the protocol doesn't match your network. Keep the tool, the time window and the target fixed when you test, or the numbers aren't comparable.

Should I leave it running all the time?

It depends on the setting — there's no blanket answer. On public Wi-Fi, hotel networks or when working across borders, leaving it on is sensible, because the risk comes from the network itself. On a fixed home broadband line, turning it on only when you use international services is enough.

Leaving it on permanently on mobile costs you two things: battery, and a reconnect gap when you move between Wi-Fi and cellular. If you really do need it always on, set up split routing so local apps connect directly and only apps that need international routes go through the proxy — that saves battery and causes fewer problems than a global proxy.

Accounts, subscriptions and clients: what to sort out before installing

What do I need to fill in to create an account?

A username and a password. There's no email verification step in the flow, and no email address required. One less field is one less surface to leak: an email address is usually the way credential-stuffing, account recovery and marketing mail get in, so leaving it out removes a whole category of hassle. Once you're set up, the subscription entry point is right there in the dashboard.

What is a subscription link, and how do I import it?

A subscription link is a URL that the client fetches periodically to get the node list, ports, protocols and encryption parameters. It works like account credentials: anyone who has the link can burn through your data. The transport layer is protected with quantum encryption, but the link itself is a plaintext credential — don't paste it into public groups or send screenshots of it; if you suspect it has leaked, reset the subscription in the dashboard.

Importing works much the same on every platform: copy the subscription link → open the client → find “Subscriptions / Profiles” → import from clipboard → select the profile you just fetched → update it manually once. Desktop clients usually offer two ways to take over traffic: system proxy, which only covers apps that respect the system proxy, and TUN, which takes over all traffic. If you need per-app routing, TUN is less trouble.

How do the clients differ between systems?

Desktop (Windows, macOS) is the most capable: TUN, split-routing rules, different routes per domain. Android is usually installed from a package and supports per-app proxying. iOS is limited by the system — you can only install clients that support subscription import from the App Store, and per-app control is weaker, usually achieved through rule files. Linux is mostly a command-line core plus a config file with no GUI, which suits a router or an always-on machine.

The same subscription link can be imported into all of these clients at once; there's no need to buy separately for each platform.

Protocols and routes: which to pick, what to run

With so many protocols, which one do I actually choose?

Newer isn't automatically better — it depends on your network. The table below lists the common ones by transport and typical use:

Order of selection: first check whether the network allows UDP — if not, rule out Hysteria2 and TUIC; then decide whether you need disguise, where Trojan and VLESS with TLS are steadier; finally check client compatibility, where Shadowsocks and VMess are the least trouble on older devices.

Hong Kong, the US or Japan — which region should I pick?

Pick by where the service you're reaching is, not by “which one is fastest”. If the service is hosted in the US, land in the US; services aimed at Japan or Korea go through Tokyo; if you're only looking things up and reading docs, Hong Kong and Singapore usually have lower round-trip latency.

Route type matters just as much — the three differ in path:

• Direct: the client connects straight to the overseas server over the public internet, so it's the most exposed to international gateway congestion at peak hours.
• Relay: you connect to a domestic relay entry point first, which forwards to the landing server — a more controllable path, and cheaper than a dedicated line.
• IEPL dedicated line: runs over the carrier's international private line and skips the public gateway, giving the steadiest latency and packet loss — suited to jitter-sensitive work such as meetings and real-time collaboration.

With 100+ countries and 250+ routes to choose from, don't chase “the single best route” — grouping by purpose is more practical: one for meetings, one for downloads, one for everyday browsing, so you know which to switch first when something goes wrong.

Do I need to worry about DNS leaks?

Yes — and they're easy to check. If your traffic goes through the proxy but DNS queries still go to your local ISP, two things follow: resolution may be steered to a location that isn't the right one, and the domains you visit are exposed at the resolution layer.

How to check: connect to a route, open any DNS leak test page, and see whether the resolver locations it lists match the route you selected. If they don't, resolution is still happening locally. The fix is to enable remote DNS in the client (sometimes called proxy DNS) and confirm that your routing rules send DNS queries through the proxy rather than direct; check again afterwards — it's only set up properly once the locations match.

Refunds, payment and three easy-to-confuse points

30-day money-back guarantee, counted from the day of purchase, no reason required. Payment supports Alipay, WeChat and USDT. Both are transaction-level details unrelated to route quality, but they tend to get asked together before ordering.

• Data packs and monthly subscriptions are not the same billing model: the former last until used up and never expire; the latter reset every month on the activation date, and unused data doesn't carry over.
• Unlimited devices refers to device count, not bandwidth: the more devices crowd onto one route, the less each of them gets.
• No email address refers to the account flow: it describes the form-filling step and nothing beyond it.

The setup order from zero

Here are the ten questions folded into a single path — work through it in order and you're unlikely to get stuck:

1. Create an account: username + password, no email address needed.
2. Choose a billing model: if your monthly usage stays under 60GB, take the ¥9.9 monthly subscription; if usage swings, take a data pack.
3. Import the subscription: copy the subscription link, import it from the clipboard in your client, and update the profile once manually.
4. Connect to a nearby landing first: pick by the region where your target service lives, not the flashiest entry in the list.
5. Verify: same tool, same time window, and look at latency, jitter and throughput — not a single result.
6. Set up split routing: local apps connect directly, apps that need international routes go through the proxy.
7. Troubleshoot: when something breaks, try “switch route → switch protocol → switch DNS settings”, changing one variable at a time.

• ✅ Confirm which region your target service is in before choosing a landing, rather than picking by list order.
• ✅ Treat the subscription link like a password; if you suspect a leak, reset it in the dashboard.
• ✅ Turn on remote DNS in the client, then re-check the resolver location once you've changed it.
• ✅ When several devices are online at once, assign routes by purpose instead of crowding them onto one.
• ❌ Don't judge a whole route by a single speed test — peak hours and the small hours can differ a lot.
• ❌ Don't keep hammering QUIC-based protocols on a network where UDP is blocked; switching to a TCP-based one solves it faster.

Ten questions answered, and the real hurdle is only two steps: importing the subscription into your client correctly, and getting DNS and split routing to match. Everything else can be tuned as you go — no need to get it perfect first time.