VPN Terms Explained: Subscription, Node, Route Type and Protocol

This glossary is not alphabetical. It follows the order in which a single connection happens: first you get a node list, then you pick which server to connect to, then you decide which path the data takes, and only then do you talk about encryption. Read it in that order and the six terms stop blurring together.

Why these six terms keep getting mixed up

Open any client and the subscription sits right next to the node, the route type is buried on the pricing page, the protocol hides inside the node details, and routing is a screen full of toggles. You know every word, but when something breaks you cannot say which layer is at fault, so you keep switching nodes — and the tenth one does not help either.

Split one connection into four layers and it gets much clearer:

Account layer: the subscription. It decides which nodes the client can see.
Entry layer: the node. It decides which server you connect to and with which parameters.
Path layer: the route type. It decides how data travels from your device to the exit.
Handshake layer: the protocol. It decides how traffic is encrypted and whether it runs over TCP or UDP.

Routing and global/rule mode sit outside those four layers. They are the two switches on the routing layer: the first decides which traffic goes through the proxy, the second decides whether the rule set applies at all.

Six terms at a glance: one-line definitions and the first thing to check when something breaks
Term	One-line definition	Check this first
Subscription	The link the client uses to pull the node list	Whether the link is complete, and whether it has been forwarded to anyone else
Node	The full set of access parameters for one server	Whether address, port, protocol and password match the configuration
Route type	How data travels from your device to the exit	Whether it wobbles at peak hours, and whether the middle segment runs over the public internet
Protocol	How the client and the node handshake and encrypt	System time, TLS, and whether UDP is restricted
Routing	Which traffic goes through the proxy and which goes direct	Rule order and the final fallback rule
Global and rule mode	The client-wide routing switch	Whether global mode was left on, which disables every rule

Below, each one in that order.

Subscription: one link, essentially your account credential

A subscription is a URL. The client requests it every so often and gets back a node list: possibly a base64-encoded string of ss://, vmess://, trojan://, vless:// or hysteria2:// links, possibly a YAML config that Clash / mihomo can read directly. Importing a subscription just means handing that URL to the client; it does the rest.

Three things that are easy to miss:

Updating a subscription replaces everything. The client re-requests the link and whatever the server returns overwrites what you had. Node names, ordering and notes you edited by hand are gone after one update.
A subscription can carry account status. Some servers attach the expiry date and used traffic to a response header (subscription-userinfo), and the client shows it on the home screen. Support for that header varies between clients — not seeing it does not mean it is absent.
A failed fetch and a failed connection are two different problems. A failed fetch usually means the link was truncated by a chat app, the device clock is far enough off to break the TLS handshake, or the current network cannot reach the panel domain. A node that will not connect belongs to another layer entirely.

A subscription link is an account credential The token in that URL usually returns every node without a second factor. Forward it to someone and you have handed over the account. When you change devices, reuse the same subscription instead of copying individual nodes.

Node: a set of access parameters, not a name

A node is every parameter the client needs to reach an exit server: address, port, protocol, encryption method, password or UUID, transport (TCP / WebSocket / gRPC), TLS on or off with SNI, and path. Miss any one of them and the handshake never completes.

So a node name and a node are two different things. The name is only a label — rename it and it still connects. What actually decides whether traffic flows is the parameter set above. One exit server can spawn several nodes, with different ports and transports, which is why node counts and route counts often do not match.

To judge whether a node is usable, do not rely on a single speed test: does the handshake succeed several times in a row, does throughput drop noticeably at peak hours, and do long-lived connections such as video calls and SSH sessions survive? Those three say more than a one-off peak number.

Route type: direct, relayed and dedicated lines compared

Route type describes the path: how data gets from your device to the exit server.

Direct: the client connects straight to the exit server over the public internet. Cheapest, and the most exposed to congestion at peak hours.
Relayed: you connect to a relay entry first, which forwards to the exit. The entry address can be swapped while the exit stays put; it is steadier than direct, but the middle segment is still public internet.
IEPL dedicated line: a carrier-grade international Ethernet private line. The middle segment never touches the public internet and bandwidth is effectively dedicated. Latency and jitter are far more predictable, and it costs the most.

