VPN Terms Explained: Subscriptions, Nodes, Protocols, and Routing

Start with the complete connection flow: where each term fits

The most effective way to understand VPN terminology is not to memorize definitions one by one, but to follow a real connection from start to finish. The user first gets a subscription link from the service dashboard and imports it into a client. The client reads the node configurations, then establishes a connection based on the protocol, transport method, and authentication details. Once connected, routing rules determine which requests enter the node, DNS settings resolve domain names to addresses, and the exit server ultimately accesses the target website on behalf of the device.

In this workflow, a subscription distributes configuration, a node describes a reachable entry or exit point, a protocol defines how the client and server communicate, a route describes the network path behind the node, and routing determines whether a request passes through the proxy. These concepts are related, but they are not interchangeable. A subscription updating successfully does not mean every node in it suits the current network; a protocol completing its handshake does not mean the target website will necessarily use that route.

How do subscription links, nodes, and configuration files differ?

A subscription link is a configuration entry point, not a node itself

A subscription link is usually generated by the service dashboard. When the client accesses the address, it receives encoded or structured configuration data that may include node names, server addresses, authentication details, protocol types, and transport parameters. The client’s “update subscription” action simply requests this data again and refreshes the local list.

Subscription links often contain tokens that identify an account or service permission, so they should be protected like passwords. Do not publish a complete link on a public webpage, in screenshots, forums, or code repositories. When describing an issue to support, you can share the client error and node name, but mask identifying parameters in the link.

A failed subscription update and a failed node connection should be assessed separately. The former may be caused by an expired link, an inaccessible subscription address, or an incompatible client format; the latter may result from node maintenance, local network restrictions, mismatched protocol parameters, or an incorrect system clock. Old nodes may continue to connect even when the subscription can no longer refresh; conversely, a successful update does not mean every route suits the current environment.

A node is a set of connection parameters

The region names shown in a client list, such as “Japan” or “Singapore,” are simply labels for identification. A node configuration also includes the server address, port, user credentials, protocol, transport layer, and security-layer parameters. Identical node names can still point to different entry points, relays, or protocols.

A node’s region usually indicates where its exit address is located, but services may also name nodes by entry point, purpose, or route type. To verify the exit location, visit the My IP page after connecting instead of relying only on the client label. Browser geolocation, account region, and website caching can also affect what a page displays; they are not the same as the exit IP.

Manual configuration and subscription imports

Manual configuration means entering the server, authentication, protocol, and transport parameters one by one. Its advantage is that every field is explicit, making it useful for isolated testing. Importing a subscription is more convenient for daily use because the client can retrieve changes after the service updates its nodes. Both methods establish connections on the same underlying principles; the main difference is how the configuration reaches the client.

1. Copy the subscription link from the service dashboard instead of using an untrusted intermediary conversion page.
2. In a compatible client, find “Subscriptions,” “Configuration sources,” or a similar entry.
3. Paste the link and run an update, then confirm that the list shows nodes and protocol details.
4. Choose a node, connect, and verify the exit IP and DNS status.
5. Update the subscription after server-side configuration changes instead of relying on cached parameters indefinitely.

What do direct, relay, and IEPL routes mean?

The protocol answers “how is data encapsulated and transmitted?” while the route answers “where does the data actually travel?” The same protocol can run over different routes, and one route can carry different protocols. When comparing nodes, consider the local network, destination, and route path—not just the protocol name.

Direct route

A direct route connects the client straight to a server in the target region, without an additional provider-configured relay in between. Its structure is simple, and the path is determined largely by the local carrier and Internet routing. Real-world performance is affected by inter-network connectivity, congestion at international exits, and route detours. The same direct node can perform very differently across regions and access networks.

Relay route

A relay route first connects to a nearby or more reachable entry point, which then forwards traffic to the final exit. Relays are commonly used to avoid poor direct routing or to manage entry and exit points separately. They add a forwarding hop, but that does not automatically make them slower; when the entry-to-exit path is more stable, the overall experience may be better than a heavily detoured direct route.

When choosing a relay, consider the local-to-entry path and the entry-to-exit path separately. If the entry is reachable but the exit is malfunctioning, the client may still show an established connection while web requests fail. Use logs to determine whether the handshake succeeded without data transfer or whether the destination rejected the exit request.

IEPL dedicated route

IEPL generally refers to an international Ethernet private-line connection that links network access points in different regions over an operator’s dedicated transport. In user-facing node names, “IEPL dedicated route” usually emphasizes that the backbone segment differs from an ordinary public-Internet direct route. The device-to-access-point leg and the exit-to-website leg may still pass through local networks or the public Internet.

Therefore, IEPL should not be understood as a physically exclusive route from the device to every website, nor can a label alone establish a fixed latency or bandwidth. A more practical assessment is to compare connection stability, sustained transfer smoothness, and access to the target platform on your own network. The Global Nodes page lists regions and route types; dynamic status should be judged by the client’s results during the actual connection.

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

Protocols define how the client and server authenticate, encapsulate, and transmit data, but modern proxy connections often add transport and security layers as well. When you see a protocol name, also check whether it runs over TCP, WebSocket, gRPC, or QUIC, whether TLS is enabled, and whether parameters such as the server name and certificate verification are correct.

