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

When you first open a VPN client, the hardest part is usually not clicking Connect—it is understanding what subscriptions, nodes, protocols, routing, global mode, and rule mode each control. They operate at different levels: a subscription delivers configuration, a node is a connection endpoint, a protocol defines client-server communication, a route describes the network path, and routing mode determines which requests use it.

Think of the process as a delivery network. A subscription is a continuously updated address book, nodes are optional transfer points, the protocol is the agreed packaging method, the route is the road the data actually takes, and routing rules are the dispatch plan. Put these ideas back into the connection flow, and a crowded client interface becomes a clear data chain.

Core Terms at a Glance: What Each Option Controls

The key distinction is between “configuration” and “traffic.” Subscriptions, nodes, and protocols belong to connection configuration; routing, global mode, and rule mode govern traffic handling. A successful connection only means a channel exists between the client and the remote endpoint. It does not mean every app is using that channel, or that DNS requests are taking the expected path.

Subscriptions and Nodes: An Address Book Is Not a Connection Endpoint

What a Subscription Link Delivers

A subscription link usually points to configuration content that a client can read. After accessing it, the client parses the response into a node list or configuration file. Supported subscription formats vary by client: some recognize common share links directly, some require a specific configuration structure, and some also deliver rule sets, proxy groups, and DNS parameters.

A subscription link is not an ordinary webpage bookmark or merely a download button. It may contain server addresses, ports, protocol credentials, transport methods, and node names, so store it like an access credential. Posting it in a screenshot, log, or support request could expose an entire set of connection settings.

“Update subscription” means that the client reads the remote configuration again. After an update, nodes added, removed, or adjusted on the server are reflected locally. Some clients overwrite manual changes to subscribed nodes, so persistent local rules should be kept in the client’s supported overrides, config snippets, or separate rule area instead of editing generated nodes directly.

1. Copy the subscription link: Get a link matching the client’s format from the service panel; do not transcribe it manually from a chat screenshot.
2. Choose an import method: In the client, use “Import from URL,” “Add subscription,” or a similarly named option.
3. Run the update: Wait for the client to finish parsing, then confirm that the node list appears—not just an unloaded subscription name.
4. Choose a node: Start with the exit region and purpose, then adjust for route type and current network performance.
5. Enable traffic interception: Choose the system proxy or TUN according to the platform, then verify the exit and DNS with actual requests.

How Much Can a Node Name Tell You?

A node is a remote configuration that can establish a connection. Its name often indicates a region, city, route, or purpose, but the name itself does not participate in network transmission. It is more like an operations label that helps users choose a configuration. A node labeled “Japan” usually indicates an expected exit in Japan, but its name alone cannot reveal the entry point, transport path, carrier routing, or current congestion.

“Node” and “server” are not completely interchangeable. Multiple node configurations may run on the same infrastructure or use different entry points, exit points, or transport parameters. Conversely, one node may involve entry forwarding and an exit service. For users, a node is a logical connection option in the client; a server is the infrastructure that implements it.

• ✅ First, check that the exit region meets the target service’s regional requirements.
• ✅ Then check whether the route type suits the current network environment and time of day.
• ✅ After switching nodes, reopen the target connection so an old session does not continue using the previous exit.
• ❌ Do not judge the actual path solely by labels such as “high-speed” or “dedicated” in a node name.
• ❌ Do not mistake a failed subscription update for a simultaneous failure of every node.

Protocols: Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC

A protocol defines how the client packages requests, authenticates, and exchanges data with the server. Protocol names often appear alongside transport-layer, TLS, WebSocket, QUIC, and other parameters, so the same protocol can be deployed in different ways. A protocol name alone cannot directly predict speed, stability, or regional suitability; a more reliable assessment considers the protocol, transport, route, and local network together.

Strictly speaking, Shadowsocks is an encrypted proxy rather than a full VPN protocol that creates a traditional network interface. In everyday use, many clients place different proxy protocols under a unified “VPN” or “proxy” interface. That is a product-level classification and does not change how the protocol itself works.

VMess and VLESS are both common in the V2Ray-compatible ecosystem, but they are not simply old and new names for the same thing. Their authentication and protocol structures differ, so the client must import the format provided by the server. Trojan typically depends on correct TLS parameters; if the client omits a required field, the connection may terminate during the handshake before authentication.

Hysteria2 and TUIC use QUIC and UDP. On networks with packet loss, jitter, or changing bandwidth, they may behave differently from TCP-based options, provided the network allows normal UDP communication. Corporate networks, public networks, and some routing devices may restrict UDP; in that case, switching to a TCP-based configuration is usually more direct than repeatedly changing QUIC parameters.