How the three route types travel, and what they suit
Type	Path	Traits	Best for
Direct	Device → exit, all over the public internet	Low cost; noticeable swings at peak hours	Quick lookups, light browsing
Relayed	Device → relay → exit	Entry can be swapped, steadier than direct; middle segment still public	Everyday web, social media, general downloads
IEPL dedicated line	Device → dedicated entry → exit, middle segment off the public internet	Latency and jitter far more predictable, stable at peak hours	Video calls, long-lived connections, streaming

Look at the route first, the protocol second. Whether peak hours stall is decided mainly by the path; the protocol solves how to encrypt and how to handshake, not whether the public segment in the middle is congested. Conversely, a good route with the wrong protocol still will not connect.

The current routes and plans on this site are easy to compare: 90+ countries, 190+ routes, no cap on simultaneous devices, and a no-questions refund within 7 days of your first payment.

90+Countries

190+Routes

UnlimitedSimultaneous devices

7 daysNo-questions refund

Protocol: choosing between six common handshakes

The protocol decides how the client and the node handshake, how traffic is encrypted, and whether it runs over TCP or UDP. It is not the same thing as encryption strength: outer encryption on every mainstream protocol is good enough; what really shapes the experience is whether the transport profile matches the network you are on.

Six common protocols: transport, traits and what to watch
Protocol	Transport	Traits	Watch out for
Shadowsocks	TCP / UDP, AEAD encryption	Lightweight, low overhead, supported almost everywhere	Traffic profile is fairly distinctive and easy to fingerprint
VMess	TCP / WebSocket / gRPC, can be wrapped in TLS	The veteran protocol of the V2Ray family, supports multiplexing	Validation depends on time; a large clock gap between the two ends breaks the handshake
VLESS	Usually wrapped in TLS (including Reality)	No encryption of its own, relies on outer TLS, one less layer of overhead	Many settings; SNI and the disguise target must match
Trojan	TLS	Disguised as ordinary HTTPS traffic, password authentication	Needs a domain and a certificate; a wrong password simply will not connect
Hysteria2	QUIC(UDP)	Still works on weak, lossy networks	Depends on UDP; some networks throttle or block it
TUIC	QUIC(UDP)	Multiplexing, fast handshake, low latency	Also at the mercy of UDP quality

Three trade-offs

Your network treats UDP well: Hysteria2 and TUIC hold up better under packet loss, which suits mobile networks and long cross-border links.
Your network restricts UDP: prefer the TLS family — VMess + TLS, VLESS + Reality and Trojan can all run on port 443.
Old devices, old clients: Shadowsocks has the widest compatibility; nearly every client supports it.

Clock sync is not a small thing The VMess handshake validates a timestamp, so a large gap between client and server fails outright — the symptom is a node that looks available but never connects. When that happens, set the device clock to automatic sync first, then go back to the configuration.

Routing: which traffic goes through the proxy and which goes direct

Routing is an ordered set of rules. The client matches from top to bottom and stops at the first hit, so order matters more than quantity.

Common rule types:

DOMAIN / DOMAIN-SUFFIX / DOMAIN-KEYWORD: match by domain name.
IP-CIDR / GEOIP: match by IP range or geographic assignment.
PROCESS-NAME: match by process name; desktop clients only.
RULE-SET: reference an external rule set, which is easier to maintain in bulk.
MATCH (written FINAL in some clients): the fallback rule, and it must come last.

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - DOMAIN-KEYWORD,github,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

This rule set means: example.com and its subdomains go direct; any domain containing github goes through the proxy; anything resolving to a mainland China IP goes direct; everything else goes through the proxy. Move MATCH to the first line and none of the rules below it ever run — the symptom is that the rules are there but nothing happens.

DNS leaks: the other half of routing

A DNS leak means domain lookups do not follow the proxy path and are handed to the local network instead. Two consequences: which domains you visit is exposed to the local DNS resolver, and the answers can be poisoned, handing you a wrong address.

