VPN Glossary for Beginners: Subscriptions, Nodes, Protocols and Routing Explained

Open a client and you may see subscriptions, nodes, protocols, system proxy, global mode, rule mode and DNS all at once—a bit like boarding a spacecraft whose buttons are labeled with acronyms. In reality, this VPN glossary for beginners has one central idea: the subscription delivers configuration, nodes provide connection entry points, protocols define communication, and routing decides which requests take which path. Most other settings simply support that flow.

These terms are often used interchangeably, but they describe different things. More nodes do not necessarily mean faster routes, a newer protocol is not automatically better for the current network, and global mode is not a “performance boost” button. Put each term in the right mental drawer first, then troubleshoot the connection; it is far more effective than switching settings at random.

What Are Subscriptions, Subscription Links and Configuration Files?

A subscription is not a route by itself. It is a set of connection configurations maintained by the service. It may include node names, server addresses, ports, protocols, authentication details and transport parameters. Once the client reads these settings, it can display the available nodes.

A subscription link is the address used to retrieve that configuration set. Paste it into a compatible client, and the client requests the remote content and converts it into its own node list. When the service updates its routes, you normally need to select “Update Subscription” in the client or wait for its scheduled refresh. Importing it once does not mean the local list will stay current forever.

A configuration file is another way to deliver settings. It may be plain text or a file that the client can read directly. A subscription link is designed for ongoing updates, while a standalone configuration is more like a static snapshot of one connection. Both describe “how to connect”; the main difference is how they are updated and organized.

What Happens When You Import a Subscription?

1. The client requests the subscription address and receives the configuration returned by the service.
2. The client parses the supported protocols and fields, then generates a local node list.
3. You choose a node, and the client establishes a connection using its corresponding protocol.
4. Whether system traffic enters that connection also depends on system proxy settings, the virtual network interface and routing configuration.

So “subscription imported successfully” only means the client understood the configuration. It does not mean the selected node is connected, nor that every app has started using the connection. Importing, connecting and taking over traffic are separate stages. If the client reports an unsupported format, common causes include an incompatible protocol, the wrong subscription type, an incomplete link, or temporarily unavailable subscription content.

• ✅ The subscription name and node list appear in the client
• ✅ Manual subscription updates complete without parsing errors
• ✅ A clear connection status appears after selecting a node
• ✅ Traffic from the browser and target app follows the current mode
• ❌ Assuming all traffic is covered simply because node names are visible

Nodes, Servers and Routes Are Not Synonyms

A server is a physical or virtual computing resource; a node is a connection configuration that the client can select; a route describes the network path data takes from your device to its egress point. One server can host multiple node configurations, and nodes with different names may share part of the same infrastructure. The client shows an entry-point menu, but the full path cannot always be inferred from the name.

Node names often include region, entry point, egress, bandwidth multiplier or route labels. A region usually indicates the egress location, but naming conventions are set by the service provider. When checking your apparent access location, rely on an actual egress test rather than treating the node name as proof of the network location.

A so-called latency test is usually just a quick probe that the client runs against a node. Different clients may measure connection setup, web response time or a simple probe packet, and the result cannot be treated as download speed. Latency is useful for filtering out clearly unreachable nodes; throughput, packet loss, jitter and peak-hour performance require real-world use or separate testing.

A node list is like a station departure board: it tells you where you can board, but not every section of track along the way. Actual route quality depends on the path and sustained performance after connection.

What Do Protocol Acronyms Actually Define?

A protocol defines how the client and server authenticate, package and transmit data. It affects compatibility, traffic characteristics, resilience to network changes and deployment requirements, but it cannot magically fix a congested route. Think of a protocol as a train standard: it must match the track, and when the track is blocked, a shinier locomotive will not get through the wall.

Shadowsocks