Route Types: The Practical Difference Between Direct, Relay, and IEPL Dedicated Routes

Protocols answer “how is data transmitted?” Routes answer “where does it travel?” Even two nodes using the same protocol and targeting the same exit region can have very different latency, jitter, and packet-loss patterns because their paths differ. Choosing a node based only on its protocol while ignoring the route is like judging a vehicle without checking the road conditions.

Direct Route

A direct route means the client connects straight to the remote node’s entry point, without a forwarding entry explicitly provided by the service. The structure is simpler and involves fewer detours, but international segments depend more heavily on the local carrier and public-internet routing. A direct route that performs well on one network may behave differently with another carrier.

Relay Route

A relay route first connects to an entry point that is closer or easier to reach, which then forwards traffic to the target exit. Its purpose is not to magically shorten physical distance, but to use a more controllable entry and subsequent route to avoid poor public-internet segments. The extra forwarding step means entry capacity, the entry-to-exit path, and traffic scheduling all affect the final experience.

IEPL Dedicated Route

IEPL generally refers to an international Ethernet private-line connection that provides a more controllable dedicated transport path between locations. For subscription services, a common structure is for the user to reach a local or nearby entry point first, then travel across the dedicated segment to a remote exit. It does not mean the device connects directly to the entire private line, nor that every segment between the device and entry point leaves the public internet.

The engineering value of IEPL lies mainly in path controllability and stability across international segments. It is not tied to any particular proxy protocol: the dedicated line carries the path, while Shadowsocks, Trojan, VLESS, and others handle communication between the client and entry point. Treating “IEPL” as a protocol leads troubleshooting in the wrong direction.

Routing, Global Mode, and Rule Mode: Deciding Where Each Request Goes

Once a connection is established, the client still has to decide which traffic should use the node. That decision process is routing. Common actions include proxy, direct, and block: proxy sends the request to the current node or proxy group; direct uses the local network; block sends nothing, often for ad domains, tracking domains, or addresses that do not need a connection.

Global Mode Does Not Literally Mean “Everything”

Global mode usually means that all traffic within the client’s interception scope is sent to the proxy by default. The important qualification is “within the interception scope.” If only the system proxy is enabled, apps that follow system proxy settings are covered; apps that ignore them or create their own connections may not enter the client. With TUN enabled, the client can generally intercept a wider range of traffic at the network layer, though platform permissions, route exclusions, and LAN settings can still matter.

Therefore, seeing “Global” does not prove that all data on the device passes through the node. Verify it by checking the target app’s exit, DNS path, and client connection logs. If a browser shows a changed exit while a standalone app still uses the local network, check whether the app bypasses the system proxy and whether TUN is enabled correctly.

How Rule Mode Matches Requests

Rule mode selects an action based on conditions such as domain, IP address, geolocation database, application process, or port. Clients generally evaluate rules from top to bottom and apply the matching policy; unmatched requests follow the final rule. Order therefore matters: a broad rule placed first may prevent a later, more precise rule from ever taking effect.

Domain belongs to the target service → Proxy
Domain belongs to a commonly used local service → Direct
Address belongs to a local-area network range → Direct
Domain belongs to the blocklist → Reject
All other requests → Apply the final rule

This is not the fixed syntax of any particular client, but a decision model for understanding the logic. Rule formats vary between clients. Before copying rules, confirm the syntax supported by the current core, the policy-group names, and the DNS mode; otherwise, rules may import successfully without ever matching.

• ✅ For international services, put the relevant domains and their dependencies in the proxy policy.
• ✅ Prefer direct access for local services to avoid unnecessary detours and changes in regional detection.
• ✅ Keep LAN devices on direct access in most cases so printers, storage devices, and router admin pages remain reachable.
• ✅ After changing rules, close the old connection and test again so connection reuse does not affect the result.
• ❌ Do not permanently send every request to one policy without understanding what it does.

System Proxy and TUN: Why a Successful Connection May Not Work in Every App

A system proxy is a proxy setting provided by the operating system for apps to read. Browsers and most desktop apps that follow system network settings use it, but games, command-line tools, virtual machines, and programs with their own network stack may ignore it. System proxy setup is simple and works well for webpages and standard apps, but coverage depends on whether each app cooperates.

TUN mode creates a virtual network interface and routes traffic into the client for processing. It can cover more apps that do not support system proxies and is better suited to UDP or per-process routing. In return, TUN requires higher system privileges and may conflict with other network tools, firewalls, virtual-machine adapters, or enterprise security policies.

