VPN terminology can seem overwhelming, but it follows the order of a typical connection: the provider supplies a subscription link, the client reads its node configurations, a protocol establishes the connection, traffic travels over direct, relay or IEPL routes, and routing rules decide which requests use the proxy. Once this chain makes sense, most client settings stop feeling like disconnected terms.
In everyday conversation, “VPN” is often used as a broad term for proxy and network acceleration services, but the underlying technology is not always a traditional VPN tunnel. Shadowsocks, VMess, Trojan, VLESS, Hysteria2 and TUIC are different proxy protocols or protocol families. A VPN switch in system settings may simply mean that the client is taking over traffic through the operating system’s virtual network interface. To identify how a connection works, check the protocol, client mode and actual routing—not just the product name.
Starting with subscription links: they are not ordinary download URLs
A subscription link is a configuration entry point that a client can read. After accessing it, the client usually receives node names, server addresses, ports, protocol parameters and group information, then organizes them into a selectable node list. When the provider updates its routes, you can refresh the subscription in the client instead of editing each server configuration by hand.
A subscription link is not the same as a single-node configuration. The former is more like a continuously updated configuration list, while the latter describes one specific connection. Some clients also support importing an individual share link, but a standalone configuration will not receive later subscription updates automatically. When moving to another device, use the client’s built-in “Import from URL” or “Add subscription” option rather than opening the subscription as a webpage.
- ✅ Copy the complete subscription URL from the service dashboard, making sure its beginning, ending and query parameters are intact.
- ✅ In the relevant client, choose Add subscription instead of entering the URL in a single-node server field.
- ✅ Run one update after importing and confirm that node names and groups appear correctly.
- ✅ After changing the subscription URL, delete expired configurations to avoid selecting an old node by mistake.
- ❌ Do not treat a subscription URL as a route list for public sharing.
Nodes are not routes: direct, relay and IEPL explained
A node is a selectable connection entry in a client, usually named by region, city, purpose or route type. It answers “which configuration should I connect to?” A route describes how data travels from your local network to the exit server, answering “which path does the traffic take?” The same region may offer several routes, while one route may appear as multiple nodes in a client.
A direct route generally means that your network connects to an overseas server without a dedicated entry point or relay server deployed by the provider in between. The path is simple, but performance depends heavily on the public route from your local carrier to the destination region. Evening congestion, cross-network detours and fluctuations at international gateways can make the same node perform differently on different networks.
A relay route adds a forwarding point between you and the exit server. You first connect to a nearby or more stable relay server, which then sends the traffic to the final exit. A well-designed relay can avoid some unstable public routes, but using more servers does not automatically make a connection faster; the quality of the entry point, forwarding path and exit load still matter.
IEPL usually refers to an international Ethernet private-line product provided by a carrier. In proxy services, an IEPL node generally means that part of the route uses private-line or dedicated transmission resources, reducing reliance on ordinary international public routes. It should not be read as meaning that every segment is fully exclusive, and actual quality cannot be judged from the node name alone. A more practical approach is to consider your local network, target region and specific application together.
| Term | What it describes | Key characteristics | How to evaluate it |
|---|---|---|---|
| Node | A connection configuration in the client | Includes an address, port, protocol and name | Check the region, purpose and current availability |
| Direct route | The public path from your network to the exit | A simple path structure, clearly affected by public routing | Test performance from your network to the target region first |
| Relay | A route that passes through a forwarding point | Can change the path across networks and international segments | Compare it when direct routes are unstable |
| IEPL | Private-line or dedicated transmission resources | Reduces reliance on some ordinary public-network segments | Focus on the actual connection experience, not just the name |
| Exit | The server that ultimately accesses the target website | Determines the exit region visible to the target website | Choose based on content region and access needs |
How to read common protocols: different names, similar roles
A protocol defines how the client and server establish a handshake, authenticate, encrypt and transmit data. Nodes in the same region do not necessarily use the same underlying protocol, and the same protocol does not guarantee the same route quality. Protocols affect compatibility, traffic characteristics and performance across networks, while routes determine the network path the data actually takes. Keep these two concepts separate.
Shadowsocks
Shadowsocks is a lightweight encrypted proxy protocol. Its configuration usually includes a server, port, password and encryption method. It is mature and widely supported by clients, making it suitable for everyday web and application proxying. It is not a traditional enterprise VPN, and it does not automatically determine whether all system traffic uses the proxy; the final scope depends on the client’s system proxy, TUN mode and routing settings.
VMess and VLESS
VMess is commonly found in the V2Ray ecosystem and has its own authentication and transport settings. VLESS separates identity authentication from encrypted transport more clearly; in real-world deployments, it is commonly used with TLS, REALITY or other transport methods. When you see VMess or VLESS, do not compare protocol names alone. Also check the transport layer, server name, certificate parameters and whether the client supports the complete configuration.
Trojan
Trojan usually runs over TLS, with common settings including the server address, password, port and server name. It depends on correct TLS configuration. A badly wrong system clock, mismatched server name or failed certificate validation can all prevent a connection. Disabling certificate verification should not be a routine troubleshooting step; first confirm that the configuration is complete and the client version is compatible.
Hysteria2 and TUIC
Hysteria2 and TUIC both use QUIC transport over UDP and combine it with congestion control to improve performance on certain networks. They are not automatically faster everywhere: if the current network restricts UDP, a router handles it poorly, or the public network does not work well with long-lived UDP sessions, the connection may be less stable than a TCP-based option. In that case, switch protocols or routes instead of repeatedly increasing client parameters.
| Protocol | Common transport foundation | Settings beginners should check | Common compatibility issues |
|---|---|---|---|
| Shadowsocks | TCP and UDP | Encryption method, password and port | Older clients do not support newer encryption methods |
| VMess | Can work with multiple transport layers | Identity information, transport method and TLS parameters | Transport settings omitted during import |
| VLESS | Can work with TLS, REALITY and similar methods | Identity information, flow control and server name | The client lacks the required transport capability |
| Trojan | TLS and TCP | Password, server name and certificate validation | Time, domain or certificate parameters do not match |
| Hysteria2 | QUIC and UDP | Authentication, TLS and bandwidth-related settings | The current network restricts UDP |
| TUIC | QUIC and UDP | Identity information, TLS and congestion control | The client version or UDP environment is incompatible |
Routing rules and global mode: deciding which traffic uses the proxy
After connecting to a node, the client still has to decide where traffic goes. Direct means the request bypasses the proxy node; proxy means it is sent through the current node or proxy group; reject means the client blocks the request. Routing rules assign requests to these actions based on domains, IP addresses, applications, ports or rule sets.
Rules mode is also commonly called split-routing mode. A typical setup keeps local websites and LAN resources on direct connections, sends requests that need international routes through the proxy, and rejects advertising or known-risk domains. This reduces unnecessary detours and can prevent local services from triggering extra verification when the exit region changes. The trade-off is that rules require maintenance; when a website adopts a new domain or shared infrastructure, older rules may classify it incorrectly.
Global mode generally sends most traffic that the client can take over through the proxy. It is useful for checking whether a rule failed to match, or for situations that require a consistent exit for a short time. Global mode does not mean the client can take over every type of traffic on the device: a system proxy usually affects only applications that follow proxy settings, while TUN mode covers more traffic but can still be affected by operating-system permissions, route priority and an application’s own networking implementation.
Direct mode lets requests bypass the proxy. It can be used to pause the proxy’s effect or verify whether a problem originates with the node. After switching modes, reopen the target application if possible, because existing connections may continue reusing the previous network session and make it appear that the mode change did not take effect.
- ✅ For everyday browsing, use a well-maintained rules mode so local and international traffic take suitable paths.
- ✅ If a website will not open, temporarily switch to global mode to check whether a rule is missing.
- ✅ When a local service behaves unexpectedly, check whether its domain was incorrectly routed through the proxy.
- ✅ If LAN printing, file sharing or a router administration page fails, confirm that local addresses remain direct.
- ❌ Do not treat global mode as a speed boost; it only changes where traffic goes.
Client imports: system proxy and TUN are not the same
Client interfaces vary widely across platforms, but their core tasks are the same: save the subscription, parse nodes, establish a connection and take over traffic. A successful import only means that the configuration has entered the client; it does not mean system traffic is already using the proxy. You may still need to enable the system proxy, VPN configuration or TUN mode and grant the network permissions required by the operating system.
On desktop systems, a system proxy mainly writes to the operating system’s proxy settings. Browsers and most applications that follow system configuration will use it, but some games, command-line programs and software with its own networking stack may ignore it. TUN mode creates a virtual network interface and uses routing to take over a broader range of TCP, UDP and DNS requests. It suits cases that need coverage for more applications, but it is also more likely to conflict with enterprise VPNs, virtual machines, container networks or security software.
Mobile platforms usually establish a local tunnel through the VPN interface provided by the operating system. A VPN icon in the status bar means the client has system tunnel permission; it does not necessarily mean that the underlying technology is a traditional VPN protocol. iOS places platform limits on background operation, network extensions and subscription imports. Android offers more client choices, but customized system versions may handle background persistence, battery policies and always-on connections differently.
On Windows and macOS, installing a TUN driver or network extension may require administrator approval. Linux clients often provide a graphical interface, command-line core and transparent proxy options at the same time, so routing tables, DNS services and firewall rules need more deliberate configuration. Beginners do not need to start with the most complex transparent proxy setup. First use the client’s recommended mode to confirm that the subscription and nodes work, then adjust coverage based on the applications you need.
| Traffic takeover method | Coverage | Suitable scenarios | What to watch for |
|---|---|---|---|
| Browser proxy | A specified browser or extension | Web browsing only | Other applications do not follow automatically |
| System proxy | Applications that follow system proxy settings | Regular desktop browsing and office applications | Some programs bypass system settings |
| TUN mode | Traffic routed through a virtual interface | Games, command-line tools and more applications | May conflict with other networking tools |
| Mobile system tunnel | Application traffic the operating system allows the client to take over | Unified connections on mobile devices | Affected by background policies and system permissions |
What is a DNS leak? Domain lookups must follow the right path too
Before opening a website, a device usually uses DNS to resolve its domain into an IP address. If web traffic goes through a proxy while DNS queries are sent directly to a resolver provided by the local network, the lookup path and access path may differ. This is commonly called a DNS leak. It can reveal the domain being queried or return an address unsuitable for the current exit region, causing the site to fail, show the wrong regional content or take an indirect route.
Common client-side approaches include proxy DNS, encrypted DNS, virtual IPs and rule-based DNS routing. Proxy DNS sends queries through the proxy path. Encrypted DNS protects query traffic over HTTPS or TLS. With virtual IPs, the client first returns an address it manages to the application, then forwards the actual request according to domain rules. No approach is universally better outside its environment; the key is that DNS results and routing actions must agree.
For example, a domain may be assigned to the proxy by a rule while its DNS query goes directly through the local network and returns a special result, causing the subsequent connection to fail. Conversely, sending a local service to a remote resolver may return an address unsuitable for the local network. During troubleshooting, check the matched domain rule, selected DNS server, whether IPv6 is enabled and whether the browser has enabled secure DNS independently of the system.
Troubleshoot in sequence: narrow the issue from configuration to application
Beginners often change many settings in rapid succession and then cannot tell which change helped. A more reliable approach is to change one variable at a time, checking each layer from subscription and node to protocol, takeover mode, DNS and the specific application.
- ✅ Refresh the subscription first and confirm that the client does not show an authentication error, configuration parsing error or expired subscription.
- ✅ Choose another node of the same type to determine whether the problem affects one node or the entire client.
- ✅ On networks that restrict UDP, compare with an available TCP-based protocol.
- ✅ When rules mode behaves unexpectedly, briefly switch to global mode to check for a missing rule.
- ✅ If the browser works but other applications do not, check whether only the system proxy is enabled.
- ✅ If a domain will not open but a known service works directly, check DNS settings and the resolution path.
- ✅ Re-establish the connection after changing settings and close old network sessions in the target application.
- ❌ Do not change the protocol, node, DNS and routing rules at the same time, or the cause will be difficult to identify.
Also distinguish between “the node cannot connect” and “the target website cannot be reached.” The former usually occurs during the handshake, with the client showing timeout, authentication or certificate errors. The latter may result from incorrect routing, unsuitable DNS results, the website’s regional policy or application cache. A successful proxy connection only means that a channel has formed between the client and server; it does not mean every target service will respond normally.
Speed tests should not replace real-world checks. Initial page load, long-lived connection stability, file transfers and real-time communication place different demands on a route. For beginners, confirming a stable connection, correct DNS and accurate routing before comparing nodes for a specific use is more meaningful than repeatedly chasing a single test result.