Shadowsocks is an encrypted proxy protocol known for its relatively simple design and broad client ecosystem. It generally handles application-layer proxy traffic and is not inherently the same as taking over the entire system like a traditional VPN. Whether all apps can use it depends on system proxy settings, virtual network interface mode and routing support.

VMess and VLESS

VMess is a common authentication and transport protocol in the V2Ray ecosystem, and its configuration is often paired with an underlying transport and security layer. VLESS uses a lighter authentication model and does not provide content encryption by itself; deployments typically combine it with TLS, REALITY or another secure transport method. When you see VLESS, check the transport, security and server-name fields rather than judging the protocol name alone.

Trojan

Trojan typically runs over TLS, making its connection resemble ordinary encrypted website traffic. It relies on certificates, domains and TLS parameters working together correctly. Incorrect system time, certificate validation or server-name settings can cause a handshake failure. Disabling verification may hide the error temporarily, but it is not recommended as a long-term troubleshooting method.

Hysteria2 and TUIC

Hysteria2 and TUIC both build on QUIC and UDP transport, with an emphasis on improving transmission over networks with high latency, packet loss or frequent changes. Both the client and server must support them, and the current network must allow the required UDP traffic. If a network handles UDP poorly, these protocols may fail to connect; switching to a compatible TCP-and-TLS option is often a better way to isolate the problem.

System Proxy, Virtual Network Interfaces and Traffic Capture

After a client shows “Connected,” traffic still has to be sent through its local proxy core. Common methods include system proxy and virtual network interface mode. These determine which programs hand requests to the client; they are a separate layer from the protocol used by the remote connection.

A system proxy changes the operating system’s proxy settings. Browsers and apps that respect those settings can usually use the connection, but programs that create their own network stack, ignore the system proxy or send UDP directly may bypass it. That is why a browser can work while one app spins forever: it is not cosmic radiation, just a different door.

Virtual network interface mode is often labeled TUN. It uses a virtual network interface provided by the system to capture a broader range of IP traffic, which the client then handles according to its rules. Coverage is usually more complete than with a system proxy, but conflicts with firewalls, other network tools, enterprise security software or existing virtual interfaces are also more likely. System permission may be required.

How Global, Rule and Direct Modes Route Traffic

Routing uses domains, IP addresses, apps or rule sets to decide where requests go. Common destinations are proxy, direct connection and blocking. It does not change the node itself; it manages traffic before requests reach the node.

Global mode generally sends as many client-captured requests as possible through the selected node. It is useful for temporarily checking whether a node can reach a target service and for ruling out rule-matching problems, but it does not mean every piece of data on the operating system enters the connection. Client coverage, local-network traffic and system components may still be exceptions.

Rule mode chooses proxy or direct connection according to preset or custom rules. A common setup sends local services direct, routes international destinations through a proxy, or assigns paths per app. Rule mode is better suited to everyday use, but outdated rules, incorrect domain classification or overlapping rules can send a target website through the wrong egress.

Direct mode normally bypasses the remote node and uses the current local network. It can help determine whether a problem is caused by the proxy path and confirm whether an app is actually controlled by the client. If switching to direct mode changes nothing, the app may not be captured by the client at all, or an old cached connection may still be open.

Request enters the client
├─ Matches a direct rule → Use the local network
├─ Matches a proxy rule → Send it to the current node
├─ Matches a blocking rule → Block the request
└─ Matches no rule → Use the client’s final rule

Rules usually have a matching order. More specific rules should appear where they can take priority, while the final rule catches requests not identified earlier. If changing a rule has no effect, close and reopen the target app so it creates a new connection; clear the DNS cache if necessary.

• ✅ Use global mode temporarily to verify that the node can reach the target service
• ✅ After verification, return to rule mode and check the matching result
• ✅ Check the target domain and final destination in the client connection log
• ✅ Re-establish the target app’s network connection after changing rules
• ❌ Treating global mode as a switch that unconditionally increases speed

DNS, DNS Leaks and Domain Resolution

