This VPN glossary for beginners follows the practical workflow: get a subscription link, import it into a client, choose a node, confirm the protocol, and then decide between routing, global, and rule modes. Many connection problems are not caused by a failed route, but by treating “subscription,” “node,” “protocol,” and “operating mode” as the same thing and troubleshooting the wrong layer.
You do not need to study complex networking theory first. Once you know where the configuration comes from, where traffic is meant to go, how the client carries it, and which requests need to use a route, most settings become understandable. Button names vary by platform, but the underlying layers are largely the same.
Understanding the complete path from subscription to connection
A normal connection usually involves several independent configuration layers. The subscription supplies node details to the client; a node describes a selectable access target; the protocol defines how the client and server communicate; the route type describes the network path after traffic leaves the access point; and routing rules decide whether a request should be handled by a node.
| Term | What it solves | Common misconception | What to check first |
|---|---|---|---|
| Subscription | Delivers usable configuration to the client and allows later updates | Treating the subscription URL like a normal web page | Whether the subscription imported and updated successfully |
| Node | Provides one specific connection configuration | Assuming nodes in the same region always use the same path | Node name, region, protocol, and connection status |
| Protocol | Defines how the client and server exchange data | Judging actual speed from the protocol name alone | Whether the client supports the protocol and transport method |
| Route type | Describes the network path used after connection | Confusing the route type with the protocol | Direct, relay, or IEPL dedicated-route label |
| Routing rules | Decide whether a request uses a node or connects directly | Assuming all traffic automatically uses a node once the client is enabled | Rule match results and the current operating mode |
What is a subscription link, and why import it into a client?
A subscription link is a configuration URL generated by a service provider for a client to read. It may return a node list or a complete configuration with groups, rules, and DNS settings. If opening it in a browser shows plain text, a download prompt, or unreadable content, that does not mean the link is broken: it is intended for a compatible client, not a web browser.
During import, the client requests the subscription, parses the server address, port, protocol parameters, and node names, and saves them as a local configuration. When you later choose “Update subscription,” the client fetches the version provided by the server again. Updates usually add, modify, or remove nodes, but whether manual local changes are preserved depends on how the client merges configurations.
- Copy the subscription link from the service page without cutting out any part of it.
- Open a client compatible with your platform and find the subscription, configuration, or profile section.
- Choose Import from URL and paste the complete link into the relevant field.
- Save it, run an update, and confirm that nodes or policy groups appear in the client.
- Select a node, then enable system proxy, TUN, or another traffic-capture method.
- Use the website or app you actually need to access to verify the routing result.
Subscription links usually contain credentials that identify the subscription, so store them as carefully as you would a password. Posting the link on a public forum, showing the complete URL in a screenshot, or importing it into an untrusted online conversion tool could expose the configuration. If you suspect the link has leaked, reset the subscription on the service page instead of merely deleting the old profile from the client.
Nodes, servers, and route types are not the same thing
A “node” in a client is a set of connection parameters that can be selected. It usually includes a display name, server address, connection port, protocol, and authentication details. Region, route, or purpose labels in a node name are guidance for choosing; they are not themselves part of network transmission.
“Server” generally refers to the host or access point that actually carries the service. A “node” is the configuration unit shown to the user in the client. One server can host configurations for different protocols, and the same region may have several completely different routes. Therefore, two nodes showing the same city do not necessarily share the same entry point, exit, or intermediate path.
What direct, relay, and IEPL dedicated routes mean
A direct route means the client connects straight to the target server entry point without an additional forwarding layer set up by the provider. Its structure is straightforward, but the experience is more directly affected by local-carrier routing, interconnection, and fluctuations at the international gateway.
A relay route first connects to an entry point that is closer or easier to reach, then uses the relay network to reach the exit. Its value lies in changing the network path, not the application-layer protocol. When the relay entry is stable, it can avoid some poor public-network routes; if the relay itself is congested, the extra hop can become a bottleneck.
An IEPL dedicated route usually uses a private international Ethernet connection for the cross-border segment, combined with an entry and exit point to provide access. This is separate from “which proxy protocol is used”: a VLESS node can run over different route types, and a Trojan node can use a direct, relay, or dedicated route. The protocol name cannot replace the route description.
How to understand Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC
A protocol defines how the client and server establish a session, authenticate, and transmit data. It affects compatibility, transport characteristics, how TCP or UDP is used, and client configuration, but it cannot determine final speed on its own. Actual performance also depends on the route, server load, local network, congestion control, and application traffic.
| Protocol | Key characteristics | Configuration notes | When it is commonly suitable |
|---|---|---|---|
| Shadowsocks | A relatively straightforward encrypted proxy protocol with a mature ecosystem | The encryption method, password, and plugin parameters must match the server | A general-purpose connection option when widely supported by clients |
| VMess | Common in the V2Ray ecosystem and compatible with different transport layers | Identity parameters, transport method, and time settings can all affect the connection | Worth keeping when you already have a compatible configuration; do not judge performance by the name alone |
| Trojan | Often paired with TLS to carry data over a standard encrypted connection | The domain, certificate validation, and server name must match correctly | Suitable when the client fully supports the required TLS parameters |
| VLESS | A lightweight authentication layer that can be combined with TCP, WebSocket, gRPC, and other transports | VLESS is only one layer; TLS, REALITY, and transport parameters must also match | Suitable for configurations using a newer Xray ecosystem |
| Hysteria2 | Based on QUIC and UDP, with an emphasis on transport performance in challenging networks | If the local network restricts UDP, it may underperform or fail to connect altogether | Useful on networks with noticeable packet loss or jitter where UDP is available |
| TUIC | Also based on QUIC and UDP, with support for concurrent data transport | The client version, authentication parameters, and congestion-control settings must be compatible | Suitable when the server explicitly provides it and the current network permits UDP |
Terms such as WebSocket, gRPC, TCP, and QUIC often appear alongside protocol names, but they may belong to different layers. For example, VLESS can run over different transport methods, while TLS or REALITY handles connection validation and encrypted encapsulation. After importing a subscription, you normally do not need to rebuild these parameters manually; if you change one without a matching server configuration, the connection will fail.
“Newer protocol means faster” is not a reliable rule. Hysteria2 and TUIC rely on UDP and may be a better fit where UDP is allowed and the network has noticeable jitter. On office, public, or other access networks that restrict UDP, TCP-based configurations may establish connections more easily. The sensible approach is to keep working alternatives and test them on the current network.
How to switch between global mode, rule mode, and direct mode
Operating mode determines which traffic is handed to a node. It is unrelated to the protocol used by the node. The same VLESS node can be used in rule mode or global mode. Switching modes does not automatically change the node’s route; it only changes how the client handles requests.
Rule mode: a practical everyday choice
Rule mode determines where traffic goes based on domains, IPs, apps, ports, or rule sets. A common setup sends local services directly while routing requests that need international access through a node. This reduces unnecessary detours and can prevent some local websites from triggering extra verification because the apparent region changed.
Rules are generally matched in order, and the first match takes effect. In a client, “proxy,” “direct,” and “reject” usually represent different actions; policy groups let multiple nodes become the target of a rule. If a website takes the wrong route, check the matched rule in the connection log rather than only checking the currently selected node.
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-SUFFIX,local.example,DIRECT
PROCESS-NAME,browser,PROXY
MATCH,DIRECTThe example above is only a neutral illustration of rule structure: a domain suffix can be assigned to a proxy or direct connection, an application process can have its own policy, and the final MATCH handles requests that matched nothing earlier. Field names and syntax differ between clients, so one format cannot be pasted directly into every app.
Global mode: useful for temporarily testing whether rules are the problem
Global mode usually sends all traffic already captured by the client through the current node. It is useful for short troubleshooting tests: if rule mode fails but global mode works, the likely issue is rule matching, DNS results, or policy-group selection; if global mode also fails, continue checking the node, protocol, and local network.
“Global” does not necessarily mean every piece of traffic on the device. When only the system proxy is enabled, apps that ignore system proxy settings may still connect directly. Traffic not captured by TUN, independent network stacks, and special system services may also bypass the client. Global describes the client’s internal decision mode, not an absolute statement about the device’s entire traffic scope.
Direct mode: quickly restore the local network path
Direct mode prevents captured requests from going through a remote node. It is useful for checking whether a local website is failing because of a detour, or when international access is temporarily unnecessary. To stop traffic capture completely, also disable the system proxy or TUN; switching the policy to direct usually leaves the client process running.
What system proxy, TUN, and DNS leaks each control
A system proxy writes a proxy address into the operating system so apps that follow the setting send HTTP or SOCKS requests to the client. Browsers and most conventional apps can read the system proxy, but some games, command-line programs, standalone runtimes, and apps with their own networking may ignore it.
TUN mode creates a virtual network interface and captures a broader range of traffic at the IP layer, after which the client handles routing and rules. It is better suited to apps that do not support system proxy settings and can unify the handling of TCP, UDP, and DNS requests. However, TUN often requires system network permissions and may conflict with other traffic-filtering tools, enterprise security software, or existing virtual adapters.
DNS translates domain names into IP addresses. A DNS leak usually means that a domain lookup which should have been handled by the client’s rules or encrypted route was sent through the local carrier or another unexpected resolver path. This can expose lookup targets and return results that do not match the node’s exit region, causing a site to select the wrong region, connect to an unsuitable address, or load while its content remains unavailable.
When handling DNS issues, check the client DNS settings, system resolver settings, and encrypted DNS in the browser together. If the browser specifies its own resolver, it may bypass the client’s intended routing design. If the client uses Fake IP or an enhanced mode, the related sniffing, mapping, and exclusion rules must also be correct. Do not attribute every resolution problem to the node: a reachable node does not guarantee a correct DNS path.
Understanding client differences across Windows, macOS, Android, and iOS
Clients on different platforms share the same core tasks but use different permission models. Windows clients often provide a system proxy, virtual adapter, and service mode; macOS clients work with system network extensions or proxy permissions; Android usually creates a local tunnel through the system VPN interface; iOS and iPadOS rely on the network-extension capabilities permitted by the system. All may show “Connected,” but the actual capture scope still depends on the current mode.
Desktop clients make connection logs, rule matches, and DNS queries easier to inspect, which helps troubleshoot subscription parsing and routing. Mobile platforms are affected by background scheduling and battery-saving policies. When an app moves to the background or the network changes between Wi-Fi and cellular data, the system may rebuild the tunnel. A brief disconnect does not necessarily mean the subscription failed; first return to the client and check the system tunnel status.
A subscription displaying different content in different clients does not necessarily mean that configuration was lost. A full-configuration client may show policy groups, rules, and DNS modules, while a client that supports only node subscriptions may extract only server entries. Some protocols or transport methods require newer core support: a client may import node names without being able to establish the corresponding connection.
When choosing a client, check the subscription format, protocol support, system proxy and TUN capabilities, rule syntax, and log clarity first. Do not judge compatibility solely by whether the interface looks similar. The client and configuration method explicitly provided on the service page will usually make it easier to keep parameters consistent.
Troubleshoot connection problems layer by layer instead of changing every setting at once
Effective troubleshooting depends on comparison. Change one condition at a time so you can tell whether the issue is with the subscription, node, protocol, route, mode, or DNS. If you update the subscription, switch protocols, enable TUN, replace rules, and change system DNS all at once, even a recovered connection will not reveal the real cause, and the next similar problem will send you back to trial and error.
- ✅ First confirm that the subscription updates successfully and that the client shows complete node names.
- ✅ Choose a clearly supported node and check the connection log for a completed handshake.
- ✅ If nodes in the same region fail, compare them using a different route type.
- ✅ If rule mode behaves unexpectedly, briefly switch to global mode to check for a mistaken match.
- ✅ If the browser works but other apps do not, check the system proxy’s capture scope and assess whether TUN is needed.
- ✅ If the site shows the wrong region or domain resolution is abnormal, check the DNS paths used by the client, system, and browser.
- ❌ Do not casually modify authentication, TLS, transport-layer, or server-name settings generated automatically by the subscription.
- ❌ Do not paste the subscription link into an untrusted conversion page or public content.
If the log shows that the subscription request failed, the problem occurred while fetching configuration. If the node exists but the handshake fails, check protocol compatibility, local network restrictions, and node status. If the handshake succeeds but a particular website is unavailable, continue by checking rules, DNS, and the site’s own restrictions. Layer-by-layer diagnosis is more effective than repeatedly clicking the connect button.
Turn the terminology into a practical workflow and build reliable habits
Beginners often treat “the client says connected” as the end of the process. A more accurate check includes several points: the subscription has been imported and can update, the selected node works with the current network, the system proxy or TUN is actually capturing the target app, routing rules send requests to the intended policy, and DNS queries are not taking an unexpected path.
Node names are useful for quick filtering, but the final choice should reflect the task. Web access and AI Tools depend more on interaction stability; Streaming also involves the exit region and platform detection; downloads depend more on sustained transfer and traffic planning. A node that works in one scenario is not necessarily the best choice for every app.
You also do not need to manually chase every new protocol. When the subscription already provides working parameters, start with the server’s recommended configuration. Switch protocols or transport methods only when there is a clear symptom such as restricted UDP, failed TLS validation, or an incompatible client core. The more parameters involved, the more important it is to avoid changes without evidence.
Rule mode is suitable for long-term use, but rules need maintenance. Website domains, content-delivery addresses, and app endpoints change, so older rules may miss new domains. If the home page loads but sign-in or images fail, check whether the failed request’s domain falls under the wrong policy instead of switching the entire device to global mode permanently.