This VPN glossary for beginners starts with the shortest answers: a subscription is an updatable collection of connection configurations; a node is an access option you can select in the client; a route is the network path the data actually takes; and a protocol defines how the client and server establish and maintain a connection. Split tunneling determines which requests use the selected route and which continue over the local network.
These terms often appear together in a client interface, but they describe different layers. Mixing them up can lead to treating “update subscription” as “switch route,” or repeatedly reinstalling the client when a node is unavailable. The right order is to confirm that the client can read the subscription, verify that a node can establish a connection, choose a route for the intended use, and then check whether split tunneling and DNS settings behave as expected.
What exactly is a subscription link
A subscription link is the address a client uses to read configuration data. The server provides a set of node details at that address, and the client imports them into a selectable list. Node names, server addresses, ports, protocol parameters and authentication details are usually supplied by the subscription, so users do not have to enter each item manually.
A subscription is not the same as a persistent connection. A successful import only means that the client read the configuration; when you actually connect, the client uses one of those nodes to establish a session. A subscription is not an ordinary web bookmark either. Opening it in a browser may show encoded text, download a configuration file or return content that is not meant to be read directly. None of these outcomes necessarily means the link is invalid.
The Difference Between Importing, Updating and Switching
- ✅ Import a subscription: add the configuration set to the client. This is usually needed when setting it up for the first time or after reinstalling.
- ✅ Update a subscription: fetch the node names, addresses and parameters published by the server again to sync route changes.
- ✅ Switch nodes: select another access option from the imported list without creating a new subscription.
- ✅ Start the connection: let the client handle eligible network requests according to the current node and split-tunneling mode.
- ❌ Do not paste a subscription link publicly in forums, screenshots or shared documents; it may contain credentials used to identify the subscription.
After a subscription update, the client may keep old nodes or replace them with the new list, depending on how the software works. If the list is clearly outdated, use the client’s built-in update function before deleting all configurations and importing everything again. Before deleting anything, also check whether custom split-tunneling rules are stored in the same file as the subscription configuration so they are not lost together.
How nodes, servers and routes differ
A node is a user-facing connection entry. It usually includes a server address, protocol and required parameters, but it does not have to correspond exactly to one independent physical server. Multiple nodes may run on the same infrastructure, or different entry points may connect to different exits. Node count therefore cannot be equated directly with the number of physical servers, and it does not by itself indicate the quality of the experience.
A server is a device or instance that provides computing and network capacity. A route describes the path data takes from the client to the entry point and then to the exit. The same exit region may use a direct connection, a relay or a dedicated IEPL route. Although they show the same region, their cross-network stability, congestion patterns and failover behavior may differ.
| Term | Primary meaning | What users can usually see | What it does not tell you directly |
|---|---|---|---|
| Node | A selectable connection configuration in the client | Region, name, protocol or route labels | The actual number of physical servers |
| Server | Infrastructure that handles connections and forwarding | The underlying structure is usually not shown in full | Whether the cross-border path is stable |
| Route | The network path from the local network to the entry and exit points | Descriptions such as direct, relay or dedicated route | A fixed speed at all times |
| Exit | The network location from which the target website sees the request leave | The exit region and detected public IP | The complete path from the client to the entry point |
Direct, relay and dedicated IEPL routes
A direct route connects the client straight to the remote server entry point. The path is simple and involves fewer forwarding steps, but performance depends more heavily on the local carrier and international network conditions. Cross-network routing changes or peak-hour congestion can still cause fluctuations on the same node.
A relay route first connects to a nearer entry point or one with better interconnection, then uses the relay network to reach the exit. Its value lies in adjusting the first part of the journey and reducing the instability that can occur when the local network connects directly to a remote destination. A relay is not automatically faster than every direct route; performance still depends on the entry location, capacity and network conditions at the time.
IEPL generally refers to an international Ethernet private-line connection used in enterprise settings. Compared with an ordinary public-internet direct connection, it emphasizes a more controlled cross-border transport path. However, the local network between the client and the access point still affects performance, and the provider’s implementation and traffic scheduling matter as well. Treat a “dedicated line” label as a description of the route architecture, not a promise of perfectly consistent performance in every environment.
How to read common protocol names
A protocol defines how the client and server package, authenticate and transmit data. Beginners do not need to memorize every field, but should understand that a protocol affects compatibility, connection methods, traffic characteristics and network adaptability. The same protocol name does not mean two services have the same route quality: server deployment, routing and configuration remain separate variables.
| Protocol | Key idea | Common considerations |
|---|---|---|
| Shadowsocks | A lightweight encrypted proxy protocol with broad client support and a relatively straightforward configuration structure | The encryption method must match the server, and older clients may not support newer configurations |
| VMess | Common in the V2Ray ecosystem, with authentication, transport and security parameters in the configuration | Transport-layer settings must match; copying only the server address is not enough |
| Trojan | Usually establishes connections with TLS and depends on correct certificate and domain configuration | System time, certificate verification and server-name settings can affect the handshake |
| VLESS | A relatively streamlined authentication and transport framework, often combined with other transport and security mechanisms | It is not a standalone parameter; the client must fully support the corresponding combination |
| Hysteria2 | A QUIC-based transport approach focused on maintaining effective transmission under complex network conditions | Restrictions on UDP can directly affect connection performance |
| TUIC | Also based on QUIC and UDP, with an emphasis on concurrent transmission and connection management | The client and server versions, authentication and transport parameters must be compatible |
Shadowsocks is often shortened to SS. It handles encryption and forwarding for proxy traffic. VMess and VLESS commonly appear in the V2Ray or compatible ecosystem, but their authentication and data structures differ, so they cannot be swapped simply because their names look similar. Trojan configurations often involve TLS; an incorrect certificate domain, server name or system time can cause the connection to fail.
Hysteria2 and TUIC use UDP-based QUIC technology. They may adapt better to some high-latency or lossy networks, but strict UDP restrictions on a company network, campus network, router or local operating environment can prevent a connection from being established. In that situation, switching to a compatible TCP-based configuration is usually more useful than repeatedly retrying the connection.
A practical order for choosing a protocol
- Start with the protocol recommended by default in the subscription, as it usually matches the current server configuration.
- When a connection fails, determine whether the problem affects one node or all nodes using the same protocol.
- If UDP-based protocols generally fail, try a TCP-based compatible route from the subscription.
- If the TLS handshake reports an error, check the device time, certificate verification, domain parameters and client version.
- Do not change transport, security or authentication fields at random if you do not understand them; a mismatch at either end can cause failure.
How to choose between split tunneling, global and rule modes
Split tunneling uses domains, IP addresses, applications or other conditions to decide where requests should go. Clients usually offer global, rule and direct modes, although the names may vary slightly between products. The key is not memorizing button locations, but knowing which traffic is handed to the proxy.
Global mode usually sends all requests the client can take over through the current node. It is useful for short troubleshooting tests: if a website fails in rule mode but works in global mode, the problem is more likely to be rule matching or DNS resolution than the node itself. Global mode does not mean every type of traffic on the device is necessarily covered; that depends on the client’s operating method, system permissions and the application’s own network implementation.
Rule mode sends matching requests through the node and keeps the rest on a local direct connection. It is generally better for everyday use because local services do not need to take a detour, while international websites and specific applications are handled according to the rules. Accuracy depends on rule-set updates, domain classification and DNS resolution results.
Direct mode is generally used to temporarily disable proxy forwarding, but some clients may still leave the system proxy or virtual network interface enabled. During troubleshooting, do not look only at the mode name; also check the status bar, system proxy switch and virtual network interface state.
| Mode | Traffic handling | Best for | Things to watch |
|---|---|---|---|
| Global mode | All requests the client can take over are sent through the current node | Short tests and finding missing rules | Local services may also take a detour; it is not a substitute for maintaining rules long term |
| Rule mode | Selects proxy or direct access according to domain, IP or application conditions | Everyday browsing, development tools and streaming by category | Old rules may miss new domains or content-delivery domains |
| Direct mode | Requests continue to use the local network | Pausing the connection and comparing local-network behavior | The client’s takeover state may not be fully disabled by the mode alone |
System proxy and virtual network interface modes
System proxy mode mainly forwards traffic for applications that follow the operating system’s proxy settings. Browsers can usually use it, but some command-line programs, games or applications with their own network stack may ignore the system proxy. These programs often need proxy environment variables set separately or require the client’s virtual network interface mode.
Virtual network interface mode is often called TUN mode. It uses a system network interface to take over a broader range of IP traffic, making it more suitable for applications that do not read system proxy settings. The trade-off is that it needs additional system permissions and is more likely to conflict with firewalls, other networking tools, enterprise security software or existing virtual network interfaces.
DNS leaks and resolution paths
DNS converts domain names into network addresses. After connecting to a node, web requests may already travel through the selected route while domain lookups are still handled by DNS provided by the local network. This mismatch between the actual and expected resolution path is commonly called a DNS leak. It can expose lookup records for visited domains or cause access problems when it returns an address unsuitable for the current exit.
DNS is especially important when split-tunneling rules rely on domain matching. If an application resolves a domain to an IP address first and the client sees only the final IP, the rule may not be able to match the original domain. Modern clients often offer DNS takeover, encrypted DNS, remote resolution or rule-based resolver selection, but the configuration names are not standardized.
When checking DNS issues, identify who handles the resolution request, whether the returned address fits the current network, whether the browser has its own secure DNS enabled, and whether other networking tools are running on the system. Browser DNS, operating-system DNS and client DNS can coexist, so the final path may differ from what a single interface switch suggests.
- ✅ Make sure the client’s DNS settings match the current split-tunneling mode instead of simply turning on the connection switch.
- ✅ Check whether the browser uses a separate DNS configuration, which may bypass the client’s system-level settings.
- ✅ If rule matching behaves unexpectedly, update the rules and subscription, clear old DNS caches, and test again.
- ✅ Compare global mode with rule mode; if only rule mode behaves abnormally, check domain matching and the resolution path first.
- ❌ Avoid running multiple clients that modify the system proxy, routes or DNS at the same time; conflicts make troubleshooting results unreliable.
Client differences across platforms
Windows clients commonly offer both system proxy and virtual network interface capabilities. When using the system proxy, check whether the software restores the system settings automatically after exiting. With a virtual network interface, watch for administrator permissions, firewall rules and other virtual networking software. If access fails after sleep or a network change, an old route or proxy state may not have been restored correctly.
macOS applies stricter controls to network extensions and system permissions. The first time you enable a virtual network interface or network extension, the system may ask you to approve the permission. Clients use different network-extension implementations, and enabling several similar tools at once can cause route overrides. For troubleshooting, temporarily leave only the current client running.
Android clients generally use the system VPN interface to take over traffic. The system status icon indicates that the interface is enabled, but this only means the client has obtained a forwarding entry point; it does not guarantee that the current node is connected. Battery-saving policies, background restrictions and network changes can interrupt long connections, so allow the client to keep the necessary background access.
iOS and iPadOS likewise depend on the network-extension capabilities provided by the system. After an app enters the background, the system and client maintain the connection together. If the configuration imports correctly but cannot connect, first check that it is complete, that system network permissions allow it, and that no other network configuration is enabled at the same time.
On Linux, differences mostly come from the desktop environment, distribution-specific network management and command-line tools. A browser may read the desktop proxy settings, while terminal programs usually need their own proxy environment variables. Containers, remote sessions and subsystems may also have independent network namespaces and should not be assumed to inherit the host system’s proxy.
A beginner’s troubleshooting order
- Confirm that the local network can access commonly used services normally when the client is not enabled.
- Update the subscription and test another node in the same region to rule out a single-node issue.
- Switch protocol types and observe whether one protocol is incompatible or every connection fails.
- Use global mode for a short comparison; if global mode works but rule mode does not, check the rules and DNS.
- Confirm whether the target application reads the system proxy; if it does not, then consider a virtual network interface or application-level settings.
- Close other tools that modify the proxy, routes or DNS to prevent multiple configurations from overriding one another.
- Restart the client and check whether the system proxy has been restored, then run one clean connection test.
Putting the terms together in one complete flow
A normal connection can be understood like this: the client reads configuration from the subscription link and displays multiple nodes; the user selects a node, and the client establishes a connection to the server using that node’s specified protocol; the route carries data to the corresponding exit; split-tunneling rules determine which requests enter that route; and DNS settings determine how domains are resolved and whether the rules can identify requests.
If a subscription update fails, the client cannot obtain new configuration. If a node connection fails, the cause may be the node state, protocol compatibility or local network restrictions. If only a specific website behaves abnormally, continue by checking split tunneling, DNS, the exit region and the website itself. If the browser works but another application does not, focus on the scope of system-proxy takeover and platform differences.
When choosing a route, do not look only at the node name. Web browsing and development tools place more emphasis on connection stability, correct DNS and persistent connections. Video viewing continuously consumes bandwidth and is also affected by the platform’s content-delivery strategy. Remote meetings are more sensitive to jitter, packet loss and network changes. Different uses call for different routes.