This VPN glossary starts with four common concepts—subscriptions, nodes, protocols, and routing—and explains what each label in a client interface controls. Keep one principle in mind: a subscription delivers configuration to the client, a node determines where traffic passes through, a protocol defines how the client communicates with the server, and routing rules decide which requests use a route. They are related, but they are not the same setting.
Many connection problems come from mixing up these concepts. A successful subscription import does not mean every node is currently reachable; a region in a node name does not mean the entire path uses a dedicated route; and changing protocols will not automatically fix incorrect DNS settings. Once each layer has a clear role, troubleshooting becomes a matter of checking the path step by step instead of repeatedly clicking buttons.
Subscriptions, configuration files, and subscription links
A subscription is a configuration list maintained by the service. It may include node addresses, ports, authentication details, protocol parameters, transport methods, and display names. When you import a subscription link into a compatible client, the client reads the list and creates selectable nodes—it is not simply opening an ordinary webpage.
The difference between a subscription link and a single-node configuration is how they are maintained. A single configuration describes one connection entry and often needs to be imported again when the route changes; a subscription can update a set of configurations through the same entry point. When a client runs “Update subscription,” it fetches the latest list from the server, but whether local groups, latency results, and custom rules remain depends on the client’s merge logic.
Subscription links often contain account or plan authorization data, so treat them as access credentials. Do not post them on public pages, shared documents, or screenshots. Removing a subscription from the client does not revoke credentials already issued by the server; if a link is exposed, reset it through the service panel rather than simply importing it again locally.
- ✅ Before importing, confirm that the client supports the subscription’s protocols and configuration format.
- ✅ Before updating, check whether local custom groups and rules may be overwritten by the remote configuration.
- ✅ Manage the subscription link like an account credential; do not forward it in public environments.
- ❌ Do not assume that a successful subscription import means every node has passed a connection test.
What the client actually does after import
An import typically involves fetching the subscription, parsing the configuration, creating proxy groups, and loading rules. Only after these steps will the client list the nodes. If the import fails, the cause is usually an invalid link, network access, configuration format, or client compatibility. If the nodes appear but cannot connect, continue by checking protocol parameters, system time, the network environment, and server status.
Importing by QR code is fundamentally the same as pasting a link; a QR code simply encodes text in an easy-to-transfer graphic. After importing, verify the subscription name, node list, and update time so that an outdated configuration is not mistaken for a client problem.
What is the difference between nodes, servers, and routes?
A node is a selectable connection configuration in the client. It usually points to a server entry and includes protocol and authentication parameters. A node name may contain a country, region, city, entry type, or purpose label, but names are mainly for identification and do not fully describe the underlying network path.
A server is an infrastructure concept: it may be physical hardware, a virtual instance, or an environment running proxy services. One server can host multiple node configurations, and one node may point to different backends through a scheduling system. You therefore cannot infer the number of physical servers from the node count, nor assume every row in the interface represents completely independent hardware.
A route describes the path data takes from the user’s network to the entry point, then to the exit and the target service. It may involve local access, carrier interconnections, cross-border transport, relay entries, and the final exit. A node is a configuration the user can click; a route is the network path the traffic actually follows.
| Term | Primary meaning | Common misconception | What to check |
|---|---|---|---|
| Node | A selectable connection configuration in the client | Every node maps to a separate physical device | Region, protocol, entry point, and current connection performance |
| Server | Computing and network resources hosting proxy services | The server’s location must be the final exit location | Actual exit, routing, and server deployment |
| Route | The path traffic takes from the local network to the target service | A node name reveals the quality of the entire path | Entry method, relay path, exit, and target network |
| Exit | The network origin visible to the target website | The entry and exit regions are always the same | Exit address, DNS resolution location, and the target service’s policies |
Direct, relay, and IEPL routes
A direct route usually means the client connects straight to an overseas server without an additional entry point set up by the provider. Its structure is simpler, but performance is more exposed to local carriers, inter-network links, and changes in public international routing. A shorter geographic distance does not necessarily mean greater stability, because network paths do not follow a straight line on a map.
A relay route first connects to an entry point that is closer or better connected, which then forwards traffic to the target exit. Relaying can avoid some poor public-network paths and gives the server side more flexibility when adjusting exits, but it adds more hops. Congestion at the entry, forwarding segment, or exit can affect the final experience.
An IEPL dedicated route generally refers to international Ethernet private-line capacity connecting specific network endpoints. Its routing organization and resource guarantees differ from those of the ordinary public internet, but “dedicated” does not mean every segment from the user’s device to the target website is exclusively reserved. The access network to the entry, the network from the exit to the target service, and the local wireless environment still affect the final connection.
What do proxy protocol names mean?
A protocol defines how the client and server establish a session, verify authorization, encapsulate data, and handle transport. A protocol name does not indicate route quality: the same protocol can run on different networks, and different protocols can share the same exit. Actual performance also depends on the network path, server load, client implementation, transport layer, and target app.
| Protocol | Key characteristics | What to check during setup |
|---|---|---|
| Shadowsocks | A lightweight encrypted proxy protocol with broad client support | Encryption method, authentication details, and client support |
| VMess | Common in the V2Ray ecosystem, with authentication and multiple transport combinations | Whether the user ID, transport method, TLS, and path parameters match |
| Trojan | Often paired with TLS so the connection resembles ordinary encrypted traffic | Domain, certificate verification, password, and transport settings |
| VLESS | Authentication is relatively separate from the transport layer and is often combined with TLS or other security layers | User ID, flow control, transport method, and security-layer settings |
| Hysteria2 | Built on QUIC and UDP, focusing on congestion control to maintain transfers on challenging networks | UDP availability, authentication, TLS, and server parameters |
| TUIC | A QUIC-based proxy protocol supporting multiplexing and UDP forwarding | Client-version compatibility, congestion control, and certificate verification |
Why protocol parameters must match completely
A proxy connection requires more than checking one server address. The client and server must also agree on the port, authentication details, transport method, TLS settings, domain, path, and other parameters. Any mismatch in a key field can appear as a timeout, handshake failure, certificate error, or a connection that is established but carries no data.
Trojan and VLESS or VMess configurations with TLS usually require the domain and certificate verification to be handled correctly. Skipping verification may temporarily mask a certificate configuration issue, but it weakens the client’s ability to confirm the server’s identity and should not be a routine troubleshooting step. A better approach is to check the system time, domain, certificate chain, and subscription content for consistency.
Hysteria2 and TUIC rely on QUIC and UDP. Some office networks, public networks, or routers restrict UDP, so even a correct configuration may fail to communicate reliably. Switching to a TCP-based compatible configuration can help isolate the problem, but it does not mean one protocol is inherently better on every network.
The goal of protocol selection is not chasing the newest option. First check whether the client supports it fully, then whether the current network can carry its transport, and finally verify sustained connections with a real app. A protocol name describes the communication method; it cannot guarantee speed or stability on its own.
How system proxies, TUN, and VPN interfaces work
In a desktop client, “system proxy” usually changes the operating system’s proxy settings so apps that follow them send HTTP or SOCKS requests to the client. Setup is simple, but not every program reads system proxy settings. Some games, command-line tools, standalone updaters, or apps with their own network stack may continue connecting directly.
TUN mode creates a virtual network interface that receives traffic closer to the IP layer, then forwards it through a proxy or direct route according to the rules. It can cover more programs that do not support system proxies and is better suited to UDP, but it usually requires additional system permissions and may conflict with security software, other network tools, or enterprise network policies.
On Android and iOS, proxy clients usually use the system-provided VPN interface to take over traffic. Here, “VPN” mainly refers to the network-tunneling capability exposed by the operating system; the interface may still carry Shadowsocks, Trojan, or another proxy protocol. macOS often provides similar functionality through network extensions, while Windows clients may offer both a system proxy and TUN. Their coverage and permission requirements differ.
- ✅ If a browser works but a standalone app does not, check whether that app follows the system proxy.
- ✅ For programs that need UDP coverage or ignore proxy settings, evaluate TUN mode.
- ✅ If network problems appear after enabling TUN, check route conflicts, permissions, and other network tools.
- ❌ Do not enable multiple clients that take over network traffic and expect them to coordinate routes automatically.
What does “Allow LAN connections” mean?
This option usually allows other devices on the same local network to connect to proxy ports opened by the current client. It does not automatically give those devices the configuration or provide access control. After enabling it, check the listening address, firewall, and authentication settings to avoid exposing the local proxy port to an untrusted network. If proxy sharing is unnecessary, limiting access to the local machine is easier to manage.
How to choose Global mode, Rule mode, or Direct mode
Global mode usually sends all traffic taken over by the client through the current proxy node. It is useful for checking whether an app is skipping the proxy because of routing rules and for briefly testing the exit. Global mode still does not mean every piece of operating-system traffic is captured; if the client only enables a system proxy, programs that ignore it may continue connecting directly.
Rule mode chooses proxy, direct, or blocked handling based on domains, IPs, apps, ports, or rule sets. It avoids unnecessary detours and is the more common choice for everyday use. Rules need ongoing maintenance: domain changes, content-delivery network adjustments, or new app endpoints can make old rules incomplete.
Direct mode usually sends traffic around the proxy. It is useful for checking whether the local network itself works and for accessing resources limited to the local network. Direct mode is not exactly the same as “turning off the client,” because the client may still process DNS, a virtual interface, or rule logic; the details depend on the implementation.
| Mode | How traffic is handled | Best for | What to watch for |
|---|---|---|---|
| Global | All requests within the captured scope use the proxy | Testing a node and finding missed routing rules | Local services may take a longer route, and apps outside the captured scope may still connect directly |
| Rule | Choose a path based on domain, address, or app conditions | Everyday access with local and international traffic together | Rule sets need updates, and incorrect matches require attention |
| Direct | Requests bypass proxy nodes | Accessing local resources and checking the basic network | The client’s DNS or virtual interface may still be running |
In what order are routing rules matched?
Most rule engines check from top to bottom, stop after the first match, and let a fallback rule handle requests that match nothing. More specific app or domain rules should therefore usually come before broader regional rules. If a broad rule matches first, later precise rules will not take effect.
Dedicated domain for the target app → specified proxy group
Local service domain → direct
LAN address → direct
All other unmatched requests → default groupThis example illustrates priority, not configuration syntax ready for copy and paste. Different clients use YAML, JSON, graphical rules, or proprietary formats, and field names are not standardized. Before editing, confirm whether the configuration is maintained locally or generated by a remote subscription, so custom content is not lost after an update.
DNS leaks, resolution, and exit locations
Before visiting a domain, a device usually uses DNS to resolve it to an IP address. If webpage traffic goes through a proxy while DNS queries are sent directly through the local network, the queries are not following the expected path; this is commonly called a DNS leak. It may reveal the domains being queried, or cause access problems when local resolution differs from the proxy exit region.
Common DNS handling methods in clients include using the system resolver, forwarding queries to a remote server, retrieving results through encrypted DNS, or selecting a resolution path for each domain through the rule engine. Encrypted DNS protects queries in transit, but if requests still leave directly through the local network, it does not automatically mean they are resolved through the proxy exit. Check where the query originates, who answers it, and which route receives the result.
Some clients use a virtual-address mechanism that maps a domain to a reserved address first, then restores the domain internally and applies routing. This helps with programs that request only an IP address from the system, but some LAN services, enterprise software, or apps that rely on real-address checks may need exceptions. When you see options such as Fake IP, remote DNS, or DNS hijacking, do not switch them based on their names alone; consult the client documentation and confirm the current mode.
- ✅ If a target website will not open but a known address works when entered directly, check DNS resolution first.
- ✅ If the exit region is correct but content localization is wrong, check DNS and the app cache together.
- ✅ After switching nodes, refresh the DNS cache and app connection so an old session is not reused.
- ❌ Do not treat changing DNS as a universal fix for every connection problem.
A general troubleshooting order for client options
Client interfaces vary widely across platforms, but the troubleshooting order can remain consistent. First confirm that the subscription updates normally, then verify that the node parameters can establish a connection, next check how the system captures traffic, and finally address routing and DNS. This sequence avoids changing complex routing settings before the basic connection is working.
- Check subscription status: Confirm that the subscription is still valid, the latest update had no parsing errors, and the required nodes appear in the list.
- Choose a compatible node: Use a protocol the client explicitly supports, and verify the system time and TLS-related details.
- Verify the basic connection: Temporarily use Global mode to access the target service and distinguish a node failure from a missed rule.
- Confirm the capture scope: If the browser works but other apps do not, determine whether TUN or the system VPN interface is needed.
- Check DNS: Confirm that the resolution path matches the routing target, and clear old connections still being reused after switching routes.
- Restore everyday rules: Once the basic connection is stable, enable Rule mode again and check which group actually matched the target request.
Logs are another important clue. Subscription parsing errors, connection timeouts, TLS handshake failures, DNS query failures, and rule matches usually leave different records. When reading logs, look for the earliest key error first instead of being distracted by repeated retry messages. When submitting a support ticket, you can provide the error type, client name, platform, operating mode, and node category, but cover the subscription link, authentication details, and complete configuration.
For everyday use, you usually do not need to change low-level parameters often. Keeping the subscription updated, choosing a node compatible with the current network, using Rule mode, and checking TUN and DNS when a particular app is not captured covers most common situations. When manual configuration is truly necessary, adjust one variable at a time around a single problem so the result is easier to assess.