Some clients also offer “enhanced mode,” “virtual network adapter mode,” or similar options. These may simply be different TUN implementations. The label depends on the client interface; check whether it creates a virtual interface, handles DNS, or changes the default route instead of relying on the button text alone.

DNS Leaks and Resolution Paths: A Correct Exit Is Not the Whole Configuration

Before accessing a domain, a device usually uses DNS to resolve it to an address. A DNS leak occurs when a DNS request that should use a specified resolver or channel leaves through an unintended path instead. For example, a webpage connection may go through a proxy node while the domain lookup still goes directly to a resolver provided by the local network. This can cause regional-resolution mismatches, incorrect rule matching, or a privacy boundary that differs from what you expected.

DNS issues are not limited to leaks. If DNS returns an address suited to the local network while the connection actually comes from a remote exit, the service may load slowly or route you to the wrong region. If rules depend on domains but the client only sees resolved addresses, domain-based routing may also fail. Some clients use Fake-IP, remote resolution, or DNS interception to bring resolution into the rule engine, but capabilities depend on the client core and configuration.

During testing, separate “which exit is being used” from “which resolver is being used.” An exit check only shows where the webpage connection originates; it does not prove that the DNS path is correct. After changing a node or DNS mode, also account for caches in the operating system, browser, and app. A browser’s independent encrypted DNS setting may bypass the resolver configured in the client.

1. Confirm the interception method: Check whether the system proxy or TUN is active and whether DNS is handled by the client.
2. Clear old sessions: Close existing connections in the target app and clear the DNS cache if necessary.
3. Verify the exit: Confirm that the target request shows the expected node region.
4. Verify resolution: Check that the resolver matches the current configuration instead of looking only at the exit address.
5. Review the logs: Confirm that the domain matched the expected rule and was not captured by an earlier rule.

Cross-Platform Client Differences: Why the Same Subscription Looks Different

The subscription content can be identical, but Windows, macOS, Linux, Android, and iOS clients differ in permissions, background restrictions, and network interfaces. A client that imports a protocol does not necessarily support every transport combination for that protocol; similarly named features may be implemented by different cores.

Windows clients often offer both a system proxy and TUN. With TUN enabled, the virtual adapter, system firewall, and other network software are the main troubleshooting points. macOS likewise supports a system proxy or network extension, but permission grants, sleep/wake recovery, and network changes can affect connection status. Linux clients vary more widely, ranging from graphical apps to cores running with configuration files and service processes; desktop proxy variables, system routes, and container networking must be checked separately.

Android clients typically use the system VPN interface to intercept traffic and may offer per-app routing. Battery-saving and background controls can affect long-running connections, while switching between Wi-Fi and mobile data may trigger a reconnect. iOS clients are managed by the system network-extension framework; support for protocols, rule sets, and scripts varies by app, so confirm format compatibility before importing.

For cross-platform migration, the safest approach is to re-import a subscription that matches the target client instead of copying a complete configuration exported from another platform. A full configuration may contain core-specific rule syntax, scripts, policy groups, or DNS fields that another client ignores even if it accepts the file.

Beginner Troubleshooting Checklist: Verify Each Layer from Subscription to Traffic

When a client behaves unexpectedly, do not change the protocol, node, DNS, and routing all at once. Changing several variables makes it impossible to know the real cause even if the problem temporarily disappears. A better approach is to verify each layer in order: configuration delivery, connection establishment, traffic interception, rule matching, and domain resolution.

• ✅ Subscription updates: the link works and the client can parse the expected format.
• ✅ Node connects: authentication, protocol, transport, and TLS parameters match.
• ✅ Traffic is intercepted: the system proxy or TUN is enabled and the target app enters the client.
• ✅ A rule matches: the target domain reaches the expected policy instead of being overridden by an earlier rule.
• ✅ The exit is as expected: the new connection originates from the selected region.
• ✅ The DNS path is correct: the resolver matches the current mode and is not bypassed by the app.
• ❌ Do not use the color of the Connect button to judge whether the entire configuration is working.
• ❌ Do not automatically attribute one website’s cache, account region, or service restrictions to a node failure.

If a subscription will not update but previously imported nodes still connect, the problem is more likely in configuration retrieval. If every node completes a handshake but no app traffic appears, the issue is more likely in traffic interception. If only specific domains take the wrong path, inspect the rules and DNS. If one platform fails while others work, first compare the client core, permissions, and supported configuration fields.