VPN Beginner's Guide: Subscriptions, Nodes, Protocols and Routing Explained

Open a client for the first time and you meet four words: subscription, node, protocol, routing. Most people pause here — what does each one control, and which do you change when the connection fails? This beginner's guide works from the outside in, putting every term back where it belongs: the subscription decides which nodes you get, the node decides where your traffic exits, the protocol decides what that traffic looks like as it crosses the network, and routing decides which traffic goes through the proxy and which goes direct.

Each section below follows the same shape: what it is, what it affects, and the mistakes beginners make with it. By the end you should be able to read every setting in your client and know which layer to check first when something goes wrong — instead of changing parameters from top to bottom.

Subscription links: where your node list comes from

A subscription link is an http/https address provided by your service. When the client requests it, it receives a configuration file, usually in one of two forms. The first is a base64-encoded node list, one URI per line, each starting with ss://, vmess:// or trojan://. The second is YAML or JSON that clients such as Clash or sing-box read directly; along with nodes, it carries rule sets and policy groups.

The core problem it solves is synchronisation. Nodes get added, removed, moved to new addresses and re-tuned; entering them by hand is slow and easy to get wrong. A subscription reduces all of that to a single update. Clients usually fetch it at startup and at fixed intervals, and most let you trigger an update manually from settings.

# Config snippet returned by a subscription link (illustrative)
proxies:
  - name: "Hong Kong-01"
    type: ss
    server: hk01.example.com
    port: 443
    cipher: chacha20-ietf-poly1305
    password: "******"
  - name: "Japan-02"
    type: trojan
    server: jp02.example.com
    port: 443
    sni: jp02.example.com
    password: "******"

One thing to be clear about: a subscription link is a credential. Anyone who has it can import your nodes and use up your traffic. So don't paste your subscription address into public groups or forums, and don't share it in screenshots.

Another common misconception: updating a subscription syncs node changes from the server; it does not overwrite the rules and policy groups you edited locally (clients differ slightly here). If you have hand-edited your config, check whether your changes will survive an update before you run one.

Nodes and routes: direct, relay and dedicated lines compared

A node is one record in the config file: a server address, a port, and a set of protocol parameters. Choosing a node really means choosing where your traffic exits. The exit region determines the location some services see, and the exit route determines how stable the connection is.

Route type isn't about where the exit is — it's about how traffic travels from you to that exit. It's the layer beginners overlook most, and the one that shapes how the connection actually feels. There are three common kinds:

Direct

The client connects straight to the address the server exposes. It's the shortest path and the cheapest to run. The trade-off is that this path runs over public international links, queuing alongside everything else at peak hours — congestion and jitter show up directly in your experience.

Relay

Traffic first reaches a relay server, which forwards it to the exit node — two hops in total. The extra hop adds overhead, but relays usually run on optimised international routing, so the path is more predictable and generally more stable than direct. This is the workhorse route type in most subscriptions.

IEPL dedicated line

A dedicated line puts your traffic on a point-to-point private circuit that doesn't share bandwidth with public internet traffic. The benefit shows up as more predictable jitter and packet loss, with peak-hour performance closer to off-peak. The trade-off is cost, so these routes are usually reserved for stability-sensitive use.

One more thing: policy groups in a client bundle several nodes into one group, then pick from them automatically by latency test, manually, or in rotation. Nodes are the resource; policy groups are how you use it. Don't confuse the two.

Common protocols: from Shadowsocks to Hysteria2

The protocol decides how the client and server handshake, how they encrypt, and what the traffic looks like on the wire. It doesn't affect your exit location, but it directly affects whether you connect at all and how fast it feels. A single server can expose several protocol entry points at once, and the subscription lists them separately.

Routing and the three modes: rule, global and direct

Routing (also called split tunnelling) decides whether a given connection goes through the proxy or direct. The client matches it against a rule list, typically by domain and domain suffix, IP range and GeoIP location, process name, or port. Rule lists usually fall into three blocks: what should be proxied, what should go direct, and what should be blocked.

Clients generally offer three modes. The only difference is what happens by default:

1. Rule mode: matches against the rule list — proxied entries go through the proxy, direct entries go direct, and everything else takes the default exit. This is the one to use day to day.
2. Global mode: all traffic goes through the proxy exit; whether direct entries in the rule list still apply depends on the client. Useful for a quick check of whether a problem comes from your routing rules.
3. Direct mode: nothing goes through the proxy; the client keeps only local DNS and the rule engine. Useful for temporarily standing down on a network that doesn't need a proxy.

Three symptoms point to misconfigured routing: domestic sites get slower (traffic detours overseas and back), LAN devices such as printers, screen-mirroring targets and NAS boxes disappear, and some apps fail to sign in or pay. If you see these, first check whether the mode has been switched to global.

How DNS relates to routing

To decide whether a domain should be proxied, routing has to resolve it first. If that resolution happens locally, your queries are visible to the local network — the classic DNS leak. The more common consequence, though, is a mismatch between the resolved address and the route: you're exiting overseas but you get handed a local CDN address, so speeds never pick up.

Most modern clients handle this with fake-ip or remote resolution: domains that need the proxy are resolved by remote DNS, while direct domains still use local DNS. In most cases the defaults are fine — only revisit your DNS settings if pages load slowly or a few sites won't open at all.

Client and platform differences: system proxy, TUN, per-app routing

The same subscription behaves differently across platforms, and the differences come down to two things: how traffic is captured, and whether you can route per app.

Capture methods: system proxy and TUN

A system proxy only applies to apps that respect the system proxy setting: browsers and most desktop software do, but some games, terminal tools and apps with their own network stack ignore it. TUN mode creates a virtual network adapter and captures traffic at the network layer, covering far more; the trade-off is that it needs higher system privileges and is more likely to conflict with other virtual adapters.

Platform differences

• Windows: the widest choice of clients, and mainstream ones support both system proxy and TUN. Note that TUN can conflict with the virtual adapter drivers some security suites install.
• macOS: also supports system proxy and TUN (utun), with a relatively clean setup; the first time you enable TUN you'll see a permission prompt.
• Android: captures traffic through the system VpnService and lets you tick which apps go through the proxy — the finest per-app granularity of any platform here.
• iOS: captures everything through a VPN profile and generally offers no per-app routing, so rules are your only lever — which is why rule quality matters more on iOS.

Troubleshooting order and five common mistakes

When a connection fails, the fastest route is to work through the layers instead of changing settings at random. The suggested order: check that your device time is synced, confirm the client is in rule mode, try another node, and only then consider another protocol. That order starts with the layer that's easiest to verify.

• ✅ Import your subscription link only on your own devices — don't forward it to public groups or share it in screenshots
• ✅ When you can't connect, work through time sync → mode check → another node → another protocol, changing one variable at a time
• ✅ Before updating your subscription, check whether your locally edited rules and policy groups will be overwritten
• ❌ Copying node addresses, ports and passwords by hand — those entries won't follow along when the subscription updates
• ❌ Leaving global mode on permanently, so local services and LAN devices go through the proxy too and every failure gets amplified
• ❌ Using VMess on a device whose clock is off — the server rejects the handshake outright

Putting these terms to work in a real choice

Pulling the earlier sections together, there are really only a few things worth confirming when you pick a subscription service: whether the route types cover how you work, whether your client supports the protocols, how easy subscription updates are, and whether you can get a refund if it isn't for you.

Take VPNWY as an example: 110+ countries and regions, 150+ routes, no limit on the number of devices, no email address required to sign up, and a full no-questions-asked refund within 30 days of your first payment. Monthly plans and data packs are priced on the pricing page, so we won't repeat them here.

Three common questions