This VPN glossary for beginners starts with the most common workflow: get a subscription, import the configuration into a client, choose a node, protocol, and routing mode, then verify that traffic follows the expected path. Many complex-sounding terms simply describe different steps in this process. Mixing them up makes troubleshooting difficult; separating their roles lets you check most problems step by step.
The short version: a subscription is not a client, a node is not a protocol, and a route label does not necessarily reveal the actual network path. Global mode determines which traffic enters the proxy, the protocol determines how the client communicates with the server, and DNS converts domain names into addresses. If any part is mismatched, you may see “connected” while websites still fail to load.
Start with a table of common VPN terms
| Term | What it is | What it is not | What to check first |
|---|---|---|---|
| Subscription | A set of node configurations maintained by the service and usually delivered to the client through a subscription link | Not the application that establishes the connection | Whether the link is complete or expired and whether the client updated successfully |
| Client | Software that reads configurations, creates the tunnel, and applies routing rules | Not the route itself | Whether it supports the protocol and whether system permissions are enabled |
| Node | A selectable server configuration entry that a client can connect to | Not necessarily a dedicated server or a fixed physical path | Whether the address, port, authentication details, and protocol match |
| Protocol | The agreed method for data encapsulation, authentication, and transmission between the client and server | Not a speed tier or a region name | Whether the client core is compatible and all required parameters are present |
| Route | The network path and routing arrangement between the local entry point and the destination exit | Not a property that can be confirmed entirely from a node name | Exit region, route stability, and real-world app performance |
| Split tunneling | Using domains, addresses, apps, or rule sets to decide whether traffic is proxied, sent directly, or rejected | Not another name for connecting to multiple nodes at once | Rule order, match results, and the final fallback policy |
| DNS | The system that resolves domain names into network addresses | Not the protocol that transports webpage content | Who sends the query and whether the result is handled correctly by the rules |
How subscriptions, clients, and nodes fit together
A subscription is a configuration list, not an installer
A subscription link usually returns encoded or structured node information. The client reads it to display regions, protocols, and node names. When the service changes an entry point or updates parameters, running “Update subscription” in the client synchronizes the local configuration. Treat a copied subscription link as a credential, and never publish it in forums, screenshots, or public documents.
A failed subscription update does not necessarily make every existing node stop working immediately. The client may retain the last successfully downloaded local copy, but whether an old configuration still connects depends on the service status. Conversely, a successful update does not guarantee that every node works; it only means the client read the configuration list.
The client turns configuration into a connection
The client handles protocol implementation, authentication, traffic interception, DNS processing, and routing rules. Interfaces vary widely across platforms, but the underlying tasks are similar. Desktop systems commonly offer system proxy or TUN modes; mobile systems often use the system’s VPN permission to create a virtual network interface. A VPN icon in the status bar only shows that the interface exists—it does not by itself prove that the exit region and DNS path meet expectations.
A node is a connectable configuration
A node configuration usually includes a server address, port, protocol type, authentication details, and any additional parameters required by the protocol. Selecting a node tells the client to use those parameters to establish a session. Node names may describe a region, purpose, or route label, but they are defined by the provider and cannot alone reveal the underlying route.
- ✅ Import subscription links only into trusted clients and manage them like credentials
- ✅ After updating a subscription, check that the node list actually synchronized
- ✅ Before importing, confirm that the client supports the protocols included in the subscription
- ❌ Do not treat “subscription updated” as proof that every node can connect
- ❌ Do not infer the complete network path from a node name alone
How direct routes, relays, and IEPL dedicated routes differ
A route describes the path data takes from the user side to the exit side. Even when exits are in the same region, differences in entry location, carrier interconnection, cross-border segments, and congestion can produce different results. A speed test reflects network conditions at that moment; it cannot replace observing long-term routing and real application performance.
Direct route
A direct route usually means the client connects straight to the target server entry point without an additional forwarding entry deployed by the service. Its structure is simpler, but cross-network performance depends more heavily on the local carrier, destination network, and current routing. “Direct” does not mean data travels without routers; it means the service architecture has no extra relay layer.
Relay route
A relay first connects to a nearer entry point or one with better interconnection conditions, which then forwards traffic to the target exit. This can split an unstable public-network path into separately managed segments. A relay is not automatically faster: entry load, forwarding links, exit quality, and the local network all matter. Its advantage is path management; the trade-off is greater architectural complexity.
IEPL dedicated route
IEPL generally refers to an international Ethernet private-line connection used to create a relatively controllable cross-border transmission segment. In an acceleration service, access from the user side to the entry point may still use the local public network, with only part of the path entering the private line. An “IEPL node” therefore does not mean every segment from the device to the destination is entirely outside the public internet. Refer to the service provider’s description for the exact access boundary and exit architecture.
| Route type | Typical path | Main characteristics | How to evaluate it |
|---|---|---|---|
| Direct | The local network accesses the remote entry point directly | Simpler structure, with greater dependence on public-network interconnection quality | Observe sustained performance from the local carrier to that region |
| Relay | The local network reaches a forwarding entry point before the exit | The path can be managed, while both the entry and forwarding layers affect performance | Test stability with real applications instead of relying on a single latency reading |
| IEPL | A combination of public-network access and private-line segments | Some cross-border segments are more controllable; the boundary depends on the architecture | Confirm which segments are covered by the entry, exit, and private line |
What common protocols are designed to do
A protocol defines how the client and server encapsulate data, authenticate, and transmit traffic. Supporting a protocol name alone is not enough; the related transport layer, TLS, server name, and congestion-control parameters must also be compatible. If an imported configuration shows “Unknown protocol,” the client core may be outdated or the configuration format may not match—it is usually not a node-region issue.
Shadowsocks
Shadowsocks is a lightweight encrypted proxy protocol. Its core configuration usually includes a server, port, password, and encryption method. It is widely implemented and suits common proxy scenarios. Support for cipher suites and plugins varies between implementations, so an older client may not read a configuration generated by a newer one.
VMess and VLESS
VMess is common in the V2Ray ecosystem and includes mechanisms for identity authentication and data encapsulation, with support for different transport methods. VLESS has a leaner design and does not rely on the protocol itself to provide complete data encryption; deployments commonly pair it with TLS or another secure transport layer. Their names are similar, but their fields and authentication logic differ, so they cannot be swapped directly.
Trojan
Trojan usually runs over TLS. Common configuration fields include the server address, authentication password, server name, and certificate-validation parameters. The client must validate the certificate and server name correctly. Disabling certificate verification for temporary troubleshooting weakens connection validation and should not be a long-term setting.
Hysteria2 and TUIC
Hysteria2 and TUIC both rely heavily on QUIC and UDP transport, with an emphasis on improving transmission scheduling and connection behavior across complex links. They are not automatically better than TCP-based options on every network. If the current network restricts UDP or a router handles UDP sessions poorly, the connection may fail or degrade. Switch to a compatible protocol and route instead of repeatedly changing unrelated routing rules.
| Protocol | Common foundation | Compatibility checks | Common misconception |
|---|---|---|---|
| Shadowsocks | Encrypted proxy | Encryption method, plugins, and client implementation | Assuming all clients with the same name support identical configurations |
| VMess | Authentication and encapsulation in the V2Ray ecosystem | Transport method, identity parameters, and core version | Swapping it directly with a VLESS configuration |
| VLESS | Lean authentication, commonly paired with a secure transport layer | TLS, server name, and transport parameters | Ignoring the outer secure-transport configuration |
| Trojan | TLS connection and password authentication | Certificate, server name, and time status | Leaving certificate verification disabled long term |
| Hysteria2 | QUIC- and UDP-based transport | UDP reachability, authentication, and bandwidth parameters | Equating a protocol name with a fixed speed |
| TUIC | QUIC- and UDP-based proxy transport | Client version, UDP, and certificate configuration | Ignoring the current network’s UDP restrictions |
How to choose between global, rule, and direct modes
Once connected, the client still needs to decide which requests should pass through the node. That is the routing mode. Common interfaces call these Global, Rule, and Direct; some clients use similar labels such as Proxy, Rule, and Direct. “Global” usually means that traffic intercepted by the client uses the proxy, not necessarily that every program and protocol on the device is captured.
Global mode
Global mode is useful for checking whether rules are causing access problems. If a site works in Global mode but not in Rule mode, the issue is likely related to domain classification, address matching, DNS resolution, or rule order. For everyday use, Global mode may also send local services and apps that do not need international access through a remote exit, so choose it according to your needs.
Rule mode
Rule mode checks domains, network addresses, processes, or rule sets in sequence and decides whether traffic is proxied, sent directly, or rejected. Rules usually have an order, and a request that matches an earlier rule will not continue through the list. The final fallback is important too: whether unmatched requests go direct or through the proxy depends on the client configuration, not on the name “Rule mode” itself.
Direct mode
Direct mode generally means traffic does not pass through the selected node. It can pause proxy behavior, access local-network resources, or help compare a fault. The virtual interface may remain active while the client is in Direct mode, so check connection logs, rule matches, and exit information to determine whether traffic uses a remote exit rather than relying only on the system icon.
- ✅ When a website behaves unexpectedly, compare it in Global mode first to determine whether the issue is rule-related
- ✅ Check which rule matched the target domain and its related domains
- ✅ Confirm whether the fallback policy is Proxy, Direct, or Reject
- ✅ Keep local devices and LAN resources on Direct when needed
- ❌ Do not assume Rule mode automatically identifies every type of traffic
What is the difference between system proxy, TUN, and in-app proxy?
A system proxy is a proxy setting provided by the operating system to applications. Browsers and apps that follow it send supported requests to the client, but some programs may ignore the system proxy or proxy only web traffic. This can result in a browser working normally while a desktop app still connects directly.
TUN mode uses a virtual network interface to capture a broader range of traffic, which the client then handles according to its routing rules. It is often better suited to apps that do not read system proxy settings, but it requires system permission and may conflict with other network tools, virtual machines, enterprise security software, or an existing VPN interface. After enabling TUN, configure LAN bypass and DNS policies as well to avoid losing access to local services.
An in-app proxy applies only to that application. For example, entering a local proxy port in a browser does not make other programs use the same connection automatically. This approach has a clearly defined scope and is useful for testing, but maintaining settings across multiple apps can be tedious. If the app retains the proxy address after the client exits, it may appear to have no network access at all.
What do DNS leaks and resolution errors mean?
Before accessing a domain, a device usually looks up its network address. A DNS leak occurs when queries expected to use a specified controlled path are instead sent directly by the local network or another resolver. This may reveal the domains being queried or produce results inconsistent with the proxy exit region.
DNS problems do not always make a site completely unreachable. Other signs include a domain failing while its address responds directly, different apps returning different results on the same node, old cached results persisting after a route change, or domain-based rules receiving only already-resolved addresses. Remote DNS, local DNS, encrypted DNS, and virtual-address mapping handle different stages in the client, so do not enable every option without understanding its purpose.
First determine whether the operating system, browser, or client initiated the query, then check whether TUN or the system proxy captured it. Some browsers use their own secure DNS setting, which may bypass the operating system’s default resolution path. After changing DNS, account for system and browser caches; otherwise old results can make the new setting appear ineffective.
- ✅ Confirm whether the client captures DNS queries and which resolver it uses
- ✅ Check whether the browser has its own secure DNS setting enabled
- ✅ After changing the policy, clear the relevant caches and reconnect
- ✅ Compare the rule logs to confirm matches for the domain and resolved address
- ❌ Do not use “the node connects” as a substitute for checking the DNS path
The correct order: from importing a subscription to verifying it works
Beginners often switch between several settings and end up unsure which change helped. A more reliable approach is to verify one layer at a time, checking configuration, connection, routing, DNS, and applications in that order.
- Choose a compatible client. First confirm that the client explicitly supports the protocols and configuration format in the subscription. If it cannot recognize the protocol, there is no point troubleshooting routes or split tunneling yet.
- Import and update the subscription. Paste the complete subscription link, wait for the client to report success, and then check that the node list appears. Do not paste the subscription link into a conversion webpage from an unknown source.
- Select a node and connect. Start with the client’s default parameters instead of changing the transport layer, certificate, DNS, and routing options at the same time. If the connection fails, check protocol errors and handshake logs first.
- Run a basic check in Global mode. Confirm that the client can transfer data to the server and check that the exit region matches the selected node. This step helps rule out interference from split-tunneling rules.
- Switch back to Rule mode. Test commonly used websites and apps, and check whether Proxy, Direct, and Reject rules match as expected. When something fails, record the domain and the matching rule.
- Check the DNS path. Confirm that DNS queries follow the exit policy and watch for interactions between the browser’s separate DNS settings, caches, and virtual interfaces.
- Adjust traffic-capture methods afterward. Test the system proxy with a browser first; consider TUN only for programs that do not follow the system proxy. Recheck the connection after every change.
What other boundaries should beginners keep in mind?
Latency, bandwidth, jitter, and packet loss are different metrics. Latency reflects round-trip time, bandwidth describes the amount of data transferable per unit of time, jitter measures latency variation, and packet loss can trigger retransmission or directly affect real-time data. The latency shown in a node list is usually a probe from the client to the entry point, so it cannot fully represent video, downloads, or remote meetings.
The same node can perform differently on different networks and devices. Home broadband, public Wi-Fi, enterprise networks, and mobile networks have different routes and restrictions; desktops, Android, and other mobile platforms also handle background activity, virtual interfaces, and system proxies differently. When reusing a configuration, check platform permissions and client implementation together rather than copying only the node name.
Finally, a connection tool changes the path used by some network traffic. It does not judge whether a website is trustworthy and cannot replace account security, software updates, or certificate validation. If the client reports a certificate error, the system clock is wrong, or the configuration source is unclear, address those basics first instead of disabling verification to keep the connection going.