VPN Terms Explained: Subscription, Nodes, Route Types, Protocols, Split Tunneling, Global vs Rule Mode

From Subscription to Connection: How Those Terms Appear in Your Client

The first time you open a client, you don't see one big switch — you see a list. Sort out the order in which things appear, and every term afterwards falls into place.

The full chain looks like this: get a subscription link → import it into the client → the client requests the subscription URL and pulls back a node list → pick a node from that list → the client uses its routing rules to decide which traffic goes through that node → the connection is established. The sections below follow that order.

A subscription link is a URL with parameters that points to a configuration file on the server. When the client requests it, it gets back a configuration containing several nodes, each with a server address, port, protocol and encryption parameters. It also carries your account credentials — it is both a config and a key.

A node is one entry in that list, corresponding to a server endpoint you can connect to. Node names often carry prefixes like HK, JP, SG or US, which indicate which country or region the route exits from — not that your traffic only loops around inside that one country.

Latency is the round-trip time in milliseconds the client gets from probing a node; it is only useful as a rough ranking. The probe packet is tiny and may not follow exactly the same path as real traffic, so low latency does not mean fast downloads. Bandwidth and data allowance are a different dimension, depending on your plan's data quota and the capacity of the route itself.

Nodes and Route Types: How Direct, Relay and IEPL Routes Differ

A node name only tells you where the exit is, not how you get there. The segment between your device and the exit server is what the industry calls a route, and there are three common ways to organise it.

Direct: the client connects straight to the public address of the exit server. Shortest path, lowest cost; the cross-border leg runs over the public internet, so latency jitter is noticeable when international gateways are congested at peak hours.

Relay: the client first connects to a nearby relay server, which forwards to the exit. The cross-border leg can take an optimised path, usually more stable than direct, at the cost of one extra forwarding hop.

IEPL: short for International Ethernet Private Line, a carrier-grade point-to-point leased line whose cross-border leg does not pass through public internet gateways. Packet loss and jitter are lower, and the cost is the highest — typically used where stability matters most.

MeyeVPN's routes work like this: filter by route type first, then pick the few nodes with the lowest latency in your target region; the full breakdown of regions and routes is on the nodes page.

Protocols: What Shadowsocks, VMess, Trojan, VLESS, Hysteria2 and TUIC Each Are

A protocol decides three things: how the client and server handshake, how data is encrypted, and whether data travels over TCP or UDP. It is a separate matter from route type — the route solves how packets travel, the protocol solves what packets look like. For users, the protocol comes down with the subscription and usually needs no manual choice.

• Shadowsocks: a lightweight proxy protocol, close in spirit to SOCKS5 plus its own encryption layer (the AEAD family, such as chacha20-ietf-poly1305 and aes-256-gcm). Low overhead, which suits routers and other devices with limited performance.
• VMess: a protocol developed for the V2Ray project; it identifies users with a UUID and supports transports such as WebSocket, gRPC and HTTP/2. Early implementations relied on timestamp validation, so a client system clock that is too far off causes the handshake to fail outright — a common reason beginners can't connect.
• VLESS: the lightweight successor to VMess. It has no built-in encryption of its own and relies on TLS or the transport layer for protection; the structure is simpler and overhead lower, and it is often paired with XTLS or REALITY.
• Trojan: disguises the proxy session as standard HTTPS traffic, usually on port 443, so it looks like ordinary website access.
• Hysteria2: a QUIC-based (UDP) protocol with built-in congestion control, more stable on lossy or weak networks; because it depends on UDP, it won't connect on networks that restrict UDP.
• TUIC: also QUIC-based, with multiplexing and connection migration, so a connection is less likely to drop when you switch from Wi-Fi to cellular.

Routing Rules, Global and Rule Mode: Choosing Between the Three Modes

Clients usually offer three modes at the top: Global, Rule and Direct. They all decide the same thing — which traffic goes through a node.

