This beginner’s VPN glossary answers four common questions: What is a subscription? How should you choose a node? How do protocols differ? Which routing mode should you use? Keep this flow in mind: the service provides the configuration, the subscription link delivers it, the client reads it, the node determines the exit point, the protocol defines transmission, and routing rules decide which connections use the selected route.
These terms often appear together in a client, but they are not interchangeable. Once you understand their roles, you can troubleshoot failed imports, nodes that connect but cannot load pages, or local services that slow down after switching to global mode without repeatedly reinstalling the client.
What is the relationship between subscriptions, clients, and nodes?
An account gives you access to the service dashboard and lets you manage your plan. A client is the connection tool installed on your device. A subscription link is an address containing access credentials; the client uses it to retrieve node names, server addresses, ports, protocols, and related parameters. All three matter, but they serve different purposes.
A subscription link is not an ordinary webpage bookmark. Compatible clients can use it to retrieve a full set of connection configurations, so treat it like account credentials. Posting the link publicly or sending it to an untrusted conversion site gives someone else access to those configurations. When changing devices, copy the link again from the service dashboard instead of searching for an old version in your chat history.
Subscription Links vs. Single-Node Links
A subscription link usually returns a group of nodes and can be updated in the client. A single-node link describes one specific connection and is useful for temporary imports or manual testing. If the service adjusts its routes, a subscription update can synchronize names and parameters; a manually saved single-node configuration may continue pointing to an old address.
Some clients support QR-code scanning, clipboard imports, URL-based additions, or local configuration files. Although the menu names vary, each option writes a remote or local configuration into the client. A successful import only means the format was recognized; it does not mean the route is reachable. You still need to select a node, start the connection, and confirm that system traffic is actually entering the client.
| Term | Primary purpose | Common misconception |
|---|---|---|
| Account | Access the dashboard and manage plans, subscriptions, and client entry points | Assuming that being signed in means a route is connected |
| Subscription link | Provide the client with an updateable set of connection configurations | Treating it as an ordinary public URL to forward |
| Client | Parse configurations, establish connections, and capture or forward traffic | Assuming every client supports exactly the same protocols and rules |
| Node | Represent a selectable combination of connection entry and exit points | Looking only at the name instead of the region, route, and protocol |
How to distinguish nodes, entry points, exit points, and routes
A “node” in a client is usually a selectable connection configuration. It may include an entry address, protocol, authentication details, and exit region, but the node name itself is not a complete network topology. A region in the name usually indicates the exit used for external access; the actual traffic may still pass through carrier networks, relay entry points, or dedicated route resources.
The entry point is where the client connects first. The exit point is the apparent source location seen by the destination website. Entry and exit points may be in the same region, or the service may connect them through internal links. For users, the exit region affects content availability, account risk controls, and access paths; entry quality affects whether the local network can establish a stable connection.
Direct Connections, Relays, and IEPL
A direct connection means the device connects straight to the destination server, without an additional forwarding entry arranged by the service. Its structure is simple, but performance depends more heavily on the public route from the local carrier to the destination region. Evening congestion, inter-carrier links, or changes at the international gateway can directly affect the experience.
A relay route first connects to a nearby or more reachable entry point, then the service forwards traffic to the exit. A relay is intended to adjust the public route, not to guarantee higher speed. Congestion at the entry, limited relay capacity, or a heavily loaded exit can still affect results. Judge relay routes by real stability and suitability for the target region, not by the name alone.
IEPL generally refers to an international Ethernet private-line connection. A service may use it to carry traffic between the entry and exit, making that segment less dependent on ordinary public-internet forwarding. Keep in mind that an “IEPL” label in the client cannot by itself prove the complete path, available capacity, or service level. Choose based on actual stability, the target application, and the local network.
| Route type | Path characteristics | What to focus on |
|---|---|---|
| Direct | The device accesses the remote server directly | Public-network quality from the local carrier to the exit region |
| Relay | Traffic reaches an entry point first, then is forwarded by the service to the exit | Entry reachability, relay capacity, and exit suitability |
| IEPL | The entry-to-exit segment may use a private-line connection | Actual stability, service details, and use case |
What common protocols are designed to do
A protocol defines how the client and server encapsulate, authenticate, and transmit data. Even in the same region, different protocols may use different handshakes, transport layers, congestion controls, and client support. Protocols are not simply ranked from “old” to “new,” and no single option works best on every network.
Shadowsocks
Shadowsocks is an encrypted proxy protocol with a relatively straightforward design and broad client support. It is commonly used for browser and application proxies and rule-based routing. Strictly speaking, it is not the same type of technology as a traditional VPN protocol that takes over an entire network interface; whether all applications can use it depends on the system proxy, virtual network interface, and routing implementation.
VMess and VLESS
VMess is a protocol in the V2Ray ecosystem with authentication and transport settings, and it can work with different underlying transports. VLESS emphasizes lightweight authentication and traffic forwarding, and typically needs to be paired with TLS, REALITY, or another secure transport configuration. When using a VLESS node, entering only the server address and port is not enough; the transport, server name, path, fingerprint, and other parameters must also match the server.
Trojan
Trojan usually runs over a TLS connection, so the client must correctly handle certificate verification, the server name, and authentication details. A certificate-name mismatch, an incorrect device clock, or wrong TLS parameters can all appear as a handshake failure. Permanently disabling certificate verification for troubleshooting is not appropriate; check the subscription configuration and the server requirements instead.
Hysteria2 and TUIC
Hysteria2 and TUIC both use modern UDP-based transport mechanisms and focus on connection performance in congested environments. They may work better on some high-loss or unstable networks, provided the current network permits the relevant UDP traffic and the client core supports the protocol. If a company, campus, or public network restricts UDP, they may perform worse than a TCP-based route that can connect normally.
| Protocol | Core characteristics | What to troubleshoot |
|---|---|---|
| Shadowsocks | Encrypted proxy with a relatively straightforward configuration | Encryption method, authentication details, and system proxy status |
| VMess | Can work with multiple transport methods | Identity parameters, transport type, path, and server name |
| VLESS | Lightweight authentication, often paired with secure transport | TLS or REALITY parameters and client compatibility |
| Trojan | Usually establishes connections over TLS | Certificate, server name, and device clock |
| Hysteria2 | UDP-based, focused on transport in congested environments | UDP reachability, client core, and configuration version |
| TUIC | QUIC-based proxy transport | UDP restrictions, authentication parameters, and client support |
Split tunneling, global, rule-based, and direct modes
Once a connection is established, the client still has to decide where each request should go. This is routing mode. Common options include global, rule-based, and direct modes. The names are similar, but definitions can vary slightly between clients, so check the current client’s documentation before switching.
Global mode generally means sending as many client-managed connections as possible through the selected node. It is useful for checking whether an application was left out by a routing rule and for short troubleshooting sessions. However, local websites, LAN devices, and system updates may also be sent through a remote route, changing how speed and location appear.
Rule-based mode uses domains, IP addresses, applications, or rule sets to decide whether traffic goes direct, through a proxy, or is blocked. It is better suited to everyday use, but the rules need maintenance. New domains, content-delivery domains, and embedded application services may not be recognized, causing the main page to load while images or sign-in components fail.
Direct mode generally means requests do not pass through the selected node. It can pause routing, access LAN devices, or help determine whether a fault comes from the proxy path. The client interface may still show that it is running in direct mode, so “the client is running” does not mean “traffic is passing through a node.”
- ✅ For everyday use, start with rule-based mode so local services and requests needing international routes are handled separately.
- ✅ If an application cannot connect, briefly switch to global mode for comparison and check whether a rule is missing.
- ✅ When accessing a printer, storage device, or router admin panel, make sure LAN addresses remain direct.
- ❌ Do not change the node, protocol, DNS, and routing mode at the same time before locating the problem.
- ❌ Do not assume global mode lets the client take over every type of special traffic on the system.
System Proxy and Virtual Network Interfaces
The system proxy mainly affects applications that follow the operating system’s proxy settings. Some games, command-line tools, or software with its own network stack may ignore them. Virtual network interface mode, often called TUN mode, captures more traffic at the network layer and therefore usually has broader coverage. It also requires system permissions and may conflict with firewalls, other network tools, or enterprise policies.
If a browser works but a standalone application does not, first check whether that application reads the system proxy. If the client offers TUN mode, enable it according to the official instructions and compare the results. If LAN access becomes unreliable, check the LAN bypass rules instead of deleting the entire routing configuration.
DNS, DNS Leaks, and Domain Resolution
DNS converts domain names into addresses that can be reached. What looks like a single webpage request usually begins with domain resolution and then connects to the returned address. If domain queries use the local network while the subsequent connection uses a remote route, the result may not match the exit region, and the local resolver may be able to see which domains were queried.
A DNS leak generally means that DNS queries expected to follow a client-defined route were actually sent to an unintended resolver. It does not mean that all connection contents were exposed, and a page failing to load alone is not enough to prove one. During troubleshooting, check the client’s DNS settings, system network interfaces, the browser’s secure DNS feature, and the current routing mode together.
Remote Resolution, Local Resolution, and Fake IP
With remote resolution, queries are handled through the proxy side or a designated remote resolver, helping align the resolution location with the exit route. Local resolution is usually more direct and suits local services, but it may return addresses intended only for the local network. In rule-based mode, clients often choose different resolution paths by domain category.
Fake IP is a mechanism used by some clients for routing. The client first returns an internal mapped address to the application, then uses the mapping to identify the original domain and decide the route. This helps with connections that expose only a destination IP, but some LAN services, specialized applications, or enterprise environments may be incompatible and require exclusion rules.
Why Clients Behave Differently Across Platforms
After importing the same subscription into different clients, the number of nodes, their names, or the available protocols may differ. This usually reflects differences in the client core version, protocol support, rule format, and operating-system permissions rather than random changes in the subscription. When a client cannot recognize Hysteria2 or TUIC nodes, it may ignore them or display them and report that they are unsupported when connecting.
Desktop systems usually offer both a system proxy and TUN mode, making it easier to balance compatibility and traffic coverage. Mobile systems rely on the VPN interface provided by the operating system, so sleep behavior, battery-saving policies, and network changes can affect connection persistence. Router clients are constrained by processor performance, memory, firmware components, and rule-set size, so do not copy every advanced desktop setting onto a router.
Clients may also use different terminology. “Proxy mode,” “routing mode,” and “outbound mode” may all describe traffic selection, while “update subscription,” “refresh configuration,” and “sync nodes” usually mean reading the subscription again. Check the actual documentation rather than relying on a button label alone.
The Correct Order for Importing a Subscription
- ✅ Copy the current subscription link from the service dashboard and make sure it contains no extra spaces or line breaks.
- ✅ Use a compatible client listed in the service documentation, and avoid outdated cores that do not support the relevant protocols.
- ✅ Choose “Import from URL” or the equivalent option in the client, then complete the subscription update.
- ✅ Keep the default protocol, DNS, and rules at first, and connect using one node in the target region.
- ✅ Open the application you need and confirm that the exit location and access results are as expected.
- ❌ Do not submit the subscription link to an online conversion page from an unknown source.
- ❌ Do not publicly share a QR code or configuration file containing access credentials just to make importing easier.
Which Troubleshooting Path to Follow When a Connection Fails
Effective troubleshooting depends on changing one variable at a time. First confirm that the subscription can update, then check whether the node can complete a handshake, verify that system traffic is entering the client, and finally inspect DNS and routing. Skipping the earlier steps and changing advanced settings often turns one problem into several.
The Subscription Will Not Update
First confirm that the link was copied in full, the plan is active, and the client can access the subscription address. If the client reports a format error, check whether the selected import option supports a subscription URL rather than only a single-node link or local file. A failed subscription update and a failed node connection are different stages; repeatedly switching nodes will not fix the former.
The Node Is Selected but Cannot Connect
Focus on protocol compatibility, the system clock, TLS parameters, UDP restrictions, and the local firewall. Within the same client, you can switch to another known-working protocol for comparison. If every node fails at once, inspect the local network and client permissions; if only one node fails, consider the status of that specific route.
The Client Shows Connected but the App Cannot Access the Internet
First compare rule-based and global modes to identify a missing routing rule. If the browser works but a standalone application does not, check whether the application ignores the system proxy and consider whether TUN mode is needed. If domain resolution fails while a known address works directly, the issue is more likely in the DNS layer.
The Access Location Does Not Match the Selected Region
First rule out browser cache, account region, location permissions, and the application’s own regional settings. Websites do not determine location from the exit IP alone; previous sign-in data and content-delivery caches may also influence the result. After confirming that traffic is actually passing through the node, clear the relevant site data and test again.
The terminology map every beginner should remember
The account is the management entry point, the subscription link is the configuration credential, the client is the execution tool, the node is a selectable connection, the exit point determines the external location, the protocol defines the transmission method, the route describes the network path, DNS handles domain resolution, and routing rules decide whether requests go direct or through the selected node.
Direct connections, relays, and IEPL describe how paths are organized; Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC describe transport protocols; global, rule-based, and direct modes describe how traffic is allocated. Keeping these three groups separate is enough to handle most first-time configuration issues.
Only a few habits are worth keeping long term: protect the subscription link like a credential, use a compatible client, start with the default configuration, choose a node by target region, and troubleshoot in this order: subscription, protocol, system capture, DNS, and routing. This is more reliable than collecting supposedly universal settings.