Shadowsocks

Shadowsocks is an encrypted proxy protocol. Its core configuration typically includes the server, port, password, and encryption method. Its structure is relatively straightforward and it is widely supported by clients, making it suitable when configuration complexity should stay low. The client and server must use compatible encryption methods and parameters or data decryption will fail. It is not a traditional full-device VPN by itself; whether it handles every application depends on whether the client uses a system proxy, TUN mode, or another forwarding method.

VMess

VMess is common in the V2Ray ecosystem and includes an identity-authentication mechanism that can work with different transport methods. Some implementations are sensitive to clock skew, so when authentication fails, confirm that the device time and time zone are synchronized automatically. VMess is only one part of the connection configuration; the WebSocket path, hostname, TLS, and transport parameters must also match the server.

VLESS

VLESS uses a more streamlined authentication and data structure and does not provide complete transport encryption on its own. It is usually paired with TLS, REALITY, or a protected underlying transport. To assess whether a VLESS configuration is secure, do not look only at the protocol name. Check whether the security layer is enabled, whether the certificate or public-key parameters match, and whether the client performs proper server identity verification.

Trojan

Trojan typically runs over TLS and uses a password for authentication, giving the connection an appearance similar to ordinary TLS traffic. Common configuration fields include the server name, certificate verification, and password. Disabling certificate verification may temporarily bypass a configuration error, but it weakens server identity checks and is not suitable as a long-term troubleshooting method. A better approach is to check the domain, certificate, and device time.

Hysteria2

Hysteria2 is designed around UDP and QUIC concepts and includes congestion-control mechanisms for unstable or high-loss links. It may deliver strong sustained-transfer performance on suitable networks, provided the local network allows UDP and the router, firewall, and carrier path do not impose severe restrictions. If UDP is blocked or performs poorly, choose another usable protocol rather than repeatedly changing unrelated routing rules.

TUIC

TUIC is also built on QUIC and UDP, with an emphasis on multiplexing and connection management. It is not interchangeable with Hysteria2 and does not use the same parameters; the client and server must each support the corresponding implementation. When “protocol not supported” appears, first check the client version and core capabilities instead of manually entering a TUIC node as an ordinary TLS node.

How split tunneling, global mode, and rule-based mode work

Routing is the decision a client makes for each network request. Common outcomes are proxying, direct access, and blocking. Decisions may be based on the domain, destination IP, application process, port, geolocation databases, or custom rules, depending on the client and platform.

Global mode

Global mode generally means that all traffic captured by the client is sent to the current node by default. It is useful for temporarily checking whether a request went direct because no rule matched, and for short periods when a consistent exit is needed. Global mode does not mean every packet on the device must pass through the node: apps outside system-proxy coverage, local-network traffic, system services, and unsupported protocols may still use their original path. TUN mode can expand coverage, but the client documentation and routing table remain authoritative.

Rule-based mode

Rule-based mode matches requests in order. For example, local-network addresses can go direct, specified international websites can use the proxy, advertising domains can be blocked, and everything else can follow the default policy. Rules usually have priorities, so a request matched earlier will not continue to later rules. When a custom rule has no effect, check both its contents and whether an earlier rule overrides it.

Domain rules and IP rules also differ. Domain rules require the client to see the original domain; if an application has already performed its own DNS lookup, the client may see only the destination IP. Conversely, a domain may resolve to changing addresses, making fixed IP rules unreliable. A robust rule set generally combines domain data, IP data, and DNS handling.

Direct access and bypassing the local network

Direct access means a request does not pass through a remote node but uses the local network normally. Local resources such as printers, router administration pages, and network storage typically require direct access. If global mode prevents access to them, enable “bypass local network” or add local-address rules. Keep in mind that a direct rule exposes the local network’s original exit; that is the intended result of routing, not necessarily a connection failure.

System proxy and TUN mode

A system proxy mainly affects applications that follow the operating system’s proxy settings. Browsers usually support this well, but some games, command-line tools, and applications with their own network stacks may ignore it. TUN mode uses a virtual network interface to capture a broader range of IP traffic. Coverage is usually more complete, but conflicts with firewalls, enterprise network software, or other VPN configurations are also more likely.

If the browser works but a particular app does not, first check whether the app follows the system proxy. If no apps can connect, check TUN routes, DNS, and the system firewall. Do not mistake an app outside system-proxy coverage for a failed node.

DNS, remote resolution, and DNS leaks

DNS resolves domain names into connectable IP addresses. When a browser visits a website, it typically resolves the domain first and then establishes the network connection. A connected proxy does not automatically mean DNS requests use the same path; that depends on the client’s DNS mode, system settings, and the app’s own behavior.

What is a DNS leak?

When all relevant requests are expected to use the proxy, a DNS leak occurs if domain lookups are still sent to a resolver provided by the local network. The local resolver may still see the queried domains, and different local and remote results may also cause websites to load incorrectly.

Do not check only the exit IP. Also confirm that the DNS servers shown by a DNS test match the current configuration, and note whether the browser has enabled its own secure DNS. Encrypted DNS built into a browser can protect the query in transit, but if it uses a direct local exit, that does not mean the query was forwarded through the proxy node.