DNS converts domain names into addresses that can be reached. After you enter a domain in a browser, the system or client must resolve it before starting the connection. If the node works but DNS resolution fails, the domain may not open even though a direct request to a known address responds.

Remote DNS is usually handled by the proxy side or a specified encrypted DNS service, while local DNS uses the resolution path provided by the current network. A split-routing client may handle different domains according to separate rules to support both local services and international websites. If DNS queries use the local network while the actual request uses a remote node, the result may not suit that egress and could expose queries that were meant to follow the proxy path.

A DNS leak usually means DNS queries that should use a controlled path bypass the client and go to a resolver on the local network. It is not the same as an IP leak. Key checks include enabling the client’s DNS capture, confirming the resolution path in virtual network interface mode, preventing apps from using resolvers outside the rules, and checking whether the browser’s built-in secure DNS conflicts with the client policy.

Why Do Clients Look Different on Each Platform?

The same subscription may show different settings and protocol support on different platforms. This usually is not the subscription changing on its own; operating-system capabilities, client cores and app permissions differ.

Windows clients often provide both system proxy and TUN modes. System proxy is straightforward to start with, while TUN covers more traffic but requires attention to administrator permissions, drivers, the system firewall and other network tools. macOS clients commonly rely on system network extensions or proxy settings and request authorization the first time they are enabled. Until authorization is complete, importing nodes in the interface will not actually capture traffic.

On iOS and iPadOS, clients usually capture network traffic through the system VPN configuration. After importing a subscription, allow the configuration to be added and confirm that the connection is established in the system status. Platform rules mean that protocol, script and routing support can vary between clients; do not assume every desktop option will appear unchanged.

Android clients generally use the system VPN interface and can set whether each app goes through the connection, but the exact features depend on the client. If battery-saving policies restrict background activity, the connection may drop when the screen locks or the network changes. On Linux, command-line tools, service processes and manual configuration are more common; system proxy and route capture often need to be configured separately.

When choosing a client, first confirm support for the subscription’s protocols and transport parameters, then check system proxy, TUN, rule editing, subscription updates and logging. Comparing only how flashy the interface looks can leave you with a spacecraft whose dashboard glows but whose engine cannot understand the configuration.

What Troubleshooting Order Should Beginners Follow?

Connection problems are hardest to diagnose when you change the protocol, switch nodes, reinstall the client, adjust DNS and clear every rule at the same time. You may recover, but no one will know which step helped. Reproducible troubleshooting should move from the outside in, changing only one variable at a time.

1. Check the local network: Temporarily disable the client and see whether ordinary websites open directly.
2. Update the subscription: Confirm that the subscription can be fetched and that the node list has no parsing errors.
3. Switch nodes: Keep the same protocol and mode while changing nodes to distinguish a single-node failure from a broader configuration problem.
4. Check protocol compatibility: Confirm that the client supports the relevant protocol, transport and security parameters.
5. Switch the capture method: If the browser works but other apps fail, focus on the system proxy and TUN.
6. Temporarily use global mode: If global mode works but rule mode does not, the problem is likely in the routing rules or DNS path.
7. Read the logs: Look for clear messages about resolution failures, connection timeouts, TLS handshakes, authentication failures and routing conflicts.

“Timeout” in a log means that no response arrived within the waiting period; possible causes include an unreachable node, packet loss or firewall restrictions. “Authentication failed” points more toward mismatched credentials or configuration. “TLS handshake failed” calls for checks of system time, server name, certificate and security parameters. “Address already in use” commonly indicates a local port conflict. Wording varies by client, but the fault layers are broadly similar.

Once these terms make sense, the client interface is no longer a wasteland of acronyms: the subscription delivers configuration, nodes provide entry points, protocols establish communication, the system proxy or virtual interface captures traffic, routing rules decide where it goes, and DNS finds the destination address. When something fails, checking each layer along the data path is far more reliable than toggling everything blindly.