The key to understanding VPN terminology is not memorizing a string of English abbreviations. It is knowing where subscriptions, nodes, routes, protocols and traffic routing fit in the connection process. They often appear side by side in a client, but they are not the same thing: a subscription delivers configuration, a node describes an available entry point, a route determines how data reaches a remote destination, a protocol defines how the client communicates with the server, and traffic routing decides which requests use that connection.
Think of the process like shipping a package: the subscription link is a continuously updated address book, a node is a delivery point selected from that book, the protocol defines the packing and handoff rules, the route is the transport path, and routing rules decide whether an item should use a dedicated route or a local path. Once this relationship is clear, the options in a client become much easier to understand, and troubleshooting is less likely to confuse a failed subscription update with a failed node connection.
What subscriptions, configurations and clients each do
A subscription link is neither a client nor a protocol
A subscription link is usually a dedicated address generated by the service. When a client accesses it, the client retrieves node names, server addresses, ports, protocol parameters and group information, then turns that data into selectable configurations. When routes are adjusted, updating the subscription provides the latest configuration without requiring every field to be entered manually.
Therefore, “subscription added” only means that the client can read the configuration; it does not mean every node has established a connection. If the subscription page will not open, the link was copied incompletely, or the client does not support the format, the problem is in configuration delivery. If the subscription updates successfully but the selected node cannot reach the target service, check the protocol, route, system proxy and DNS.
A dedicated subscription address may allow others to retrieve connection settings. Do not place the full link in public screenshots, public documents, search boxes or untrusted online conversion tools. If you suspect the link has been exposed, reset or replace it in the service dashboard.
The difference between a single-node configuration and a subscription
A single-node configuration contains the information needed for one connection entry. Common forms include text links, QR codes and manually entered parameters. A subscription can maintain a set of configurations and let the client fetch updates again later. Importing one node temporarily is useful for testing a specific protocol, while a subscription is easier to keep aligned with server-side route changes over time.
A QR code is simply one way to carry configuration data; it does not automatically improve connection security or speed. Check the source before scanning, then review the protocol, server domain and label recognized by the client after import. For configurations from unknown sources, the client cannot determine how the operator handles traffic on your behalf.
What the client does
The client parses subscriptions, establishes protocol connections, configures the system proxy or a virtual network interface, and forwards requests according to rules. Some clients handle only applications that follow the system proxy, while others can take over a broader range of system traffic through TUN mode. Even with the same subscription, clients may differ in DNS behavior, rule syntax, background keep-alive and system permissions.
- Before importing, confirm that the client supports the protocols and parameters used by the subscription.
- After updating the subscription, check whether the node list has changed as expected instead of repeatedly importing the same subscription.
- When switching clients, review routing, DNS and local network access settings again; do not assume they will migrate automatically.
- Before removing a device, clear the subscription links and cached configurations stored in the client.
Nodes, servers and routes are not synonyms
A “node” is a selectable connection entry shown to the user by the client. A node usually includes a server entry point and protocol parameters, but its name is only a label and may not fully describe the underlying deployment. Multiple nodes may use different entry points to reach the same region, or share part of the same network resources. Even under the same city label, paths may differ between direct routes, relays and dedicated lines.
A “server” refers more to the computing and network resources themselves, while a “route” emphasizes the path data takes from your network to the server. A region name in the node list indicates only the remote exit or the location labeled by the service; it cannot by itself reveal route quality. Your experience also depends on the local network operator, inter-network connectivity, congestion, routing detours, the protocol and the target site’s response.
| Route type | Connection method | Typical characteristics | What to evaluate |
|---|---|---|---|
| Direct | The client connects directly to the remote entry point | A simpler path structure; quality depends more on the local network and public Internet routing | Watch for inter-network detours, evening congestion and reachability of the remote entry point |
| Relay | The connection first reaches a nearby or more stable entry point, then forwards traffic to the remote destination | Can adjust part of the public route, but the relay entry point may become a bottleneck | Distinguish between entry-point failures, forwarding-link failures and remote-exit failures |
| IEPL dedicated line | Carries part of the cross-border path over an international Ethernet private line | Focuses on transport-path design; it is not an application-layer encryption protocol | Still evaluate it together with the protocol, entry method and target service performance |
IEPL is a route-layer concept, not a “more advanced VPN protocol.” The client still needs a protocol to communicate with the server, and application data still passes through DNS resolution, route selection and target-site processing. Comparing IEPL directly with Trojan, VLESS or Shadowsocks in the same option group is like comparing a transport road with packaging rules: they belong to different dimensions.
Regions should not be chosen solely by physical distance. When accessing a region-restricted service, the exit region needs to match the target’s requirements. For ordinary web browsing, start by comparing connection stability and route quality. Labels such as “high speed” or “optimized” in node names are only classification hints; actual evaluation should reflect your network, usage hours and target service.
First identify the exit region required by the target service, then compare route types and real-world stability within that region. Do not rely only on momentary latency in the client, and do not treat region, protocol and route as the same metric.
How to understand and choose common protocols
A protocol defines how the client and server perform handshakes, authentication, encapsulation and data transfer. Interfaces often group several proxy protocols under the broad “VPN” category, but technically they are not all equivalent to traditional system-level VPN protocols. Whether an entire device’s traffic can be handled often also depends on whether the client enables TUN, a virtual network interface or system-provided VPN permissions.
Shadowsocks
Shadowsocks is an encrypted proxy protocol. Its configuration usually includes a server, port, password and encryption method. The implementation is lightweight and the client ecosystem is broad, but compatibility depends on the encryption suites and extensions supported by both sides. If authentication or encryption methods are incompatible after import, first check the client version and configuration fields rather than repeatedly switching nodes.
VMess and VLESS
VMess includes authentication and transport settings and can be sensitive to system clock drift. If the device time is significantly wrong, the handshake may fail. VLESS focuses more on streamlined authentication and forwarding; it should not be treated as a complete encryption layer. Deployments commonly pair it with TLS, REALITY or other transport-security settings. When reviewing a VLESS configuration, check the security layer, transport method, server name and certificate-related parameters together.
Trojan
Trojan usually runs over TLS, with configuration fields for the server domain, password, certificate verification and server name. TLS does not make certificate checks optional. Disabling verification may temporarily hide a configuration error, but it weakens confirmation of the server’s identity. If certificates do not match, check that the domain, system time, server name indication and configuration correspond.
Hysteria2 and TUIC
Hysteria2 and TUIC both rely heavily on QUIC and UDP, with an emphasis on congestion control and multipath performance in complex network conditions. Their suitability depends on whether the current network supports UDP. Some corporate, hotel and public networks restrict UDP, which can cause handshake failures or instability after a network change. In that situation, compare against an available TCP-and-TLS configuration instead of assuming the entire subscription is broken.
| Protocol | Transport focus | Common checks |
|---|---|---|
| Shadowsocks | Encrypted proxy and implementation compatibility | Encryption method, password and extension support |
| VMess | Authentication and transport parameters | System time, user identity and transport configuration |
| VLESS | Authentication combined with an external security layer | TLS or REALITY parameters and server name |
| Trojan | TLS connection and password authentication | Certificate, domain and system time |
| Hysteria2 | QUIC- and UDP-based transport | UDP reachability, congestion and network changes |
| TUIC | QUIC-based connections and multiplexing | UDP restrictions, authentication parameters and client compatibility |
A protocol name does not directly indicate speed. Connection performance depends on the local access network, route, server load, congestion control, packet loss and target site, among other factors. Choose a client-compatible, stable connection first, then compare actual performance on the same network, in the same region and at similar times.
How routing, rule mode and global mode relate
Routing answers the question, “Where should a particular request go out?” A client can usually send a request through a proxy, connect directly or reject it under specific conditions. Rules may match domains, IP addresses, applications, processes or geolocation databases. When rules are checked from top to bottom, the first matching entry usually determines the final path, but follow the rule documentation for the specific client you use.
Rule mode
Rule mode chooses a path based on preset conditions. For example, frequently used local services can connect directly, destinations requiring international routes can use the proxy, and local network addresses can remain local. This reduces unnecessary detours and helps prevent local device management pages from being sent to a remote destination. The drawback is that rules require maintenance: when a site changes domains, calls new content delivery domains or uses multiple interface groups, older rules may miss some requests.
Global mode
Global mode usually means that traffic taken over by the client all passes through the current proxy node. “Global” does not necessarily mean every packet on the device: if the client only sets a system proxy, applications that ignore it may still connect directly. A browser’s independent secure DNS may also bypass the resolution path expected by the client. Only by considering TUN or a system-level network interface, DNS settings and client permissions can you determine the actual scope of traffic takeover.
Direct mode
Direct mode sends traffic without the remote proxy. It is useful for temporarily disabling the connection or checking whether a problem comes from the proxy path. Direct mode does not necessarily close the client; some clients retain local DNS, the rule engine or a virtual interface. During troubleshooting, distinguish between switching to a direct routing policy and fully disconnecting and restoring the system’s network settings.
Practical approach: start with rule mode for everyday use. If rules clearly miss some destinations, briefly switch to global mode for comparison. If a local service behaves unexpectedly, use direct mode to confirm whether the issue comes from the routing path.
Domain chains are where routing rules most often fail. When a user opens a webpage, it may continue loading login APIs, images, video, fonts or content delivery resources. Sending the main domain through a proxy does not mean every related domain will use the same path. If the page framework loads but images, login or playback fails, check the client log to see which rule matched the failed request.
How to check DNS leaks and resolution paths
DNS converts domain names into network addresses. A DNS leak generally means that domain lookups expected to use a controlled proxy or encrypted resolution path were instead sent through the local network’s default DNS. This can make the resolution result inconsistent with the exit region and may reveal the domains being queried. It does not mean all content has been exposed—HTTPS still protects application content—but the resolution path remains important for privacy and availability.
Common causes include a client that handles application traffic but not DNS, a browser with independent secure DNS enabled, the system selecting a default resolver across multiple network interfaces, rules sending the DNS server address directly, or settings not being restored correctly after a virtual interface exits. Some clients use DNS interception to route system queries through their own resolver; others require manual configuration of remote and direct DNS.
- Before and after connecting, check whether the system’s current DNS servers and exit network match expectations.
- Check whether the browser has independent secure DNS enabled, and confirm that it matches the routing target.
- Look in the client log for domain-resolution requests and see whether each matched a proxy, direct or reject rule.
- After switching nodes, clear stale DNS cache so old results are not mistaken for a problem with the new route.
- After disconnecting the client, confirm that system resolution has returned to normal and that no leftover virtual interface affects subsequent connections.
Also account for differences between IPv4 and IPv6. If the proxy handles only one address family while the system prefers the other, some connections may bypass the expected path or load slowly because the target address is unreachable. Do not simply disable all IPv6. First confirm that the client, subscription configuration, TUN implementation and current network support it together, then decide whether to use dual-stack resolution or return only supported addresses.
Why clients behave differently across platforms
The same subscription may behave differently on Windows, macOS, iOS, Android and Linux. The cause is usually not the subscription itself, but differences in system network interfaces, permission models and background policies. When comparing clients, focus on protocol compatibility, system-level traffic handling, DNS capabilities, rule formats and maintenance—not just similar interfaces.
Windows and macOS
Desktop systems commonly offer system-proxy and TUN approaches. System proxy setup is simple but covers only applications that follow the setting. TUN can handle more types of traffic, but it requires virtual network permissions and may conflict with firewalls, virtual machines, container networks or other network tools. On macOS, also review system network-extension permissions; on Windows, check that the virtual adapter and routes are properly cleaned up after an abnormal exit.
iOS and Android
Mobile systems usually use the VPN interface provided by the operating system to handle traffic. iOS clients are constrained by system extension capabilities and background policies, and supported protocols and rule syntax can vary by app. Android clients often offer per-app proxying, sending selected apps through a node while keeping others direct, but battery-saving policies may pause the client after the screen locks. When switching between Wi-Fi and mobile data, also check whether the tunnel rebuilds automatically.
Linux
Linux environments vary widely. Traffic may be handled through a desktop system proxy, TUN, routing tables or a transparent proxy. Command-line programs often do not automatically read desktop proxy settings, so use environment variables, application settings or system-level forwarding as appropriate. With containers, distinguish between the host, container network and DNS namespace; verifying the host connection alone does not prove that the container uses the same path.
Being able to import a subscription does not mean every protocol in it will run. First check whether the client supports the relevant protocol, transport layer, security layer and subscription format, then verify that its TUN and DNS capabilities fit the way you use the current platform.
A complete workflow from import to troubleshooting
The most effective approach for beginners is to change one condition at a time. If you change the node, protocol, client and DNS simultaneously, even a recovered connection will not reveal the real cause. The sequence below separates configuration delivery, protocol handshaking, system traffic handling and target-service issues step by step.
- Verify the subscription source.Copy the complete subscription address from the service dashboard rather than routing it through a public conversion site. After pasting, check for extra spaces or missing characters at either end.
- Update and inspect the list.Have the client actively update the subscription and confirm that node names and protocols appear. If it fails at this stage, first check the link status, network access and subscription format.
- Choose a compatible node.Start with a protocol the client explicitly supports and make sure the system clock is synchronized automatically. For TLS connections, also check the domain and certificate parameters.
- Start with the simplest traffic-handling method.First verify whether the system proxy is enough for browser access, then enable TUN if games, command-line tools or other applications that ignore the system proxy require it.
- Check the routing match.Open the client log and confirm whether the target domain uses the proxy or a direct connection. If only part of a page fails, continue checking the rule results for related domains.
- Verify DNS.Check whether the system, browser and client are each using different resolvers, and confirm that the lookup path matches the expected exit region.
- Run a single-variable comparison.Keep the region and client unchanged while switching only the route or protocol; alternatively, keep the node unchanged while switching between rule and global mode, and record the differences.
If every node fails to update, the problem is more likely subscription access, client parsing or the local network. If only one protocol fails, check protocol compatibility, UDP restrictions, system time and security-layer parameters. If only one website fails, focus on routing, DNS, the browser session and the target service’s regional requirements. This classification is more useful than randomly switching nodes over and over.
A successful connection does not prove that the configuration is fully correct. Also verify that local sites are not being routed remotely unnecessarily, local network devices remain reachable, the connection resumes after sleep and wake, DNS updates after a network change, and the system proxy is restored after the client exits. Stable use depends on complete system behavior, not just a client button that says “Connected.”
The subscription delivers configuration to the client, the node is a selectable connection entry, the protocol defines client-server communication, the route describes the network path, and routing decides whether each request uses the proxy or connects directly. Following this chain layer by layer during troubleshooting usually helps locate the issue faster.