This VPN glossary for beginners starts with a common point of confusion: “subscription, node, protocol, split tunneling and global mode” may appear side by side in a client, but they belong to different layers. A subscription delivers configuration, a node is a selectable entry or exit point, a route describes where data travels, a protocol defines how the client communicates with the server, and the routing mode determines which requests use that path.
It is easier to picture them as one journey: a subscription link is like an updateable route guide, nodes are stops, direct connections, relays or dedicated routes are the paths, the protocol is the communication rule used by the vehicle and road, and routing rules are the navigation system deciding which segments use a fast route and which stay on local roads. Once the layers are clear, most client settings become straightforward.
What are subscriptions, configurations and nodes?
A subscription link is an updateable configuration index
A subscription link is usually generated in the provider dashboard. When a client accesses it, the client retrieves a set of server configurations that may include an address, port, protocol, transport, authentication details and node names. It is not an ordinary information page but a configuration entry point with access permissions, so it should not be posted in forums, screenshots or public documents.
“Import subscription” and “connect to a node” are two separate actions. Importing only tells the client which configurations are available; data transmission begins after you select a node from the list and start the connection. Some clients refresh subscriptions periodically, while others update only when prompted. If the provider changes an entry point but the local list still shows old data, updating the subscription is usually more effective than repeatedly switching among outdated nodes.
A single-node configuration is not the same as a subscription
A single-node link describes one configuration and is useful for a temporary import or focused troubleshooting. A subscription link centrally maintains a group of nodes; after the server updates them, the client can sync the changes by fetching the subscription again. If a beginner sees “import successful” but cannot find new nodes, check whether the open group is a subscription group or a local configuration, and confirm that the client is not using cached data.
A node name is a label, not the complete topology
Names such as “Tokyo,” “Singapore” and “Los Angeles” usually indicate an exit location, an entry location or a provider’s route label; they cannot reveal the entire path by themselves. A relay node labeled Tokyo may first connect to a nearby entry point and then use an optimized route to a Tokyo exit. A direct node usually connects the device straight to a remote server.
- ✅ After importing, update the subscription first, then check whether the node list has changed.
- ✅ Treat the subscription link as an access credential and keep it only on trusted devices and in trusted clients.
- ✅ After switching nodes, verify the configuration currently shown by the client instead of checking only which item is selected in the list.
- ❌ Do not assume “import successful” means the network connection is already active; the connection toggle still needs to be enabled separately.
- ❌ Do not infer the route type from a city label alone; refer to the provider’s route details.
Direct connections, relays and IEPL dedicated routes
Route type answers the question, “How does data travel from the device to the exit?” It is related to, but not interchangeable with, the protocol: the same protocol can run on a direct route, a relay path or a dedicated route. The protocol handles connection and encapsulation; the route handles how the underlying network carries the data.
| Route type | Typical path | Common characteristics | Metrics worth watching |
|---|---|---|---|
| Direct | The device connects directly to a remote entry point or exit | A simple structure whose performance depends heavily on the local carrier and international network path | Handshake quality, peak-hour fluctuations, packet loss and route changes |
| Relay | The connection reaches a nearer entry point first, then forwards traffic to the target exit | Can avoid some less favorable public-network segments, but both the entry point and relay path affect the result | Distance to the entry point, forwarding stability, exit load and return path |
| IEPL dedicated route | An enterprise-grade dedicated route carries traffic between the entry point and the endpoint outside the local network before connecting to the target network | The core cross-border segment relies less on ordinary public-network detours and generally prioritizes route consistency | Access quality, dedicated-route coverage, exit-side networking and failover |
Direct does not automatically mean slow, and relay does not automatically mean fast. If the device has a good path to a remote entry point, a direct connection can be simple and effective. If the public international path is unstable, a well-designed relay may be steadier. IEPL describes how traffic is carried between entry points; it does not mean every segment from the device to the final website uses a dedicated route. Access to the entry point and the path from the exit to the target service still use their respective networks.
How to understand common protocol names
A protocol defines how the client and server authenticate, encrypt, encapsulate and transmit data. Beginners should not treat protocol names as a speed ranking. UDP availability, support in the system kernel, transport settings, server load and the underlying route can all change the result. The descriptions below help you understand client options rather than assign permanent rankings to protocols.
Shadowsocks
Shadowsocks is a lightweight encrypted proxy protocol. Its configuration usually consists of a server address, port, encryption method and password. It has broad implementations and good client compatibility, making it suitable for ordinary web and app split tunneling. It does not decide which domains connect directly; the client’s rules handle routing.
VMess and VLESS
VMess includes identity authentication and time-related checks, so clock drift can cause a handshake to fail. VLESS is designed with a leaner protocol layer; its practical security and transport performance depend heavily on the outer TLS layer, transport method and server configuration. When you see VLESS, check whether it is paired with TLS, WebSocket or another transport instead of looking at the protocol name alone.
Trojan
Trojan usually runs over TLS, giving the connection a shape similar to ordinary encrypted web traffic. It depends on certificates, domains and server settings working together correctly. An expired certificate, incorrect system time, DNS resolution failure or interference along the path can all appear as a handshake failure, so troubleshooting should go beyond changing the password.
Hysteria2 and TUIC
Hysteria2 and TUIC both emphasize QUIC- and UDP-based transport and may maintain strong throughput and responsiveness on networks with some packet loss or jitter. If the current network strictly restricts UDP, however, these protocols may fail to connect or perform worse than a working TCP path. When web-oriented protocols work but QUIC-based protocols do not, first check UDP support on the network rather than assuming the node has failed.
| Protocol | Primary transport characteristics | Troubleshooting focus | How to choose |
|---|---|---|---|
| Shadowsocks | Lightweight encrypted proxy with broad implementation support | Encryption method, port, authentication details and split-tunneling rules | Prioritize client compatibility and a simple configuration |
| VMess | Includes identity and time-related checks | System time, transport layer and identity details | Suitable where a mature server configuration is already available |
| VLESS | A lean protocol layer, often paired with TLS | TLS, domain, transport method and server parameters | Evaluate the complete transport configuration rather than the name alone |
| Trojan | Usually establishes connections over TLS | Certificate, DNS resolution, system time and port | Suitable for networks where the TLS path works normally |
| Hysteria2 | QUIC- and UDP-based, with an emphasis on efficient transport | UDP reachability, congestion control and local network restrictions | Suitable when UDP conditions are good or the network is prone to fluctuation |
| TUIC | QUIC- and UDP-based, with support for concurrent transport | UDP reachability, certificates and client implementation | Choose based on platform support and current network conditions |
Split tunneling, rules, global and direct modes
Mode switches determine where traffic goes. Many beginners interpret “global” to mean that every piece of device traffic enters the tunnel, but this depends on how the client takes control. With only a system proxy enabled, only apps that follow system proxy settings are handled; with TUN enabled, the client can usually process more system-level traffic, though platform permissions, protocol type and exclusion rules still matter.
Rule mode
Rule mode directs traffic by matching domains, IP addresses, apps or rule sets. International websites can use the selected node, local services can stay direct, and ad domains can be rejected according to rules. It suits everyday use, but timely rule updates are essential: changes in domain ownership, content delivery networks or an app’s new endpoints can all cause mismatches.
Global mode
Global mode usually sends all traffic the client can take over through the current node, making it useful for checking whether a rule is misclassifying traffic. If a service fails in rule mode but works globally, the issue is often a rule match, a DNS result or an app that was not properly intercepted. After troubleshooting, return to rule mode so local services do not unnecessarily use a remote exit.
Direct mode
Direct mode does not use a remote node. It is useful for pausing the proxy while keeping the client running, or for checking whether the issue comes from the local network. If both direct access and the proxy fail, the problem may not be on the route side; local DNS, browser cache, system networking or the target service itself may be responsible.
System proxy and TUN
A system proxy mainly provides an HTTP or SOCKS proxy entry point. Browsers and apps that follow system proxy settings can connect easily, but some apps bypass it. TUN creates a virtual network interface and captures more traffic at the system network layer, making it more effective for apps that do not read proxy settings. The trade-off is that it requires the relevant system permissions and may conflict with firewalls, enterprise networking tools or other virtual interfaces.
Why DNS leaks and resolution paths matter
Before accessing a domain, a device usually looks up its address through DNS. If application traffic enters a remote node while DNS queries still go to a resolver on the local network, the DNS path and access path may diverge. The result is not necessarily limited to a privacy concern: the target service may return an address unsuitable for the current exit region, or split-tunneling rules may receive an incorrect resolution result.
“Remote DNS,” “local DNS,” “encrypted DNS” and “sniffing” handle different stages in a client. Remote DNS generally resolves domains that need proxying through a remote path; local DNS is often used for local services and direct domains; encrypted DNS protects queries between the device and resolver; domain sniffing attempts to recover a domain from connection data to help rules determine the route. Sniffing is not a replacement for DNS and cannot fix every app’s resolution behavior.
A browser’s built-in Secure DNS may bypass the system resolver specified by the client, or it may be correctly captured by TUN, depending on the client implementation and routing configuration. If the same website behaves differently in a browser and another app, check the browser’s Secure DNS, system DNS and client logs separately instead of simply changing nodes.
- ✅ Confirm that proxied and direct domains use resolution paths consistent with the intended rules.
- ✅ Check whether the browser has independent Secure DNS enabled and whether the request is being handled by the client.
- ✅ After changing DNS settings, clear the old cache and establish the connection again.
- ✅ Compare rule mode with global mode to determine whether the issue comes from domain matching.
- ❌ Do not treat a changed exit address as the only proof that DNS is being handled correctly.
Why client switches differ across platforms
After importing the same subscription on different platforms, node names may match, but interception methods and permission models do not. Windows clients often offer both a system proxy and TUN; macOS typically relies on system network extensions or proxy settings; Android creates a virtual network through the system VPN interface; iOS and iPadOS use the network extensions and configurations permitted by the system.
Therefore, “works on desktop but not on mobile” does not necessarily mean the subscription is faulty. Mobile systems may restrict background activity and may need to rebuild the tunnel after a network change; desktop systems are more likely to be affected by firewalls, antivirus software, enterprise settings or other virtual adapters. Platform differences also affect app routing: some clients support selection by process or app, while others can handle only domain and IP rules.
The client core version also determines which protocols and fields it can recognize. An older core encountering newer Hysteria2, TUIC or VLESS transport settings may import them but fail to start, or ignore unknown fields entirely. Updating a subscription does not automatically upgrade the client core; when a configuration exists but startup reports an error, check both the client version and the documented protocol support.
The complete workflow from import to connection
- Copy the subscription link from the user dashboard. Do not manually remove or alter any characters, and do not paste the link into a public online conversion tool.
- Choose a client that matches the platform and supports the target protocol. If the subscription includes Hysteria2 or TUIC, confirm that the client core supports the relevant configuration.
- Use “Import from URL” or “Add subscription.” After importing, run an update once and confirm that the node list has loaded.
- Start with a node suited to the distance and intended use. Do not sort by a single latency probe alone; use the descriptions of direct, relay or IEPL routes as additional context.
- Use rule mode for everyday activity. If a particular app is not being handled, check the system proxy, TUN permissions and app routing.
- Verify the actual path after connecting. Confirm that the exit location, DNS resolution and target app behave as expected instead of relying only on the client’s “connected” status.
- Troubleshoot layer by layer. Update the subscription first, then switch nodes, compare rule and global modes, and finally check the protocol, DNS and system permissions.
The judgments beginners confuse most often
More nodes do not mean more protocols. A node group may use one protocol throughout, or the same exit may offer entry points for several protocols. A node describes a location or endpoint; a protocol describes the communication method. Neither replaces the other.
Connected does not mean every app is being handled. A successful client handshake proves only that a channel from the device to the server was established. Whether an app uses that channel also depends on the system proxy, TUN, the app’s own proxy settings and routing rules.
Global mode does not mean every underlying packet unconditionally enters the node. The client can handle only traffic permitted by the system and supported by the client. Local-network access, excluded apps, special protocols or other virtual interfaces may still take different paths.
A dedicated route does not mean every segment end to end uses a private network. IEPL mainly describes dedicated transport between entry points; the device-to-entry and exit-to-target paths still use their own networks. Evaluate the complete route instead of relying on the route label alone.
Low latency does not mean stable sustained transfer. Probe packets are tiny, while video, downloads and meetings continuously use the route. Packet loss, jitter, congestion control and exit quality often explain real-world performance better than a single latency reading.