VPN Terms Explained: Subscription, Node, Protocol and Routing in One Read

Subscription: how one link becomes a screenful of nodes

In a client, the subscription usually occupies a single line — an address field. It doesn't point to one server but to a list of nodes: the client sends an HTTPS request to that address, parses the response into nodes, and refreshes it automatically on a fixed schedule.

The response format is decided by the server, and there are two common ones. One is a Base64-encoded block of multi-line URIs, one node per line, each beginning with ss://, vmess://, trojan:// and so on; the other is a YAML config used by Clash-family clients, which keeps nodes, policy groups and routing rules in a single file.

Subscription URLs usually carry a random string that the server uses to identify the account. That is what defines the nature of a subscription link: it is a credential. Anyone who has the link can import and use it, and the traffic is counted against the same account. When you need it on a new device, copy it again from the account panel — don't leave the link sitting in a chat history long-term.

Adding a node manually is the other path: enter the address, port, encryption method and password or user ID field by field. It suits a temporary connection to a single server; the catch is that any change to the node's parameters means filling everything in again.

The standard way to import a subscription:

1. In the client, open the Subscription (or Profiles) section and choose Add new.
2. Paste the subscription link and give it a name you'll recognise.
3. Trigger an update manually and confirm the node list appears, with the number of nodes you expect.
4. Connect to a node, then open the IP check page to confirm the exit region.

Nodes: the region is just a label — the route type is what decides quality

A node is the server the client ultimately connects to; its config fields include address, port, encryption method and credentials. The region in a node name, such as "Singapore 01", indicates roughly where the exit is — it's a label, not a measure of quality.

The same region can host three kinds of routes, with very different prices and stability:

• Direct: the client connects straight to the server's public address. Shortest path, lowest cost, all of it over the public internet, so it swings along with routing jitter at peak hours.
• Relay: the client connects to a relay entry first, which forwards to the exit server. The entry is usually closer to the user, while the exit still follows the target region. It adds a hop, but moves the least predictable leg into a segment you can control.
• IEPL dedicated line: traffic between the two ends runs over a carrier point-to-point leased line and never passes through public internet routing. Flat latency curve, little jitter, highest cost, usually billed by bandwidth.

How the three route types compare:

Using VPNWI's subscriptions as an example, the network looks like this:

Before choosing a node, you can look over each region's routes and live latency on the servers page and then decide which one to use. When do you need to touch it: by default, pick one of the nodes near the top of the latency test; if things stutter, switch nodes first rather than changing protocols; when a region has several nodes, prefer relay or dedicated lines.

Protocols: from Shadowsocks to Hysteria2, what each one solves

The protocol decides how the client and the node encrypt, how they handshake, and whether traffic goes over TCP or UDP. It doesn't change the exit location: switching protocols on the same node leaves the exit region unchanged — what changes is the transport.

Common protocols, in the order they appeared:

• Shadowsocks: a lightweight encrypted proxy using AEAD cipher suites such as aes-128-gcm and chacha20-ietf-poly1305. Low overhead, well suited to low-spec devices and routers; it only encrypts and forwards traffic, with no obfuscation.
• VMess: the native protocol of the V2Ray family, using a UUID to identify users. It has a lot of parameters, and one mistyped field means it won't connect at all.
• VLESS: a simplified successor to VMess. The protocol itself doesn't encrypt — encryption and obfuscation are handled by the outer TLS layer, so the handshake costs less.
• Trojan: disguises traffic as standard HTTPS, usually on port 443, so to middleboxes along the path it looks no different from an ordinary website visit.
• Hysteria2 and TUIC: QUIC-based protocols that run over UDP. Their retransmission strategy is more aggressive on weak networks and under packet loss, giving better latency and throughput; the trade-off is the reliance on UDP — where the network treats UDP poorly, they can be less stable than TCP-based protocols.

In a subscription file, a node is a single line like this:

ss://<encryption method>:<password>@<server address>:<port>#<node name>
vmess://<Base64-encoded JSON>
trojan://<password>@<domain>:443?sni=<domain>#<node name>