The usual fix is to let the proxy resolve DNS. In fake-ip mode the clientsynthesises a fake address locally and returns it to the app, while the real lookup happens at the exit. The cost is that some software relying on real IPs, such as LAN device discovery and the occasional multiplayer game, misbehaves; add direct rules for those domains, or put them in fake-ip-filter.

Routing self-check

✅ Open a site inside mainland China; if the connection details show a direct connection, the rules are matching as expected.
✅ Open an overseas site; if the connection details show the proxy, the fallback rule is working.
❌ If everything shows as proxied, the mode is usually stuck on global and the rules never take part.
❌ If an overseas site goes direct, the rule order is probably reversed or the fallback rule is missing.
❌ If domain lookups are still handled by the local carrier, you have a DNS leak and should check the DNS settings.

Global and rule mode: two switches, do not mix them up

Clients usually offer three modes:

Global: all traffic goes through the proxy and routing rules are ignored entirely.
Rule: traffic follows the routing rules — the mode to use day to day.
Direct: no traffic goes through the proxy.

The main use of global mode is troubleshooting, not daily use. When a site will not open, switch to global first: if it opens, the node, route and protocol are fine and the problem is in the rules; if it still will not open, the problem is the node or the network itself. That order saves a lot of pointless node switching.

Clients per platform: the same subscription, different behaviour

Subscriptions are universal; clients are not. The same node list can behave completely differently across systems.

Windows: Clash Verge Rev (mihomo core) and v2rayN are the common choices; system proxy or TUN mode both work.
macOS: ClashX Meta, Surge and others; TUN mode requires approving a system extension.
iOS: Shadowrocket, Stash and others take over traffic through a system VPN profile; background keep-alive is limited by the OS, so a long spell in the background may drop the connection.
Android: Clash Meta for Android, v2rayNG and others; the first connection asks you to authorise the VPN service.
Linux: usually the mihomo or sing-box core running under systemd; TUN mode needs root or the relevant network capabilities.

The differences come down to four things: which protocol subset is supported, the routing rule syntax, how DNS is handled, and TUN permissions. Before switching clients, confirm it supports the protocol you are using — some clients added QUIC-family support late, so a Hysteria2 node that will not connect is not necessarily the node's fault.

Putting the six terms together: one connection, start to finish

The client pulls the node list using the subscription link.
You pick a node; the client reads its address, port, protocol and password.
Traffic passes through the routing rules first, which decide proxy or direct; global/rule mode decides whether those rules apply at all.
Proxied traffic is encrypted with the protocol and reaches the exit along the path set by the route type.
The exit server decrypts it, fetches the target site, and the data comes back the same way.

Troubleshoot in that order and you will not go in circles: confirm the subscription can pull nodes, confirm the node parameters are right, check whether global mode was left on, and only then suspect the route and protocol.

Common questions

All the nodes changed after I updated the subscription — is that an error?

No. A subscription update replaces everything, so when the server adjusts the node list you see it. Hand-edited names and ordering get overwritten; that is expected.

The same node connects on desktop but not on mobile?

First compare the protocol and transport settings on both ends, then check whether the mobile network restricts UDP — QUIC-family protocols depend on it. The same subscription occasionally parses into slightly different parameters in different clients.

Global mode works but rule mode does not?

That means the node itself is fine and the problem is in the routing rules: check the rule order, whether a fallback rule exists, and whether the target domain was mistakenly matched into the direct list.

Do I have to enable TUN mode?

Not necessarily. System proxy only captures apps that respect the system proxy settings; TUN mode takes over at the network layer and covers programs that ignore it, but it needs higher privileges and is more involved to configure. Pick whichever fits how you use it.

Six terms: four layers plus two switches. The subscription handles the account, the node handles the entry, the route type handles the path, the protocol handles the handshake; routing decides which traffic is proxied, and global versus rule mode decides whether the rules apply. Troubleshooting layer by layer beats switching nodes over and over.