Open any client and the first screen is the same set of words: subscription, node, route, protocol, split tunneling, global. They sit on different layers — the subscription decides where the configuration comes from, nodes and routes decide where the data leaves, the protocol decides how it is packaged, and split tunneling decides which data needs to leave at all. Below, the entry-level VPN vocabulary is walked through in that order, with every term tied to a specific switch or line of configuration in the client.
This is a quick reference, not a review. The parts about routes and protocols are general technical explanations that hold for any provider; the numbers for price, data and refunds come from VPNCW's public pricing page.
Subscription links: import once, and every node updates from then on
A subscription link is an https address; the server keeps the node list behind it, and in most implementations it is a block of Base64-encoded configuration text. “Import from URL” and “import subscription from clipboard” in a client do the same thing: fetch once, decode, expand into node entries, then fetch again on the schedule you set.
So subscription and the node stand in a source-to-entry relationship. Add a new route on the server and the list gains a row after the client refreshes; remove one and the local entry disappears too. Manually added nodes (scanning a QR code, pasting a single config link) work just as well, but you maintain the additions and removals yourself.
A subscription link is as sensitive as an account credential
The link carries your user identifier. Anyone who gets it can import it into their own client and use the same data allowance — there is no password and no second factor. So it does not belong in group chats, public screenshots, or “online speed test” pages of unknown origin.
Tip: if a subscription link leaks, the right move is to invalidate and regenerate it, not just change the password. Most panels offer a reset option; the old link stops working immediately and you re-import once on each device.
Four common reasons an import fails
- The link was truncated by a chat app, or picked up spaces and line breaks when copied;
- The client and server clocks are too far apart — VMess relies on timestamp validation, so set the system time to sync automatically;
- The subscription address has been reset while the old link is still stored locally;
- The client is too old and does not recognise a newer protocol in the subscription.
Nodes and routes: one word, two meanings
A node is a concrete entry point: region, city, protocol, port, transport. Only when all of these are present is it a usable configuration. One row in the client list is one node, and choosing a node is essentially choosing which region your traffic leaves from.
A route is something else — how the data travels from your device to the landing data centre. The same city can be reached by direct connection, relay or IEPL line, while the node name often just says “Tokyo 01” or “Tokyo 02”; the difference hides behind those two words.
| Route type | How the data travels | Peak-hour behaviour | Best for |
|---|---|---|---|
| Direct | Local network reaches the overseas data centre through the public international gateway | Noticeably affected by congestion at the international gateway | Quick lookups when stability is not critical |
| Relay | Connects first to a domestic relay entry, which then leaves the country over an optimised path | The relay leg avoids public congestion, usually steadier than direct | Everyday browsing, video, leaving it connected for hours |
| IEPL line | End to end over a carrier's international private line, never touching the public gateway | Lowest jitter and packet loss | Meetings, long-lived connections, work that cannot tolerate drops |
No specific latency figures here: latency depends on your city, your ISP and the network conditions at the time, so any hard-coded number is not worth trusting. Whether a route suits you is decided by how stable it is at peak hours, not by the adjectives in the node name.
90+ countries and 170+ routes mean most popular regions have several entry points to choose from; one subscription covers unlimited devices online at once, so the desktop at home and the devices you carry can share a single configuration. When picking a route, prefer a node in the same region as the service you are reaching — for AI tools that need an international route, use a region they support rather than tapping the first item in the list.
Protocols: those English abbreviations decide how data is packaged
The protocol decides how data is packaged, encrypted and disguised. That column of English abbreviations in the client is exactly this. The same route can carry different protocols, so “this node is slow” is sometimes not the route's fault but the chosen protocol being interfered with on that network.
| Protocol | Underlying transport | Key traits | Common pitfalls |
|---|---|---|---|
| Shadowsocks | TCP, with UDP layered on depending on implementation | Lightweight, simple handshake, low overhead | Recognisable by traffic patterns when it has no TLS front |
| VMess | TCP / WebSocket / gRPC | Mature ecosystem, many transport combinations | Large clock skew makes authentication fail outright |
| VLESS | TCP + TLS | No encryption baggage, low CPU cost, good for high bandwidth | Depends on TLS and fallback configuration; misconfigure it and nothing connects |
| Trojan | TLS, usually on port 443 | Looks like ordinary HTTPS, inconspicuous under passive probing | Depends on the domain and certificate; an expired certificate breaks it |
| Hysteria2 | QUIC / UDP | Built-in congestion control, good throughput on long lossy paths | Degrades noticeably where UDP is rate-limited |
| TUIC | QUIC / UDP | Multiplexing, suits many small requests | Also depends on UDP; sensitive to server-side parameters |
When you need to switch protocol by hand
Most of the time you don't: server and client negotiate from the configuration written in the subscription, and the client just executes it. There are three cases where manual intervention helps — when UDP is rate-limited or blocked, the QUIC-based Hysteria2 and TUIC degrade noticeably and a TCP-based protocol is steadier; when the TLS handshake is interfered with, TLS-dependent protocols such as Trojan and VLESS struggle to connect and need a different transport or port; when the client clock is out of sync, VMess authentication fails.
Split tunneling vs global: which traffic needs the route
Split tunneling (also called rule mode) decides which traffic goes through the route and which goes direct. Nearly every client groups the modes into three, with much the same names: global, rule, direct.
- Global mode: all traffic goes through the route, including domestic sites and LAN devices. Simplest to set up, at the cost of domestic sites taking a detour — slower, and it burns through data faster.
- Rule mode (split tunneling): matches by domain, IP range, GeoIP country database and process name, one rule at a time; whatever matches takes that path, and anything unmatched falls to the final rule.
- Direct mode: nothing goes through the route — the same as temporarily turning the proxy off.
The value of split tunneling is sending out only the traffic that needs to go out. Domestic sites going direct saves data and one detour; LAN and private addresses going direct keeps NAS boxes, printers and screen casting from failing.
- ✅ Day to day, start with rule mode: domestic domains and private addresses direct, everything else through the route as needed.
- ✅ Prefer the client's built-in rule sets, and when something breaks, check the connection log to see which rule matched.
- ✅ Give services that need a fixed exit their own rule instead of sharing a node with everyday browsing.
- ❌ Don't treat global mode as “more secure”: it only sends all traffic out, the encryption strength does not increase.
- ❌ Don't hand-write dozens of overlapping rules — the more rules, the harder the troubleshooting.
DNS leaks: do lookups follow the tunnel?
The first step in opening a page is resolving the domain. If the lookup goes to your local ISP's DNS instead of out through the tunnel from the landing side, that is a DNS leak. Two consequences: the answer can be poisoned, handing you a wrong IP; and your browsing intent is exposed on the local network.
The DNS-related switches in a client are usually these:
- Remote DNS: lookups go through the route and are resolved at the landing side;
- DNS over HTTPS / TLS: encrypts the DNS query itself so it cannot be rewritten in transit;
- Domain sniffing: pulls the target domain from the SNI field of the TLS handshake so split rules can match it;
- Fake DNS: the client hands back a fake IP to take over the connection, and the proxy side restores the real domain.
Checking is straightforward: connect through a route, open a public DNS leak test page, and see whether the resolver region it reports matches the region where the node lands. If they differ, lookups are still going out locally.
Note: reconnect after changing DNS settings — most clients do not apply them live. Changing them without re-testing is the same as not changing them.
Client differences: the switches are not in the same place on five platforms
The same subscription shows identical node names on all five platforms, but split rules, DNS settings and proxy mode are local to the client, so a new client means configuring them again. How each platform takes over traffic differs quite a bit:
| Platform | How it takes over traffic | Watch out for |
|---|---|---|
| Windows | System proxy or TUN virtual adapter | Apps that ignore the system proxy need TUN mode to be captured |
| macOS | System proxy + network extension | Authorisation is required the first time; managed devices may be restricted by policy |
| iOS | System VPN configuration (network extension) | Imported as a configuration profile; per-app proxying is limited |
| Android | System VPN service | Supports per-app proxying — routing only the selected apps saves data |
| Linux | Command-line client + kernel forwarding | Configuration is file-based; TUN forwarding needs root |
Putting the terms together: the full sequence of one connection
Following the order above, a normal connection looks like this:
- The client fetches the node list from the subscription link and decodes it into individual configurations;
- You pick a node, and the client opens a connection using the protocol and transport in that configuration;
- Once connected, the client reads the split rules and decides whether this request goes through the route or direct;
- Requests that take the route go to the landing side, and the landing data centre makes the actual request;
- Domain resolution follows the DNS settings — remote DNS means no leak, local DNS means one;
- Data returns the same way, and the client hands the result back to the app that asked for it.
When something breaks, work backwards in this order: check which rule matched (step 3) first, then DNS (step 5), and only then suspect the node itself. In the vast majority of “connected but pages won't load” cases the problem is split tunneling or DNS, not the route.
To try before deciding, start with the monthly plan at ¥9.9 for 60GB; if you need more data without a monthly clock, the ¥158/300GB data pack lasts until it runs out and never expires. Creating an account needs only a username and password — no email address — and a full refund can be requested within 60 days of the first payment.