This VPN glossary for beginners starts with a practical question: what do subscriptions, nodes, protocols, and split tunneling each do in a VPN client? A subscription provides configuration details; a node is a connection endpoint you can choose; a protocol determines how the client communicates with that endpoint; and split tunneling decides which traffic uses the connection. Understanding them separately makes setup and troubleshooting much easier.
A subscription provides configuration; it doesn’t connect you to a route
A subscription is usually a link provided by your VPN service. The client reads it to display available nodes and related settings; pasting the link into the app does not connect you to the network. Most clients also require you to update the subscription, choose a node, and start the connection manually. The option may be called “Add subscription,” “Import configuration,” or “Import from URL.” The wording varies, but the purpose is the same.
A subscription link may contain information needed to access your configuration, so treat it like a credential. Copy it from your service’s website and paste it into your chosen client; don’t post it publicly or include it in screenshots. Updating a subscription reloads its configuration, but may not switch your current node. If the list still shows old entries, first make sure you imported a subscription link rather than a one-time configuration file, then check whether the client has a separate “Update” option.
- Get the subscription link from your service’s website, then choose “Import from URL” in a supported client.
- Update the subscription, check that the node list appears, then choose a node that fits your needs.
- Connect and open the website you want to visit. If it doesn’t work as expected, check the mode and exit IP.
After logging in, you can find VPNTF’s client options under Get the client. For your first setup, import the configuration and connect before adjusting split-tunneling rules. Changing several settings at once makes it harder to identify the cause of a problem.
What do nodes, regions, and route types mean?
A node is a connection endpoint you can choose from your client’s list. The country or city shown usually indicates the exit region, but a location label doesn’t guarantee that a website will serve content for that region. Sites may also consider your account region, location permissions, and other details. To check your current network exit, open IP Check after connecting and compare the results with and without the connection.
A route type describes how traffic reaches its exit point; it is not another name for a protocol. “Direct” usually means the client connects straight to the destination endpoint. “Relay” routes traffic through an intermediary before it reaches the exit. An IEPL dedicated route refers to a type of cross-border transmission resource. These terms describe the path, not whether the client uses Shadowsocks, Trojan, or another protocol. Different paths may be available in the same region, so a location label alone won’t tell you how a route performs during peak hours.
| Client setting | What it tells you | What to check first |
|---|---|---|
| Subscription | Where configuration comes from and how to update it | Whether the link imported and refreshed successfully |
| Node | Which endpoint to use for this connection | Whether the exit region meets your needs |
| Route type | How traffic reaches the exit point | Whether direct, relay, or dedicated routing fits your needs |
| Protocol | How the client communicates with the endpoint | Whether the client supports the configuration |
| Routing mode | Which requests use the selected route | Whether traffic to the destination follows the intended path |
When choosing a node, start with the region required by the service you want to access, then test a site you use regularly. If a webpage loads but a video or login doesn’t work, don’t assume the route is down: the platform’s regional requirements, account status, and access rules may also affect the result. Use the Route list to browse available regions, then judge by your own results.
Protocols define how connections work, not the whole experience
Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC may appear in a client or subscription details, but the name alone doesn’t tell you which route will be faster. Shadowsocks is a proxy protocol. VMess and VLESS use different message and authentication designs; VLESS does not encrypt traffic by itself, so consider the transport and security settings alongside it. Trojan is often paired with TLS, while Hysteria2 and TUIC use QUIC-based communication. Whether a setup works also depends on the client version, server configuration, and current network conditions.
Beginners usually don’t need to guess ports, keys, or transport settings manually. After importing a subscription, check whether the client recognizes the nodes correctly. If you see “unsupported protocol” or a parsing error, consult the client documentation and your service’s configuration guide. Copying settings for one protocol into another protocol’s form usually won’t establish a connection. If your client offers “Auto select,” check whether it selects a node or a routing mode—they’re two different settings.
Protocols establish communication, route paths determine where a connection travels, and destination services have their own access requirements. All three can affect the result. When troubleshooting, check in this order: can the configuration be imported, can the node connect, and where is traffic to the destination going? This is more effective than cycling through protocol names.
Choosing between split tunneling, global, and rule-based modes
Split tunneling directs traffic based on conditions such as domains, addresses, or apps. Clients commonly offer rules mode and global mode. Rules mode uses existing rules to decide which requests use the route and which connect directly. Global mode generally sends requests handled by the client through the selected route by default. “Global” is still subject to system proxy permissions, client capabilities, and how each app handles networking; it doesn’t mean every packet on the device automatically follows the same path.
For everyday use, start with rules mode, open the site you want to visit, and check your exit IP. If the site doesn’t work but the node connects, temporarily switch to global mode for comparison. If global mode works and rules mode doesn’t, check the rule match or DNS resolution path. After testing, choose the mode that suits your regular use; there’s no need to leave troubleshooting settings enabled.
- ✅ Make sure the client shows “Connected” before testing the destination website.
- ✅ In rules mode, check whether the destination domain matches the intended rule. Switch to global mode temporarily for comparison if needed.
- ✅ Reload the page after changing modes so you don’t mistake results from an old connection for results under the new rules.
- ❌ A connected node doesn’t mean every app is using it.
Some desktop clients offer both “System Proxy” and a routing option such as “TUN.” System Proxy mainly relies on apps following the operating system’s proxy settings. TUN uses a virtual network interface to handle more types of traffic, though its actual coverage still depends on system permissions and the client’s implementation. If an app isn’t following the rules, check not only the node but also which routing method is enabled.
Checking DNS and your exit IP: where requests go after you connect
DNS translates domain names into addresses that can be reached over a network. A “DNS leak” usually means that DNS requests you expected to follow the selected route are actually sent over another network path. This can affect how your region is detected or prevent sites from loading in rules mode. Note that an IP-check page shows your web traffic’s exit IP; it doesn’t check the DNS resolution path. A matching exit IP alone doesn’t prove that DNS requests are following the intended route.
To troubleshoot, first check how your client’s DNS settings work with its routing mode. Then compare results when disconnected, in rules mode, and in global mode. If only one app has a problem, check whether it uses its own DNS or bypasses the system proxy. Reconnect and try again after changing settings so cached DNS results in your browser don’t skew the test. Don’t copy unfamiliar rule files or DNS settings without checking which domains they send along which paths.
Client options and system permissions vary across Windows, macOS, Android, and iOS. A button labeled “Connect” may enable the system proxy on one platform, while another may ask for permission to configure the network. If you can’t find a setting shown in a screenshot from another platform, check your current client’s connection status, mode description, and permission prompts instead of assuming the setting has the same name.
Quick-reference takeaway: troubleshoot one layer at a time based on what you can access
For your first setup, understand the client in this order: subscription, node, protocol, and routing. The subscription imports configuration into the client; the node is the endpoint you choose; the client must support the protocol; and routing determines whether a request uses the selected route. Once connected, check the exit region and test the sites you need. If something goes wrong, change one setting at a time to identify which layer is affecting access.
If you’re still comparing plans, start with your typical data use and needs rather than treating a protocol name as a promise of price or performance. VPNTF monthly plans include ¥9.9 / 60GB, ¥18 / 250GB, and ¥28 / 500GB; non-expiring data packages are also available. See the Plans & Pricing page for current options. You only need a username and password to create an account—no email address required. For refund terms, see the 7-day refund policy listed on the page.