When you first start using a cross-border network acceleration service, the biggest obstacle is often not the connect button but the terminology in the interface. A VPN glossary for beginners should answer one core question first: where do subscriptions, nodes, routes, protocols, and traffic rules fit into the connection process? Confusing these concepts can lead to mistakes such as thinking that changing the protocol changes the route, or assuming that importing a subscription has already connected you.
It helps to view a connection as a processing chain: the client reads the subscription configuration, you select a node, the client establishes a connection using that node’s protocol, and traffic rules decide which requests enter the connection. Behind the node, traffic may use a direct route, transit routing, or IEPL resources before reaching an exit server and the target service. There are many terms, but each has a specific place in the chain.
What subscriptions, nodes, and routes mean
Subscriptions: an updatable configuration list
A subscription usually appears as a link. When the client reads the content at that link, it receives node names, server addresses, ports, protocol parameters, and sometimes groups and rules. When the provider adjusts its nodes, you can update the subscription in the client instead of entering every item again.
“Import subscription” only means that the client has obtained the configuration; it does not mean a connection has been established. After importing, you still need to select a node, enable the system proxy or TUN mode, and confirm the client status. A subscription link may contain a token used to identify configuration access, so do not share it publicly or submit it to an untrusted online conversion page.
Nodes: selectable connection configurations in the client
A node is an option shown directly in the client. Each node configuration points to a specific endpoint and specifies the protocol and parameters required to establish a connection. Node names often include a region, use case, or route label, but the name itself is not technical proof. To decide whether a node suits the task, check the actual route, connection stability, and the target service’s response.
Routes: the transport paths behind nodes
A route describes the network path data takes from your local network to the entry point and then to the exit. Multiple nodes may share part of the same upstream route, or use different entry points connected to the same exit. A node is a configuration object in the client; a route is an operational and network resource. The two are not interchangeable.
| Term | Primary purpose | Where users see it | Common misconception |
|---|---|---|---|
| Subscription | Delivers and updates configuration for the client | Import screen, subscription management | A successful import means you are already connected |
| Node | Provides a selectable connection endpoint and parameters | Node list, proxy groups | The node name fully represents the underlying network quality |
| Route | Describes the path between the entry point, backbone network, and exit | Route descriptions, routing information | A route and a protocol are the same concept |
| Protocol | Defines how the client and server exchange data | Node details, client core information | The protocol name alone determines all speed performance |
What proxy protocols determine
A protocol defines how the client and server encapsulate, authenticate, and transmit data. It affects client compatibility, traffic characteristics, congestion handling, and support for TCP or UDP traffic, but the protocol name alone does not determine the experience. Server load, the local network, route quality, exit location, and client implementation also matter.
Shadowsocks, VMess, Trojan, and VLESS
Shadowsocks is an encrypted proxy protocol with a relatively straightforward configuration. Its stability depends on the server implementation, encryption method, and network environment. VMess is a communication protocol in the V2Ray ecosystem, supporting identity verification and multiple transport combinations. Client and server parameters must match.
VLESS uses a more streamlined protocol design and does not provide complete transport encryption by itself, so it is commonly combined with TLS or another secure transport layer. Trojan is built on TLS, making parameters such as the domain, certificate, and server name especially important during setup. Seeing “TLS” does not mean every configuration is automatically correct; disabling certificate verification or using a mismatched server name can still create risks.
Hysteria2 and TUIC
Hysteria2 and TUIC both rely heavily on QUIC and UDP transport, with their own transport and congestion-control mechanisms designed for high-latency or lossy networks. They are not necessarily faster on every network. If the local network has unreliable UDP support, the connection may fail during the handshake, fluctuate in speed, or remain unusable. Keep a TCP-based backup node available.
- ✅ The client explicitly supports the protocols and transport methods in the subscription
- ✅ Node parameters are imported directly from the subscription, avoiding missing server names or authentication details
- ✅ Keep a switchable TCP option when the UDP option is unavailable
- ❌ Change only the protocol name without updating the corresponding server configuration
- ❌ Disable certificate verification just to connect successfully and leave it disabled
What is the difference between direct connections, transit routing, and IEPL
Here, “direct” does not mean bypassing the client. It means the client connects directly to a server in the target region or outside mainland China, without a dedicated provider-managed entry point forwarding the traffic. The structure is simple, but the path depends largely on the local carrier and public-internet routing. Results can vary by network, time of day, and location.
“Transit routing” usually means connecting first to a nearby entry server, which then sends the traffic to the exit through another network path. Its value is that the provider can manage the access and exit segments separately and adjust the route according to network conditions. Transit routing also adds system complexity: a problem at the entry point, forwarding segment, or exit can affect the connection.
IEPL is an industry term for international Ethernet private-line resources. In an acceleration service, a common design has the user connect to an entry point, with private-line resources used on part of the path between that entry point and an overseas exit. It does not mean your device connects directly from home to a dedicated private line, nor that every segment from your local network to the entry point and from the exit to the target website leaves the public internet.
| Route type | Typical path | Main characteristics | Troubleshooting focus |
|---|---|---|---|
| Direct connection | Local network connects directly to the exit server | Simpler structure; clearly affected by public-internet routing | Check local carrier routing, exit reachability, and protocol compatibility |
| Transit routing | Local network connects to an entry point, then forwards traffic to the exit | The access and exit segments can be adjusted separately | Distinguish entry-point failures, forwarding issues, and exit problems |
| IEPL | Private-line resources are used between the entry point and the overseas exit | A private line usually covers only a specific segment of the path | Check entry quality, the private-line segment, and exit status |
How to choose between global mode and rule-based split tunneling
Global mode generally means that all traffic taken over by the client is sent through the current proxy node. It is useful for temporary diagnosis: if a destination is inaccessible in rule mode but works in global mode, the issue often lies in rule matching, DNS handling, or application traffic not being captured correctly. Global mode does not mean every piece of device traffic is necessarily captured, because browser extensions, system proxy settings, and TUN mode cover different scopes.
Rule mode uses domains, IP addresses, applications, or rule sets to decide whether traffic goes through the proxy, connects directly, or is rejected. It is usually better for everyday use: local services can stay direct while requests requiring cross-border access use the proxy route. Outdated rules, incorrect priorities, or unrecognized domains can cause a page’s main content to load while images, login requests, or video APIs fail.
System proxy and TUN mode
A system proxy relies on applications actively reading the operating system’s proxy settings. Most browsers follow these settings, but some games, command-line tools, and applications that manage their own network connections may ignore them. TUN mode uses a virtual network interface to capture more IP traffic, usually providing broader coverage while depending more heavily on system permissions, routing, and DNS configuration.
“Global” and “TUN” describe different dimensions. Global or rule mode describes traffic decisions; system proxy or TUN describes how traffic enters the client. A client can apply rule-based routing in TUN mode or use a global policy in system proxy mode.
- For the first connection, use the client’s recommended rule mode and confirm that frequently used websites and apps work normally.
- When a destination is inaccessible, temporarily switch to global mode for comparison. Do not change the node, protocol, and DNS at the same time.
- After global mode restores access, check which rule matched the target domain and update the relevant rule set.
- If an application ignores the system proxy, then assess whether TUN mode and the required system permissions are needed.
- After troubleshooting, restore the split-tunneling setup suited to everyday use so local services do not unnecessarily pass through a remote exit.
Understanding DNS leaks and exit IPs
Before accessing a domain, a device usually uses DNS to resolve it to an IP address. If web traffic passes through a proxy while DNS requests still go to the resolver specified by the local network, the DNS and proxy paths may diverge. This is commonly called a DNS leak. It can expose the range of domains being queried and may give traffic rules resolution results that do not suit the current exit.
An exit IP is the source address that a target website sees. Checking it after connecting to a node can confirm whether web traffic has left the network through the expected region, but it cannot by itself prove that DNS, UDP, or every application’s traffic follows the same path. A complete check should separately examine the exit address, DNS resolver, and whether the client has captured the application traffic.
Encrypted DNS protects the connection between the device and the resolver; it does not automatically ensure that DNS requests follow the proxy exit. If an encrypted DNS client connects directly to a locally reachable resolver, it may still bypass the proxy. A safer approach is to coordinate DNS handling with traffic rules: domains requiring the proxy should use a resolution path suitable for remote access, while local domains retain local resolution.
What to check when importing a client subscription
Client interfaces vary widely by platform, but the import workflow is broadly the same: obtain the subscription link, add it to the client, update the configuration, choose a node, and enable the appropriate traffic-capture method. Desktop systems commonly offer both a system proxy and TUN; mobile systems generally use the system-provided VPN interface to create a local virtual network, with the client handling routing and forwarding.
On macOS, a client may need network-extension or VPN-configuration permission. On Windows, enabling TUN requires the virtual network component to be installed correctly. Android clients request permission to create a VPN connection, while iOS clients capture traffic through the system VPN configuration. Seeing a VPN indicator does not mean the remote service uses a traditional VPN tunnel protocol; a proxy client may simply be using the system interface to forward traffic.
- ✅ Copy the subscription link from the service panel and check that no characters are missing
- ✅ Run an update after importing and confirm that the node list and protocol details load correctly
- ✅ Test with a standard node first, then switch to the route suited to your use case
- ✅ Check that the system proxy, TUN, or mobile system VPN configuration is enabled
- ✅ Verify the exit IP after connecting and test both local services and cross-border access
- ❌ Upload the subscription link to an unknown conversion website
- ❌ Run multiple clients that capture system network traffic at the same time
What order should you follow when troubleshooting common connection issues
The most important troubleshooting principle is to change only one variable at a time. If you change the node, protocol, mode, and DNS together, you will not know the real cause even if the connection recovers. Start with the smallest-impact checks, then move on to the client and local network.
- First confirm that the subscription can update. If the update fails, check whether the subscription has expired, whether the copied link is complete, and whether the client supports its format.
- Switch to a backup node using the same protocol. If only one node fails, the issue is more likely to be with that node’s entry point, route, or exit.
- Compare TCP and UDP options within the same node group. If Hysteria2 or TUIC is unavailable while the TCP option works, check whether the current network supports UDP properly.
- Temporarily use global mode for comparison. If global mode works but rule mode does not, focus on domain rules, DNS, and rule priority.
- Close other network tools that modify the system proxy, routes, or DNS to prevent multiple clients from competing to capture traffic.
- Switch to another local network for cross-checking. If results differ between local networks, first inspect carrier routing, UDP restrictions, or local gateway settings.
Practical settings for beginners
When starting out, there is no need to edit every advanced parameter manually. Import the subscription with a supported client, choose a node that connects reliably, and use rule mode. Enable TUN only if an application ignores the system proxy; adjust DNS only when a specific destination has resolution problems; switch protocols only when the current protocol is incompatible with the local network.
Route labels help narrow the options but should not replace real-world testing. Direct connections have a simple structure, transit routing makes it easier to adjust the access and exit paths, and IEPL describes private-line segments that may be used between the entry point and exit. The right setup should offer client compatibility, connectivity on the current network, normal responses from frequently used services, and switchable backup nodes.