When you're starting out with a VPN, the setup steps are usually the easy part — the vocabulary is what trips people up. Subscription link, node, protocol, and routing each answer a different question: where the node list comes from, which machine you're connecting to, how your data is packaged, and which traffic goes through the tunnel. Once you can tell them apart, every other guide becomes much easier to follow.
Here's the order we'll follow: get a subscription → pick a node → check the protocol → set up routing. Each term gets a plain definition first, then what it actually changes in daily use, and a checklist you can work through at the end.
Subscription link: a server list that updates itself
A subscription link is usually an https address. Your client sends one request to it and gets back a node list — in the early days this was mostly Base64-encoded plain text with one node share link per line; clients like Clash and sing-box return YAML or JSON configs instead. Once the client parses it, your node list appears.
The difference from adding nodes manually comes down to how updates work. Manual entry means copying and pasting one node at a time — when the provider swaps servers, you have to paste them all over again. With a subscription you import once, then hit Update subscription and the list follows whatever changes on the server side. Once you're dealing with more than a handful of nodes, a subscription is really the only practical option.
# A subscription response looks roughly like this (excerpt; the client parses it automatically)
ss://[email protected]:8388#Tokyo-01
trojan://[email protected]:443?sni=node.example.com#Singapore-02
Where you import it varies by client — it's usually tucked under an entry called Subscription, Config, or Profile. Paste the link, save, and update. The same subscription can be imported on multiple devices, so you don't need a separate one for each.
A subscription link is itself a credential. Anyone who has it can pull your full node list, so don't post it in public groups, don't leave it visible in screenshots, and blur it out before you share anything.
If updating the subscription fails, check three things first: whether the link is still within its validity period, whether your current network can open that address, and whether your system clock is accurate. Some protocols are sensitive to clock drift — if the time is off by much, they simply won't connect.
Nodes and route types: how dedicated, relay, and direct lines differ
A node is a single entry in that list, usually written as region · city plus route type. What you're picking isn't an abstract country but a specific server. The region decides where you appear to be when you visit international sites — want Japanese streaming? Pick a Japan node. The route type decides how smooth the path is, and it's completely independent of the region.
There are three common route types, and they differ in the path your data takes from the client to the overseas exit:
- Direct: the client connects straight to the overseas server, and the cross-border leg runs over public international gateways. Cheap, but during peak evening hours it's affected by overall congestion and speeds swing noticeably.
- Relay: you first connect to a relay server inside mainland China, which forwards traffic to the overseas exit. That's one extra hop, but the local leg runs on an optimized route, so it's steadier than direct.
- IEPL dedicated line: from the client all the way to the overseas exit, traffic runs on a carrier's international private line and never touches public gateways. Latency is more stable, peak-hour jitter is small, and it costs the most — usually reserved for stability-sensitive work like video meetings and live streaming.
| Route type | How data travels | Peak-hour performance | Best for |
|---|---|---|---|
| IEPL dedicated line | Client → dedicated entry → overseas exit, all on an international private line | Most stable | Video meetings, live streaming, long always-on sessions |
| Relay | Client → relay in mainland China → overseas exit; the local leg uses an optimized route | Fairly stable, depends on relay bandwidth | Everyday browsing, streaming |
| Direct | Client connects directly to the overseas server; the cross-border leg uses public gateways | Noticeable fluctuation | Quick lookups, backup routes |
When choosing a node, look at the region first, then the route type, and only then the name. A single city often has several routes — if a dedicated line won't connect, switching to a relay in the same city tells you more about where the problem is than jumping to another country.
Protocols: how to choose between Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC
A protocol is the packaging both sides agree on: how the handshake works, how encryption is layered on, and what the traffic looks like to devices in between. There are plenty of names, but you rarely have to choose one yourself — every node in a subscription already comes with its protocol and parameters attached, so picking a node matters more than picking a protocol. The terms below are worth recognizing, nothing more.
- Shadowsocks: the earliest and most widely supported family, with lightweight configuration; its AEAD ciphers are usually aes-256-gcm and chacha20-ietf-poly1305. Router plugins and older devices support it best.
- VMess: V2Ray's early workhorse protocol; the handshake relies on a user ID and extra verification fields, and a large clock difference between client and server will stop it from connecting at all.
- VLESS: VMess's lightweight successor. The protocol itself doesn't encrypt anything and is usually paired with TLS, which keeps overhead low.
- Trojan: disguises traffic as ordinary HTTPS requests on port 443; simple to configure and broadly compatible.
- Hysteria2 / TUIC: newer protocols built on QUIC (UDP) that perform better on long-distance links with heavy packet loss. The trade-off is more aggressive transmission, and some networks handle UDP poorly.
The clock is a hidden trap. If a VMess node is the only one that won't connect while others work fine, check that your device time is set to sync automatically — being a few minutes off can be enough to break the handshake.
Routing modes: global, rule, and direct
Routing answers the question of which traffic goes through the tunnel. Most clients offer three modes:
- Global: all traffic goes through the node. It's the simplest setup, but traffic to sites in mainland China also takes the detour, which can actually make them slower.
- Rule: decisions come from a rule set — domains and IPs in mainland China connect directly, while everything on the list goes through a node. It's the least fuss day to day and the mode most people should use.
- Direct: nothing goes through a node, which is effectively the same as turning acceleration off. Use it mainly for troubleshooting.
Rule sets usually decide based on three things: domain suffixes, IP ranges (what people call GeoIP), and process names — some clients support per-app routing, so you can send only your browser through a node while download tools stay on the local network.
Rule mode isn't magic. A new domain that isn't in the list may go direct, which shows up as everything works except this one site. Switch to global mode and try again: if it loads, the rule set simply didn't cover it; if it still doesn't, then it's time to change nodes.
Quick rule of thumb: won't load — switch to global first; slow — change the route type first; won't connect — change the city first. Three actions for three kinds of problems, so don't start by reinstalling the client.
How the client differs across five platforms
The same subscription doesn't behave identically on every system — the differences come mainly from how each OS lets a client take over traffic:
- Windows: most clients offer two ways to take over traffic — system proxy and TUN. A system proxy only affects programs that respect proxy settings; TUN creates a virtual network adapter and captures programs that don't.
- macOS: works through a system network extension, so the first install asks for permission and nothing connects until you allow it. On M-series chips the native build is easier on battery.
- iOS: only works through a system VPN profile, and it may reconnect when you switch apps or lock the screen. Fine for browsing and streaming, not for long, heavy downloads.
- Android: supports per-app routing, so you can send only selected apps through the tunnel.
- Linux: mostly command-line clients, well suited to servers and routers where there's no graphical interface.
One subscription works on any of the devices above, with no limit on simultaneous connections — you never need to buy a second one just to add a device.
Beginner FAQ quick reference
The items below cover the situations beginners run into most. Work through them in order and you can usually pin down which step is failing.
- ✅ After importing a subscription, hit Update subscription once and make sure the node list isn't empty before worrying about connecting.
- ✅ Once connected, open an international website to confirm it's really working — don't just trust the Connected label in the client.
- ✅ If a site won't load, switch to global mode once to tell whether the problem is the rules or the route.
- ✅ Change one variable at a time: switch the city first, then the route type, so you know which one made the difference.
- ❌ Don't post your subscription link in public groups or forums, or leave it in screenshots — it works like your account credentials.
- ❌ Don't keep reinstalling the client without updating your subscription first — the node list hasn't changed, and a reinstall won't fix a connection problem.
Each term covers one stage: the subscription answers where nodes come from, the node decides which path you take, the protocol decides how data is packaged, and routing decides which traffic goes through. Figure out which stage is failing before you touch the matching setting.
Once these four terms make sense, every other setup guide gets much easier to follow. If you just want to get online once, remember the shortest path: import the subscription → update the list → pick a dedicated-line node in a nearby city → rule mode → open a website to verify.