Local and remote resolution

With local resolution, the device or local network obtains the destination IP first, and the routing engine then decides how to connect. It responds quickly, but domain information may remain on the local path. Remote resolution sends the query through the proxy side or a specified remote resolver, making it easier to keep domain decisions aligned with the exit region. Different clients may call these options proxy DNS, remote DNS, Fake IP, or enhanced mode, and their implementations are not identical.

Fake IP mode first returns an address managed by the client to the application, then associates it internally with the real domain and applies routing. This helps preserve domain information, but some local-network services, device discovery features, or apps that depend on special DNS results may be incompatible. If problems occur, add the relevant domains to an exclusion list instead of disabling all DNS management.

1. Record the current exit and DNS resolution status before connecting.
2. Check the exit IP again after connecting to a node to confirm that traffic actually switched.
3. Check whether the DNS resolver matches the client configuration.
4. Test the browser and other apps separately to identify whether an app uses its own DNS.
5. Compare rule-based mode with global mode to determine whether the issue is DNS-related or caused by routing rules.

Windows, macOS, iOS, Android, and Linux client differences

The same subscription may expose different options on different platforms because of differences in operating-system network interfaces and client cores. This does not mean the subscription content changed. Before importing, confirm that the client supports the subscription’s protocols, transport methods, and security parameters.

Windows

Windows clients often provide both a system proxy and TUN mode. A system proxy makes it easy to switch browser traffic, while TUN is better for apps that do not follow proxy settings. TUN may require system permissions, and you should check for conflicts with other virtual network adapters, enterprise security software, or an existing VPN connection.

macOS

macOS can also capture traffic through a system proxy or network extension. The first time an extension is enabled, the system asks the user to approve its permissions. If the client reports a connection while some apps still go direct, check whether it is using the system proxy or a virtual network interface, and confirm whether the app has its own proxy or DNS settings.

iOS and Android

Proxy clients on mobile platforms usually process traffic through the system VPN interface. A VPN icon in the status bar only shows that the system network extension is running; it does not by itself prove that the node exit and DNS match expectations. Mobile operating systems generally allow only one primary VPN configuration to be active, so ad blockers, enterprise access tools, and proxy clients may compete for the same interface.

Android devices may also offer system features such as always-on VPN and per-app routing. Power-saving policies from different manufacturers can restrict a client’s background operation. On iOS, split-tunneling capabilities depend more heavily on how the client implements its network extension. If the connection drops after the device goes idle, check system permissions and background policies before switching nodes.

Linux

Linux environments may use graphical clients, command-line cores, system services, and routing rules. System proxy environment variables work only for programs that read them; they cannot replace transparent forwarding or TUN. During troubleshooting, check whether the process is running, whether listeners are active, whether the routing table has updated, and whether system network management has overwritten the DNS configuration.

Troubleshoot connection problems layer by layer instead of changing every option at once

The practical value of terminology is that it helps break a problem into verifiable stages. Changing the protocol, DNS, node, routing, and system proxy all at once may make the problem disappear temporarily without revealing the cause. The sequence below makes reproduction and diagnosis easier.

Subscription will not update

• Confirm that you copied the complete subscription link without spaces or truncated characters.
• Check whether the service status and subscription permissions are still valid.
• Confirm that the client supports the subscription format and review network errors in the update log.
• Do not process links containing authentication data with online conversion tools from unknown sources.

Node cannot establish a connection

• Try another node using the same protocol to determine whether the issue affects one node or the protocol overall.
• Synchronize the system clock, especially when using VMess, TLS, or certificate verification.
• When using Hysteria2 or TUIC, check whether the current network allows UDP.
• Verify the server name, transport path, authentication, and certificate-related parameters.

Shows connected, but websites will not open

• Check whether the exit IP changed to distinguish a successful handshake from successful forwarding.
• Switch to global mode for comparison and determine whether the target domain is missing from the rules.
• Check whether DNS returns a result and whether that result is being routed incorrectly.
• Confirm that the browser is not retaining an invalid proxy setting or using a separate network extension.

The browser works, but other apps do not

• Confirm whether only the system proxy is enabled.
• Check whether the target app supports proxies or requires TUN capture.
• Review process-routing rules to see whether the app is set to direct access.
• Rule out differences caused by the app’s own DNS, QUIC, or fixed-exit policy.

Connection is stable, but access results are unexpected

Confirm the exit region first, then check whether the target website is displaying content based on the account region, cache, language settings, or browser location. A node changes the network exit only for traffic it captures; it does not automatically modify website account details. If a platform rejects the current exit, verify with a suitable region or route instead of attributing every result to the protocol.

With these VPN terms in hand, you can understand a connection as a clear chain: the subscription provides configuration, the client parses nodes, the protocol establishes communication, the route carries data, routing selects the path, DNS resolves domains, and the exit accesses the target on behalf of the device. When choosing a service or troubleshooting an issue, checking each layer in this order is more reliable than chasing a single protocol name. For practical next steps, see the Beginner’s Guide and the Complete Guide.