This beginner-friendly VPN glossary explains subscriptions, nodes, route types, protocols and split tunneling. These terms often appear together in clients and plan details, but they refer to configuration delivery, server entry points, network paths, transport methods and traffic decisions. Understanding each role before importing a subscription and choosing a node makes it easier to diagnose slow connections, inaccessible sites or app issues than repeatedly switching settings at random.
A subscription is not a client or a single node
A subscription is a remotely maintained configuration list provided by the service. It usually takes the form of a link or importable content and may include multiple nodes, node names, server addresses, ports, protocol parameters and other information required by the client. Once the client reads the subscription, it turns that data into a selectable list of routes.
“Buying a subscription,” “importing a subscription” and “connecting to a node” are three different actions. Having a subscription means the account has access to the relevant service configuration; importing it passes that configuration to a compatible client; connecting to a node selects an entry point from the imported configuration and establishes a connection. Completing only the first two steps does not automatically send network traffic through the proxy.
Why subscription links should be protected
Subscription links often contain a token used to identify an account configuration. Anyone who obtains the link may be able to read its node information or consume resources from the associated plan. Do not place it in public screenshots, forum posts, shared documents or public code repositories. When using it on another device you own, transfer it through a trusted channel instead of publishing the full link on a public page.
“Update subscription” in a client means requesting the list from the service again. When a provider changes entry points, route names or protocol parameters, an older client will not know about those changes automatically. If an update fails, first check whether the subscription is still valid, whether the client supports its format and whether the current network can reach the subscription URL. Do not immediately assume the node is broken.
- ✅ Copy the complete subscription link from the user panel without removing its trailing parameters.
- ✅ In a compatible client, choose “Import from URL” or an equivalent option.
- ✅ Run a subscription update once after importing and confirm that the route list loads correctly.
- ✅ Choose a node and connect manually, then check the system proxy or tunnel status.
- ❌ Do not paste a subscription link into online parsing sites or public support posts.
Nodes, entry points, exits and routes: how they relate
A node is a selectable connection configuration in the client. Names such as “Hong Kong,” “Tokyo” or “US West” generally describe the entry or exit region, but the name alone cannot fully reveal the path the data actually takes. Two nodes showing the same region may use different carriers, relay methods or protocols, so their real-world performance can differ.
The entry point is where the client connects first. The exit usually means where traffic finally reaches the target region’s internet—the location external websites see as the source. Some routes have their entry and exit in the same region; others first connect to a nearby relay server before forwarding traffic to a remote exit. A node name may show only the exit region, or also identify the entry point, carrier or intended use, so read it alongside the provider’s route description.
A region name is not a network path
The node region mainly answers “where does the traffic access the target website from?”, while the route type answers “how does the traffic get there?” When choosing a region, prioritize the target service’s regional requirements. When comparing routes, consider the local carrier, cross-border path, evening congestion and how sensitive the application is to latency or stability.
| Term | Main meaning | Common misconception | What to consider |
|---|---|---|---|
| Subscription | A configuration list maintained by the service | Treating a subscription as software that runs by itself | Format compatibility, update status and safe handling |
| Node | A set of connection parameters in the client | Assuming nodes in the same region use exactly the same path | Region, protocol, entry point and route details |
| Entry point | The server location the client connects to first | Assuming the default entry is the exit seen by websites | Network quality from your location to the entry point |
| Exit | The exit through which traffic enters the target region’s internet | Looking only at the name without checking the actual exit | Exit region and compatibility with the target service |
| Route | A combination of entry, relay, cross-border links and exit | Treating a route type as a regional label | Path stability, congestion and intended use |
IEPL Dedicated Routes, relays and direct connections
Direct connections, relays and IEPL dedicated routes describe how a cross-border path is organized, not the proxy protocol. The protocol determines how the client and server encapsulate and transmit data; the route determines the broad path those packets take through the network. A Trojan node may use a direct connection or be deployed through a relay or dedicated-route structure, so its protocol name alone does not indicate route quality.
Direct connection: connect straight to a remote server
A direct connection has the simplest structure: the local network accesses the remote node directly. Its performance depends heavily on the public routing between the local carrier and the remote data center. With a suitable path, it can handle ordinary browsing and lighter workloads. With detours or congestion, jitter, packet loss and connection setup delays become more noticeable. Switching to a node from another carrier in the same region can sometimes help more than repeatedly changing protocols.
Relay: connect to a nearby entry point first, then forward to the exit
A relay route adds an entry or forwarding layer between the local network and the remote exit. This can break a difficult long-distance public-network path into separate sections, with the provider managing the link from entry to exit. A relay is not automatically faster: entry load, the route from entry to exit and forwarding settings all affect the result. Its main value is often better path control in a particular network environment.
IEPL dedicated route: focus on how the cross-border segment is organized
IEPL generally refers to an international Ethernet leased-line style connection. When a service description mentions IEPL, it usually means the cross-border segment between the entry and exit uses specially arranged transport resources rather than relying entirely on ordinary public-internet routing. It still includes stages such as the user-to-entry connection and the exit-to-target-site connection, which may continue over the public internet. “Dedicated” therefore does not mean an exclusive end-to-end path from the device to every website.
To decide whether a dedicated route suits your situation, check whether the entry matches your local network, whether the exit region fits the intended use, whether the client connection is stable and whether jitter and packet loss remain acceptable during busy periods. Route labels provide structural clues; actual performance still needs to be tested on your own network.
| Route type | Path characteristics | Best suited to | What to watch for |
|---|---|---|---|
| Direct connection | Local network accesses the remote node directly | Ordinary browsing and networks with good native routing | Public-network detours, cross-border congestion and carrier differences |
| Relay | Connect to an entry point first, then forward to the remote exit | Situations requiring more control over long-distance paths | Entry load, relay links and exit quality |
| IEPL dedicated route | A specially arranged transport path across the cross-border segment | Use cases that prioritize stability, jitter control and sustained connections | The user-to-entry and exit-to-website segments still need checking |
Shadowsocks, VMess, Trojan, VLESS, Hysteria2 and TUIC
A protocol defines how the client and server establish a session, authenticate, encapsulate traffic and handle transport. Protocols differ in their reliance on TCP, UDP, TLS, QUIC and client cores. First check what the service provides and whether the client fully supports it. Then consider whether the current network restricts UDP, whether the system needs a virtual network interface and whether the application depends on a stable long-lived connection.
| Protocol | Core characteristics | Configuration focus | Common compatibility issues |
|---|---|---|---|
| Shadowsocks | A lightweight proxy protocol that protects client-to-server traffic with a pre-shared key and the selected encryption method | The server address, port, password and encryption method must match | Older clients may not support newer encryption methods or plugins |
| VMess | Common in the V2Ray ecosystem, with identity verification and multiple transport combinations | The user ID, transport layer, TLS and path parameters must match | Clock drift or mismatched transport parameters may cause the handshake to fail |
| Trojan | Typically carries proxy traffic over TLS and relies on certificate and domain configuration | The server name, certificate verification and password must be correct | Domain, certificate or system-time problems can affect the TLS handshake |
| VLESS | Uses a relatively simple authentication and transport design and does not provide a VMess-style encryption layer itself | Use it together with TLS, REALITY or another secure transport configuration | An outdated client core may not recognize newer transport parameters |
| Hysteria2 | Built on QUIC and UDP, with transport optimized for high-latency or lossy links | Authentication, TLS, bandwidth guidance and UDP reachability | It may fail to connect or behave unstably on networks that restrict UDP |
| TUIC | Also built on QUIC and UDP, with an emphasis on multiplexing and connection migration | User credentials, TLS parameters, congestion control and client version | Requires a client core that supports the relevant version and a usable UDP network |
A newer protocol is not automatically better on every network. Hysteria2 and TUIC depend on UDP; when an office network, public Wi-Fi or upstream device manages UDP strictly, a traditional TCP-based option may establish a connection more reliably. Conversely, when UDP is available and a long-distance link is jittery, QUIC-based protocols may deliver different transport performance.
TLS does not mean that enabling it makes every risk disappear. Certificate verification, the server name and transport parameters in configurations such as Trojan and VLESS must be correct. When a certificate error appears, do not treat disabling verification as a routine fix. First confirm the system time, subscription settings, domain and certificate chain.
How to choose between Global, rule and direct modes
Split tunneling determines which requests use the proxy and which connect directly. It is separate from the node region and does not change the protocol itself. A client showing “Connected” only means that the proxy core or system tunnel is running. Whether a particular app actually uses the selected node also depends on the system proxy’s coverage, virtual network interface status and matching rules.
Global mode
Global mode generally sends all traffic taken over by the client to the proxy. It is useful for temporary troubleshooting: if rule mode cannot open a target site but global mode can, the issue is more likely rule matching or DNS handling than a completely unavailable node. Global mode may also send local websites, LAN devices or region-sensitive apps through a remote exit, so it is not always suitable for long-term use.
Rule mode
Rule mode decides where traffic goes based on domains, IP addresses, apps or rule sets. Common actions include proxy, direct and reject. It can send international websites through the proxy while preserving access to local services and LAN devices, but its results depend on rule updates, DNS handling and match order. Domain rules generally need to take effect before names are resolved into IP addresses; otherwise the client may see only an address and be unable to classify the request by domain.
Direct mode
Direct mode sends traffic around the proxy and is commonly used to pause the service or verify the original network. If local resources remain inaccessible after switching to direct mode, the issue may be in the system network, browser cache, firewall or upstream network rather than the proxy node. After troubleshooting, confirm that the mode has been returned to the intended setting to avoid assuming traffic is proxied merely because a node is selected.
- ✅ When a target website behaves unexpectedly, briefly switch to global mode to distinguish a node issue from a rule issue.
- ✅ When a local website or LAN device behaves unexpectedly, check direct rules and private-address bypass settings.
- ✅ If an app does not follow the system proxy, check whether the client supports a virtual network interface or app-specific proxy settings.
- ✅ After changing rules, start a new connection so an existing connection does not continue using the previous exit.
- ❌ Do not import remote rule sets from unknown sources when you are unsure of their scope or effects.
DNS leaks, system proxies and virtual network interfaces
DNS converts domain names into network addresses. A DNS leak usually means that web traffic goes through the proxy while domain lookups are still handled by a resolver on the local network, making the lookup path differ from the expected path. This can cause confusing regional detection, broken rules or DNS results that do not match the proxy exit. “Leak” here does not mean that all content is exposed; it means DNS requests are not following the planned resolution path.
The system proxy mainly affects apps that actively follow the operating system’s proxy settings, such as most browsers and some desktop software. Certain games, command-line tools, store apps and software with its own network stack may ignore the system proxy. Virtual network interface mode takes over IP traffic at a lower level and usually covers more traffic, but it can also interact more readily with enterprise security software, other tunnels, LAN access and the system firewall.
“Enhanced mode,” “TUN mode” and “virtual network interface” in a client generally refer to this type of capability. Permission names and implementations vary across platforms. If the network stops working after enabling one, check virtual-interface permissions, the default route, DNS settings and whether another traffic-interception tool is running instead of repeatedly reimporting the subscription.
How to verify that the connection is working as expected
First open this site’s network check page to view exit information, then test sites that should use the proxy and sites that should connect directly. If the exit has not changed, check the current mode, system proxy and virtual network interface. If the exit is correct but domain resolution is still abnormal, update the rules and check the client’s DNS mode. If only one app is affected, see whether it bypasses the system proxy or retained an old connection.
Why clients look different across platforms
Windows, macOS, Android and iOS use different permission models for system proxies, virtual network interfaces, background operation and network extensions. As a result, the same subscription may show different options in different clients. Configuration compatibility does not mean that interface labels or traffic coverage will be identical.
Windows clients often offer both system proxy and virtual network interface modes. System proxy setup is simple but may not cover every app; virtual network interfaces cover more traffic and require the relevant driver or permissions. macOS usually takes over traffic through a network extension or system proxy, and the first activation may require approval for the network extension. If the connection stops working after a system upgrade, first check whether the extension permission is still valid.
Android clients typically use the system VPN interface to create a local tunnel and may offer per-app routing. A VPN indicator in the status bar only shows that the interface is running; it does not mean every domain uses the proxy. iOS likewise relies on a system network extension, while background status, on-demand connections and rule capabilities depend on both the client implementation and system permissions.
| Platform | Common traffic-control methods | First-use priorities | Check first when something goes wrong |
|---|---|---|---|
| Windows | System proxy, virtual network interface | Core, driver and firewall permissions | Proxy port, default route and virtual interface status |
| macOS | System proxy, network extension | Approve the network extension and proxy permissions | Extension authorization and permission status after system upgrades |
| Android | System VPN interface, per-app routing | Allow the system connection to be created | Background restrictions, per-app routing and always-on settings |
| iOS | System network extension | Allow network configuration to be added | On-demand connections, configuration permissions and background status |
When choosing a client, confirm that it supports the protocols and transport parameters in the subscription instead of checking only whether it can paste in the link. Some clients can import unknown fields but ignore unsupported transport settings, leaving the node visible in the list but unable to connect. In that case, update the client core or switch to a client explicitly listed as compatible in the service documentation.
A complete troubleshooting sequence from import to connection
Beginners often change the node, protocol, DNS, rules and virtual network interface at the same time, making it impossible to tell which setting helped. A more reliable approach is to check each layer in order: whether the subscription loads, whether the node can complete a handshake, whether traffic is being captured, whether rules match and whether DNS is consistent.
- ✅ Update the subscription and confirm that the client does not report a parse failure, expired authorization or unsupported format.
- ✅ Use the default node and protocol provided by the service first; do not change transport parameters immediately.
- ✅ Start a connection and review the client log to distinguish timeout, certificate, authentication and DNS errors.
- ✅ Temporarily use global mode to test the target website and confirm whether the node itself can carry traffic.
- ✅ Check the exit region, then test whether local sites and LAN resources connect directly as intended by the rules.
- ✅ Restore rule mode and review domain rules, app routing and DNS settings one by one.
- ❌ Do not run multiple clients that take over the system proxy or virtual network interface at the same time.
In logs, “timeout” usually means the connection was not completed within the allowed wait time, but possible causes include an unreachable server, a restricted port, unavailable UDP or packet loss along the path. “authentication failed” points more toward credentials, subscription status or mismatched parameters. TLS certificate errors should prompt checks of system time, server name and certificate chain. Wording varies by client, but these issues still fall into network reachability, authentication, transport negotiation and traffic interception.
If only nodes in one region are affected, first switch to another route of the same type to determine whether the issue is limited to one entry point. If every node fails, check the local network, subscription status and client permissions first. If the browser works but other apps fail, focus on system-proxy coverage and the virtual network interface. If pages load but regional detection is wrong, check the exit, DNS and split-tunneling rules.
With these terms understood, you can evaluate a service based on concrete needs: how easily the subscription updates, whether the client supports the target protocol, how clearly the entry and exit are documented, whether the route is direct, relayed or IEPL, whether rule mode can balance international access with local services and whether DNS and the virtual network interface are controllable. More terminology is not the goal; knowing which layer to inspect when something fails is.