The client parses these fields and creates node entries. When do you need to touch it: not by default; switch to another protocol if your client version doesn't support the current one; if the network throttles UDP, move from a QUIC-based protocol back to a TCP-based one; edit manually only when the server side gives you explicit parameters.

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

Routing is how the client chooses an exit for every connection according to rules: proxy, direct, or reject. Rules are matched from top to bottom, and the first match wins.

There are five common matching dimensions:

• Domain suffix: matches when a domain ends with a given string.
• Domain keyword: matches when a domain contains a given string.
• IP range: matched by CIDR — private ranges, for example, are let through directly.
• Geo library: judged by IP geolocation, typically written as rules like GEOIP,CN,DIRECT.
• Process name: available on desktop, letting you send a specific app out through a chosen exit.

A typical rule set does three things: local domains and local IPs go direct; everything else goes through the proxy; domains for streaming or specific services are pinned to a chosen node.

DNS leaks: the third path that routing doesn't cover

Routing decides the connection exit; DNS resolution is a separate path. If DNS queries don't follow the proxy, the resolution requests go out through the local network's DNS, the answers can be poisoned, and the queries themselves can be seen — that's a DNS leak.

There are two common fixes: send DNS queries through the proxy tunnel — remote DNS; or use fake-ip mode so the client takes over resolution and only resolves a domain when a connection is actually established. Verification is simple: once connected, open the IP check page, see whether the resolved exit region matches the node you picked, then switch nodes and test again.

Routing rules and DNS handling both happen on the client side; on the server side, the privacy stance is no logging. When do you need to touch it: only when something that should go direct is going through the proxy, or something that should go through the proxy is going direct. Otherwise, leave the default rule set in place.

Global, rule and direct: three modes and when to switch

The client home screen usually has a mode switch, with three values standing for three overall policies:

• Rule mode: follows the routing rules — the setting to use almost all of the time.
• Global mode: all traffic goes through the proxy. Useful for verifying that every request leaves through the node; the cost is that local sites take the long way round too.
• Direct mode: nothing goes through the proxy — effectively pausing the proxy while leaving the client running, which helps you tell a local network problem apart from a node problem.

The order to decide a switch:

1. Stay in rule mode by default.
2. If a local site is wrongly sent through the proxy, check the rule set first — don't jump straight to global.
3. When you need to verify exit consistency, switch to global temporarily and switch back to rule mode when you're done.
4. When the network misbehaves, switch to direct first: if direct works, the problem is the node or the proxy path; if direct doesn't work either, the problem is your local network.

Self-check list:

• ✅ Import the subscription link only on your own devices; don't forward it to chat groups or public config-sharing sites.
• ✅ Once connected, open the IP check page first and confirm the exit region matches the node you chose.
• ✅ Stay in rule mode day to day; switch to global or direct only while troubleshooting.
• ✅ When things stutter, change nodes first and only then consider touching protocols or routing rules.
• ❌ Treating the subscription link as a config file you can share with anyone.
• ❌ Leaving global mode on for hours of local video — bandwidth takes a detour and nothing gets solved.
• ❌ Resolving account-related domains with local DNS you don't control on public Wi-Fi.

Where the same term lives on different platforms

These concepts are the same on every platform; only the entry names and the way traffic is captured differ.

• Windows and macOS: desktop clients generally offer a TUN mode, using a virtual network adapter to capture apps that ignore system proxy settings, and routing rules can match by process name.
• Android: the client captures traffic through the system VPN interface, and some clients support per-app routing so that only chosen apps go through the proxy.
• iOS: clients install from the App Store, so availability depends on the region of your account; the system captures traffic through a VPN profile or Network Extension, and routing capability depends on the client's implementation.
• Linux: command-line and graphical clients coexist, and rule files are usually YAML, which makes them easy to keep in version control.

Switching platforms doesn't mean relearning the concepts — just find the matching entry in the client: subscriptions live under Profiles, nodes in the server list, and the mode switch is usually at the top of the home screen. Per-platform install and import steps are covered in the setup guide.

Glossary

Six terms, six questions, one table for looking them up: