VPN Glossary: Nodes, Routes, Protocols and Split Tunneling Explained
One comparison table and a few short sections to untangle the words beginners mix up most — subscription, node, route type, protocol, split tunneling, global and rule mode — so the guides read smoothly the second time round.
The terms beginners mix up most are subscription, node, route, protocol and split tunneling, and they don't sit on the same level. A subscription is how you get the configuration; a node is the server you land on; a route is the path the data travels; a protocol is the format the two ends speak; split tunneling decides which traffic takes the route and which stays local. Put those five in the right order and the options in your client stop looking like noise. Below is a comparison table first, then each term on its own.
Start with a comparison table
The table below puts each term next to a one-line explanation and the mix-up it causes most often. You don't need to memorise it on the first pass — every section further down comes back to one of these rows.
| Term | In one line | Where it gets confused |
|---|---|---|
| Subscription link | A single URL the client pulls the node list and settings from | It isn't a node: import the same link on another device and you get the same set of nodes |
| Node | A connectable server entry, defined by address, port and credentials | Node count isn't route count — the same node can be reached over several paths |
| Route | The network path data takes from your device to the node | Route quality is about the path, not how long the node list is |
| Route type | How the path is classified: direct, relay, IEPL dedicated line | A dedicated line describes the link, not the protocol |
| Protocol | The rules for how the client and the node wrap data | Protocol and route are independent and can be combined freely |
| Split tunneling | Decides by domain, IP or app which traffic goes through the node | Split tunneling isn't about speeding up only part of your traffic — it keeps traffic that shouldn't take the route local |
| Global mode | All traffic goes through the node | LAN devices, screen casting and printers may become unreachable |
| Rule mode | Matches the split-tunneling rule list line by line and stops at the first hit | The rule list comes from the provider or the client; overly broad rules slow down local sites |
| DNS leak | Traffic goes through the node, but domain lookups are still resolved by the local network | A page loading doesn't mean lookups aren't leaking |
Subscriptions and subscription links
A subscription is a configuration list the provider hands to the client. It doesn't encrypt traffic itself — it only delivers node information to the client. Once that clicks, most of the steps below fall into place.
What's inside a subscription link
A subscription link is usually one URL; the client requests it and receives an encoded node list. Each entry in that list carries a server address, port, encryption method, transport parameters and credentials. After import, the client renders those entries as a clickable node list. The link itself is not a node: import the same link on another device and you see the same set of nodes.
How often it updates
When the provider adds or removes nodes and adjusts routes, the list changes with them. Clients generally offer a manual update, and many can also refresh on launch or on a fixed schedule. If the regions in your list don't match what the dashboard shows, update the subscription manually first and only then start troubleshooting the network — it saves half the wasted effort.
What to do if the link leaks
A subscription link is as good as an account credential: anyone who has it can import the same configuration. If a link turns up in a screenshot, a group chat or a public repository, revoke it and generate a new one. Most clients keep several subscriptions side by side, so add the new link and delete the old one.
When you share a client screenshot, make sure the subscription link, node addresses and credentials aren't in frame. Once a link is out, regenerating it is faster than tracing where it leaked.
Nodes, routes and route types
Nodes and routes get used as synonyms, but one is a point and the other is a line.
A node is an entry point
A node is a server you can connect to, defined by its address, port and credentials. Once the client connects, the exit address is decided by the node — which is exactly why a region list exists: choosing a region means choosing where you come out.
A route is a path
A route is the network path data takes from your device to the node. The same node can be reached over different paths. The path determines how steady latency and packet loss are; the length of the node list does not.
Direct, relay and IEPL dedicated lines
- Direct: your local network connects straight to the node — the shortest path, with the cross-border leg running over the public internet. Fine for everyday pages and documents; peak-hour jitter is more noticeable.
- Relay: you connect to a relay entry point first, which forwards to the exit node. The relay leg can be optimised separately, while the exit node decides the region you appear in.
- IEPL dedicated line: an international Ethernet private line from a carrier. The cross-border leg avoids congested public peering points, so latency and packet loss are steadier — and the cost is higher.
Worth stressing: a dedicated line is a link type, not a protocol. Trojan or VLESS run over a dedicated line just as they do over a direct connection. Mixing the two up leads straight to wrong conclusions such as “a dedicated line is a protocol”.
110+
Countries / regions
160+
Route
Unlimited
Simultaneous devices
14 days
No-questions-asked refund
With VPNUJ, for example, coverage currently stands at 110+ countries / regions and 160+ routes, with unlimited simultaneous devices and a 14-day no-questions-asked refund. Which route types serve which regions is listed line by line in the route list.
Protocols: how the two ends talk
A protocol is the wrapping rule between client and node. It's independent of the route: the same dedicated line can carry different protocols, and the same protocol can run over a direct or relay path. The common families differ mainly in transport base and the environments they suit.
| Protocol | Transport base | Key traits | Best suited to |
|---|---|---|---|
| Shadowsocks | TCP / UDP; an encrypted proxy built on SOCKS5 | Light configuration, low overhead, limited obfuscation in the original | Everyday browsing, documents and video |
| VMess | TCP, can be paired with WebSocket and other transports | Full-featured, authenticates by user ID, sensitive to clock drift between client and server | Setups that need fine-grained transport options and multi-user management |
| VLESS | Relies on TLS, often paired with XTLS | Lean structure, no built-in encryption, cheap handshake | Where a TLS entry point already exists and low overhead matters |
| Trojan | TLS; looks like standard HTTPS | Good camouflage, with clear requirements for ports and certificates | Where it has to coexist with ordinary HTTPS traffic |
| Hysteria2 | QUIC, over UDP | Aggressive congestion control; steadier on weak or lossy networks | Mobile networks, long cross-border hops, lossy routes |
| TUIC | QUIC, over UDP | Multiplexing, fast connection setup, sensitive to UDP quality | Many short connections that need fast reuse |
No protocol is fastest on every network. Judge in this order: how well your local network tolerates UDP, then whether you need a TLS appearance, then whether your client supports it. On networks that throttle UDP, QUIC-based protocols degrade; in environments that check clocks, VMess needs the system time calibrated first, or you get “the config is right but it won't connect”.
Split tunneling, global and rule mode
Clients usually offer three modes: global, rule (split tunneling) and direct. They don't decide whether you can connect — they decide which traffic takes the node.
- Global: all traffic goes through the node. Simplest to set up; the trade-off is that LAN devices, printers and casting services may become unreachable.
- Rule mode: matches the split-tunneling rule list line by line and stops at the first hit. Local sites go direct, domains that need the route go through the node.
- Direct: nothing goes through the node. Mostly a diagnostic — switch to direct, open the same site, and you can tell whether the problem is your local network or the route.
What to look at in split-tunneling rules
There are four common dimensions: domain suffix, domain keyword, IP range and geolocation, and application process (desktop clients can route per app). Order matters more than quantity: one overly broad rule drags traffic that should go direct onto the route and local sites get slower; rules that are too narrow miss services that need the route. Change one rule at a time and verify immediately — far easier to debug than stacking dozens at once.
How DNS leaks happen
Split tunneling is about where lookups go as well as where traffic goes. If traffic takes the node but DNS queries are still resolved by the local network, that's a DNS leak. Pages won't fail to load right away, but lookups drift away from the route's region and you get “the node is abroad, the content is still the local version”. The fix is to enable remote resolution in the client, or make DNS queries follow the proxy rules.
Open the same site once in global mode and once in rule mode. If you get different regional versions, the lookups probably aren't following the route — the route itself is fine.
Post-import checklist
Once everything is configured, run through the list below; it saves most of the “it connects but it's unusable” troubleshooting. Step-by-step import instructions for each platform are on the guides page.
- ✅ The node list matches the dashboard in regions and count; if it doesn't, update the subscription manually first.
- ✅ System time is calibrated, so time-sensitive protocols like VMess don't drop out over clock drift.
- ✅ In rule mode, local sites go direct and services that need the route actually match a rule.
- ✅ DNS queries follow the route — no more “node abroad, local content”.
- ✅ Switching to direct and reopening the same site tells you whether the problem is your local network or the route.
Choosing a route by use case: the order of decisions
Once the terms are clear, choosing comes down to four steps.
- Start with the use case: web pages and documents, streaming, AI tools, large uploads and downloads all have different latency and bandwidth needs.
- Then the protocol: if your local network handles UDP well, prefer Hysteria2 or TUIC; if UDP is throttled, choose Trojan or VLESS.
- Then the route type: for stability at peak hours, pick an IEPL dedicated line; if budget comes first, direct and relay cover everyday use.
- Finally, check the client: does it support the chosen protocol on both desktop and mobile, and can both share one subscription?
Don't reorder those four steps. Picking a protocol before you know the use case usually produces a combination that looks good on paper and fits nothing.
Put each term back on its own level and choosing stops being guesswork: the subscription fetches the configuration, the node decides the exit, the route decides stability, the protocol decides how data is wrapped, and split tunneling decides which traffic takes the route. Pick the use case first, then the protocol, then use the route type to solve stability — that order holds in any client.
VPNUJ currently offers 110+ countries / regions and 160+ routes, monthly plans from ¥9.9 including 60GB, unlimited simultaneous devices and a 14-day no-questions-asked refund. Sign-up needs only a username and password — no email address — and payment supports Alipay, WeChat and USDT. For per-platform import steps, follow the guides page; when you want to compare prices, the plans and pricing page lists every tier and data pack.