• Global mode: all traffic goes through the node, including local sites. Behaviour is predictable, but local sites take a detour and load more slowly, some services may trigger verification because your exit address changed, and data use is higher.
• Rule mode: matches traffic against built-in routing rules, one by one. Common rule sets split by domain and IP range: local domains and local IP ranges connect directly, while traffic that needs to cross borders goes through a node; desktop clients can also route by process.
• Direct mode: no traffic goes through a node — effectively turning the proxy off while keeping the client running, which is handy for comparison and troubleshooting.

Routing rules are that matching logic itself: a set of if-it-matches-X-send-it-to-Y entries covering domain suffixes, IP ranges and process names, plus any custom rules you add. How good rule mode feels depends mainly on how promptly the rule set is maintained.

• ✅ Everyday browsing and work: use rule mode — local traffic direct, cross-border traffic through a node
• ✅ Only want your browser on the node: use per-process routing on desktop, or per-app proxying on mobile
• ✅ Need to see how a site behaves from an overseas exit: switch to global mode temporarily, then back to rule mode
• ❌ Leaving global mode on all day to watch local video: traffic takes the long way round and loads more slowly
• ❌ Treating 'rule mode isn't working' as 'the service is broken': first check whether the target domain was matched as direct

DNS Leaks and Subscription Updates: Two Steps That Are Easy to Overlook

A DNS leak means your traffic already goes through a node, but domain lookups are still sent to your local carrier's DNS servers. There are two consequences: results can be poisoned, giving you the connected-but-nothing-loads experience; and the lookup records reveal which domains you are visiting.

Clients usually handle this in one of two ways: let the proxy take over DNS queries, with resolution done on the node side and the result returned to you; or use encrypted DNS (DoH / DoT) to replace plaintext queries with encrypted transport. Both aim to keep lookups off your local DNS.

How to check: connect to a node, open a DNS leak test page, and see whether the resolvers listed are your local carrier's. If they still are, DNS takeover isn't working — turn on remote DNS in the client settings, or specify an encrypted DNS address manually.

Subscription updates are the other easy thing to forget. When nodes are added or removed and routes are adjusted on the server side, the client won't know on its own — it has to pull the subscription again. Updating manually once a week is a good habit, or turn on auto-update in the client (usually daily or weekly). If a region clearly has nodes but you never see them, update the subscription before troubleshooting anything else.

Setup checklist and common questions

Here is the previous few sections compressed into a checklist you can follow directly:

• ✅ After importing the subscription, update it manually once to make sure the node list is current
• ✅ On mobile, add the client to the system battery-optimisation whitelist so it isn't killed in the background and dropped
• ✅ On desktop, make sure the client has permission to create a virtual network adapter or set the system proxy
• ✅ Once connected, run a DNS leak check to confirm lookups aren't landing on your local carrier
• ❌ Don't edit the protocol parameters inside the subscription by hand — a wrong value means you simply can't connect
• ❌ Don't post your subscription link in public, and don't expose the full link in screenshots

Are more nodes always better?

No. More nodes means more exit options, but what really shapes your experience is the route type and how congested the current time slot is. Rather than trying dozens of nodes one after another, filter by route type first, then pick a stable one from the lowest-latency few and stick with it.

Is a low-latency node always faster?

Not necessarily. Latency is the round-trip time from a probe — it reflects how quickly a node responds. Download speed also depends on route capacity, exit bandwidth and the limits of the server on the other end. Whether video stutters and whether pages load quickly are two different things.

Global mode or rule mode — which is more secure?

Neither has anything to do with encryption strength; the only difference is where traffic goes. Use rule mode day to day: local traffic connects directly and actually crosses fewer international links. Switch to global mode only when you need to check how a site behaves from an overseas exit.

Do I need to choose a protocol myself?

Usually not. The subscription already specifies the protocol for each node and the client uses it automatically. You only need a node with a different protocol when your network restricts a particular transport (UDP, for example).