Subscription, node and protocol are the three walls most beginners hit the moment they open a client: there is a subscription link to paste in, a long list of nodes underneath, and every node trailed by abbreviations like SS, VMess and Trojan. This quick-reference guide follows the order you actually meet them, from getting the link to getting online, and unpacks subscriptions, nodes, route types, protocols, routing rules and global mode one at a time, with a one-line definition and a common misunderstanding for each, plus a terminology table and a first-setup checklist at the end.
Subscription links: what one URL actually carries
A subscription link (subscription URL) is essentially an HTTPS address. Open it and what comes back is not a web page but a node list: possibly a Base64-encoded block of node strings, or a YAML or JSON config written for a particular client. “Add subscription” in the client does two things: it stores that address, and it parses the dozens of nodes in the list into your node list.
The difference from adding a node by hand is how it is maintained. Manual entry means filling in address, port, password, encryption method and transport one field at a time, and a single wrong character keeps you offline; a subscription is delivered in bulk, so when the provider adds or removes routes, one tap on “Update subscription” in the client syncs the change. That is also why a subscription link should be treated as a credential: anyone who has the address can import the same set of nodes into their own client.
After a route change, when the client reports every node timed out, or after the client has been closed for a long stretch, refresh the subscription before troubleshooting. Plenty of “all nodes are down” reports are just a stale local list: the server moved its entry addresses long ago.
What the fields inside a subscription control
- Address and port: the node's entry point, and the first two things to check when a connection fails.
- UUID or password: your identity credential; one wrong character and the server rejects it outright.
- Transport: TCP, WebSocket, gRPC and so on, deciding how the traffic is carried.
- TLS and SNI: whether a TLS layer is applied, and the domain name declared during the handshake.
- Encryption method: listed separately for protocols such as Shadowsocks, for example the AEAD family.
The two fields beginners skip most often are transport and TLS. On the same node, with address and port both correct, putting TCP where WebSocket is required shows up as an endless spinner rather than a clear error message.
Nodes and routes: direct, relay and dedicated lines compared
A node is one selectable exit in the client list; a route is the actual path traffic takes from your device to the landing server. In everyday conversation the two get used interchangeably, but when the question is “why is this one fast and that one slow”, the route is what decides it.
| Route type | Traffic path | Traits | Best for |
|---|---|---|---|
| Direct | Device → landing server over the public internet | Simple; latency depends on public internet quality and swings noticeably at peak hours | Everyday browsing, cost-sensitive use |
| Relay | Device → entry node → landing server | Nearby entry point, optimised return path, steadier at peak times | Cross-continent access, evening streaming |
| IEPL dedicated line | Device → dedicated entry → landing, off the public internet | Stable latency and packet loss, highest cost | Live streams, voice meetings, long-lived connections |
Nothing in this table is absolutely better than anything else. The value of a dedicated line is stability, not raw speed; the same direct public route can be faster than a dedicated line at 3 a.m., it just swings more at peak hours. Conflate the two and you get the familiar disappointment of “I paid for a dedicated line, so why is it no faster”.
If the dozens of nodes in the list all point at the same landing server, switching between them only changes the entry point: when the landing server is congested they will all be slow. The order to judge in is landing location first, route type second, list length last.
With VPNJM, for example, routes cover 100+ countries and 220+ in total. Whether a specific one is direct, relay or IEPL is marked in the route list; reading that column before you choose saves more time than trying nodes one after another.
Protocols: how Shadowsocks, VMess, Trojan and VLESS differ
The protocol decides how the client and server encrypt and how they shake hands. The abbreviations in the list, SS, VMess, Trojan, VLESS and Hysteria2, are protocol names. Pick the wrong protocol and the connection fails even with the right address and port; misconfigure the transport or TLS and the usual symptom is a connection that establishes but carries no traffic.
| Protocol | Transport base | Key traits | Easy to get wrong |
|---|---|---|---|
| Shadowsocks | TCP / UDP, AEAD encryption | Lightweight, low overhead, few settings | No native multiplexing |
| VMess | TCP / WebSocket / gRPC and more | Plenty of transport choices, TLS can be layered on | Client and server clocks are checked; a large skew fails authentication |
| VLESS | As above, usually with TLS or Reality | No built-in encryption, lower overhead than VMess | Without the outer TLS layer there is no encryption |
| Trojan | TLS, usually on port 443 | Traffic looks like ordinary HTTPS | Needs a domain and a valid certificate |
| Hysteria2 / TUIC | QUIC, over UDP | Holds up well under heavy packet loss, aggressive congestion control | May not work at all on networks that restrict UDP |
Beginners do not need to memorise parameters. The practical order is: confirm which protocols your client supports, then see which ones the server offers, and only then compare route quality. One server can run several protocols at once, so use whichever connects and do not agonise over whether a name sounds advanced.
Client support for protocols varies by platform: desktop clients usually cover the most, mobile clients are limited by system network extensions so some UDP-based protocols are unavailable on particular versions, and router firmware often supports only one or two. Before importing a subscription, check that your client recognises the protocols in the list; that is less work than importing and then testing node by node.
What matters is whether the protocol runs over TLS, whether the certificate is valid, and whether your client is out of date, not whether the name sounds intimidating. VLESS on its own carries no encryption; its security comes from the TLS layer around it.
Routing rules, global mode and DNS leaks
The mode decides whether a given flow of traffic goes through the proxy at all. There are three common settings: global mode sends everything through the node; rule mode consults the rule list, sending matches through the node and everything else direct; direct mode is effectively the proxy switched off for now. Use global when you are troubleshooting, rules day to day.
How the rule list is written
Rules match by type. The common ones are DOMAIN (exact domain), DOMAIN-SUFFIX (domain suffix), IP-CIDR (IP range), GEOIP (IP database by country or region) and PROCESS-NAME (by process, generally desktop only). Rules are matched from top to bottom and the first hit wins, so putting exceptions near the top does more good than piling more rules on at the end. On mobile there is also a per-app layer, so you can send only chosen apps through the node.
What a DNS leak actually is
A DNS leak means domain lookups do not travel through the proxy tunnel but are handed to the local network instead. Two things follow: anyone on the local link can see which domains you visited, and CDNs assign servers based on where the lookup came from, which can point you at a distant server, the familiar “it is connected but slow”. There are two ways to check: see whether DNS in the client is set to follow the proxy or resolve remotely, and once connected open IP lookup to confirm the resolver's location matches the region of your exit IP.
It also sends your local online banking and corporate intranet systems out through the node, and some services will flag that as risk or refuse the login outright. Unless you are troubleshooting, stay in rule mode day to day.
Quick reference table: the ten terms people ask about most
The table below is ordered the way you meet these terms: visible while configuring, useful when something breaks. On the left is the term, in the middle a one-line explanation, on the right the misunderstanding beginners most often bring with them.
| Term | In one line | Common misconception |
|---|---|---|
| Subscription link | An address that delivers a list of nodes in bulk | Storing it like a password, or forwarding it to someone else |
| Node | One selectable exit in the client list | Assuming more entries means better routes |
| Entry / landing | The first server you connect to / the server your traffic finally exits from | Using the two interchangeably, then being unable to say which leg is slow |
| IEPL dedicated line | An international dedicated line that avoids the public internet | Assuming a dedicated line is always faster than a direct public route |
| Transport | TCP, WebSocket, gRPC and other ways of carrying traffic | Checking only address and port, and skipping the transport field |
| TLS / SNI | The outer encryption layer and the domain declared during the handshake | Assuming that entering a domain means the certificate is configured |
| Routing rules | Decide by domain, IP or process whether traffic is proxied | Assuming that with the proxy on, all traffic goes through the node |
| DNS leak | Lookup requests that do not go through the proxy tunnel | Assuming only the IP address can be exposed and domains do not matter |
| UDP forwarding | Whether a node lets UDP traffic through | Assuming it has nothing to do with games or voice calls |
| Traffic reset | Resets monthly on your activation date, not on the calendar month | Assuming it zeroes out on the 1st of every month |
First setup checklist
Once the terms above line up, run through this order on your first setup; most “will not connect” and “connects but slow” cases can be pinned down in a few steps.
- ✅ Refresh the subscription first and confirm the list is not a stale cache.
- ✅ Check protocol, port and transport one by one; all three must match the configuration you were given.
- ✅ Enable remote resolution, or the DNS setting that follows the proxy, to reduce leaks.
- ✅ Start in rule mode and send only the domains you need through the node.
- ✅ Once connected, open IP lookup and confirm the exit region matches the node you selected.
- ❌ Do not judge quality by trying every node in turn; look at landing location and route type first.
- ❌ Do not sign in to local online banking or a corporate intranet while in global mode.
- ❌ Do not treat “the page opens” as your only test; results can differ per app and per domain.
In one line: a subscription is the roster, a node is the exit, a route is the path, a protocol is the way they talk, and the mode decides who takes that path. Checking in that order on your first setup makes it easier to find which layer is failing than swapping nodes over and over.
The terms themselves are not hard; what is hard is meeting them all on one screen at once. Next time an unfamiliar abbreviation appears in your client, work out which layer it belongs to first: the roster (subscription), the exit (nodes and routes), the way they talk (protocol), or the routing rules (mode and routing). Once it is in a layer, check the table; most questions answer themselves on the spot.