VPN terminology can look overwhelming, but beginners only need to understand a few key relationships first: a subscription delivers configuration to the client, a node is a selectable connection entry, the route describes how traffic reaches its exit, and the protocol defines communication between client and server. Split tunneling, global mode, and rule mode determine which traffic uses the connection. Separate these layers and setup, route selection, and troubleshooting become much clearer.
A common mistake is treating a node, route, protocol, and client as the same thing. For example, a node may use VLESS and be labeled by the provider as a relay route; the same subscription can also be imported into compatible clients on different platforms. These concepts are related, but each solves a different problem.
What are subscriptions, subscription links, and clients?
A subscription is a dynamic configuration list, not a billing period
In proxy-client terminology, a subscription usually means a configuration list maintained by the server. It may include node names, server addresses, ports, protocol parameters, authentication details, and transport settings. The client retrieves this information through a subscription link and turns it into a selectable node list.
So “import subscription” does not mean installing a network driver, and it does not mean the connection is already working. Importing only completes the configuration read. You still need to choose a node, enable the connection, and confirm that the client is handling system traffic. If the subscription imports successfully but no node connects, check whether the subscription has expired, whether the client supports the protocol, whether the system clock is accurate, and whether the current network restricts the relevant transport.
Subscription links often contain credentials that identify an account or plan, so protect them like account passwords. Do not include a complete link in public screenshots, forum posts, synced browser notes, or shared documents. When using another device, copy it again from a trusted account panel instead of forwarding it through a public channel.
Updating a subscription vs. importing it again
“Update subscription” makes the client request the same subscription address again to retrieve the nodes and parameters currently provided by the server. When route names change, old nodes are removed, or protocol parameters are adjusted, updating is usually better than editing the local configuration by hand.
“Import again” adds the subscription as a new configuration source in the client. Different clients handle duplicate subscription names differently: some overwrite the original, some keep both, and some preserve user-created rules. Check for local edits first so an update does not replace them unexpectedly.
- ✅ Copy the complete subscription link from the account panel; do not manually remove or alter any characters.
- ✅ In the client, use “Import from URL” or a similarly named option.
- ✅ After importing, update the subscription first, then check that the node list appears.
- ✅ After connecting to a node, verify web access, DNS resolution, and commonly used apps separately.
- ❌ Do not publish subscription QR codes, complete links, or configuration files containing authentication fields.
- ❌ Do not assume that “import successful” means all traffic is already using the connection.
The relationship between nodes, servers, and exit IPs
A node is a logical connection entry displayed by the client. At minimum, it needs a reachable target and protocol parameters, but its name does not necessarily match the name of a physical server. A provider may name nodes by region, route type, or purpose, and multiple node entries may share backend resources.
A server is computing infrastructure that handles access, forwarding, or exit functions. One connection may pass through only an access server and an exit, or it may include additional relay steps. Clients usually do not show the full internal topology, so a node name alone cannot reveal how many network devices the data actually traverses.
The exit IP is the source address ultimately seen by the destination website. It usually belongs to the end of the route rather than your local network, and it may not be on the same network as the entry server. To check whether the region is as expected, look up the exit IP and compare it with the target service’s actual behavior. Different databases may assign different regions or carrier labels to the same IP, so any single lookup is only a reference.
Latency, bandwidth, and stability are different metrics
Latency is the time required for data to make a round trip, and is usually affected by physical distance, route detours, congestion, and wireless conditions. Bandwidth describes how much data can be transferred per unit of time. Stability is more concerned with jitter, packet loss, disconnections, and fluctuations during extended use.
A low-latency node does not necessarily offer faster downloads, and a high-bandwidth route may not suit meetings or remote work that require consistent interaction. Latency tests in client lists often check only an access point or a specific probe address, so they cannot fully represent performance when visiting a target website. Choose based on the task: web browsing and messaging prioritize responsiveness and stability, large file transfers depend more on sustained throughput, and real-time audio or video is also affected by jitter and packet loss.
How to distinguish IEPL dedicated lines, relays, and direct connections
A route type describes the broad path client traffic takes from the local network to the remote exit. It is not a protocol name or an encryption algorithm. Shadowsocks, VMess, and Trojan can run over different routes; conversely, the same route type can carry different protocols.
| Route type | Typical path | Common characteristics | What to check |
|---|---|---|---|
| Direct | The local network connects directly to the remote access point | A simpler structure whose performance depends heavily on the public route between the local carrier and the remote endpoint | Check evening congestion, cross-network detours, and sustained connection performance |
| Relay | Connect first to a nearby or better-routed entry point, then forward traffic to the exit | Can avoid some unfavorable public routes, but adds an intermediate forwarding step | Check entry-point stability, exit region, and peak-hour fluctuations |
| IEPL dedicated line | After access, connects the two sides of the international route through provider-labeled dedicated-line resources | Usually emphasizes a controlled path and stable transmission, but the actual implementation depends on the provider’s network | Do not rely on the label alone; verify with a real connection and the target application |
The advantage of a direct connection is a clear route with one fewer relay step; the drawback is greater exposure to changes in public international routing. Your location, access carrier, and remote server location all affect the result, so the same direct node may perform very differently on different networks.
A relay route sends traffic to an access point first, then forwards it to the exit through the provider’s forwarding network. Its value is in reorganizing the path, not automatically making every scenario faster. Even if the link between you and the entry point is stable, congestion between the relay and exit can still reduce performance.
IEPL is an industry term related to international Ethernet private lines. In a consumer node list, “IEPL dedicated line” usually indicates that the provider uses relevant enterprise network resources or labels the route category this way. The name alone cannot verify the full topology, capacity, or scheduling policy. Treat it as a route description, not a guarantee of identical performance for every target website.
What makes common protocols different?
A protocol defines how the client and server establish a session, authenticate, encapsulate data, and transmit traffic. Whether a protocol can be used depends on the server offering the relevant configuration and the client implementing the required features. A link for one protocol cannot simply be imported into a completely incompatible client.
Shadowsocks
Shadowsocks is an encrypted proxy protocol whose configuration usually includes a server, port, encryption method, and password. It is mature and supported by many clients, making it suitable for general proxy use. Supported cipher suites and extensions vary by implementation; when an import fails, first check the client version and configuration fields rather than changing the password or port at random.
VMess and VLESS
VMess is a common proxy protocol in the V2Ray ecosystem, with configuration fields covering user identifiers, transport methods, and security parameters. VLESS uses a lighter protocol design and is often paired with TLS, REALITY, or other secure transport settings. The names are similar, but their fields are not interchangeable; a client advertised as “V2Ray core compatible” does not necessarily support every transport combination.
Trojan
Trojan usually runs over a TLS connection. Key settings include the server domain, port, password, certificate validation, and transport parameters. A certificate-name mismatch, an incorrect system clock, or missing domain settings can cause the handshake to fail. Disabling certificate verification may sometimes hide the error temporarily, but it weakens server identity verification and should not be a standard fix.
Hysteria2 and TUIC
Hysteria2 and TUIC both use QUIC-based transport and generally focus on efficiency under high latency, jitter, or packet loss. They rely on UDP; if the current network strictly limits UDP, you may see handshake failures, no traffic after connection, or frequent fallback. First test on a network that permits UDP, then determine whether the issue is the node or the local environment.
Neither protocol is guaranteed to be faster on every network. If the network is stable and the destination is nearby, a traditional TCP and TLS combination may already be sufficient. Choose based on connection success, sustained transfer, and application compatibility rather than simply comparing how new the protocol names sound.
| Protocol | Transport focus | Common troubleshooting areas |
|---|---|---|
| Shadowsocks | Encrypted proxy with broad client compatibility | Encryption method, password, port, client implementation |
| VMess | Multiple transport combinations and ecosystem compatibility | User identifier, transport layer, path, and security parameters |
| VLESS | Lightweight protocol paired with external secure transport | TLS or REALITY parameters, domain, transport combination |
| Trojan | TLS-based proxy connection | Certificate, domain, system clock, and password |
| Hysteria2 | QUIC-based transport for fluctuating networks | UDP reachability, authentication details, and bandwidth parameters |
| TUIC | QUIC-based proxy transport | UDP restrictions, certificate validation, and congestion-control compatibility |
Global mode, rule mode, direct connections, and system proxy
After connecting to a node, the client still has to decide which traffic is handed to the proxy core. This is the operating mode. Names vary slightly between clients, but they generally fall into global mode, rule mode, and direct mode.
Global mode
Global mode sends as much client-managed traffic as possible through the current node. It is useful for quickly checking whether a node works and for apps that involve multiple domains or are difficult to cover with rules. The drawback is that local services, mainland websites, or apps that do not need international access may also take a longer route, increasing latency and consuming plan traffic.
Rule mode
Rule mode decides whether traffic is proxied, sent direct, or rejected based on domains, IPs, app processes, regional databases, or custom conditions. It is better suited to long-term use, but accuracy depends on rule quality. Modern apps often call separate domains for login, content delivery, updates, and telemetry; adding only the main domain may let a page load while login, images, or downloads fail.
Rules are usually matched in the order defined by the client. If a broad rule comes first, a more specific rule later may never take effect. During troubleshooting, temporarily switch to global mode: if global mode works but rule mode fails, the problem is probably with the rules, DNS, or traffic not being captured by the client—not with the node itself.
Direct mode
Direct mode sends traffic without using a remote node. It is commonly used to pause proxying without quitting the client, test the local network, or check whether a website is affected by the rules. Note that some clients still retain local DNS, traffic statistics, or a virtual network adapter in “direct” mode, so it is not necessarily the same as fully closing the software.
System proxy and TUN mode
A system proxy provides HTTP, HTTPS, SOCKS, or similar proxy addresses to the operating system or apps. Browsers and productivity apps that follow system proxy settings can usually be handled, but programs that create their own connections or ignore system proxy settings may bypass it.
TUN mode uses a virtual network interface to capture a broader range of IP traffic, making it useful for apps, game launchers, or command-line tools that do not support system proxies. Its coverage is broader, but it is also more affected by routing tables, firewalls, other network software, and permissions. If enabling TUN makes local devices unreachable, creates a network loop, or causes traffic to stop after waking from sleep, check LAN bypass settings, virtual adapter status, and route conflicts.
Application request
├─ Direct rule matched → Local network
├─ Proxy rule matched → Client → Node → Target service
└─ No rule matched → Handled by the client’s final rule- ✅ During node testing, start with global mode to confirm that the basic connection works.
- ✅ For everyday use, switch to rule mode and separate local services from international access.
- ✅ If an app does not work, check whether it follows the system proxy; then consider TUN if needed.
- ✅ After changing rules, review the client connection log to confirm which rule handled the request.
- ❌ Do not pile up duplicate rules without understanding their priority.
- ❌ Do not run multiple clients that modify the system proxy or virtual network adapter at the same time.
Why DNS leaks, resolution paths, and routing rules affect one another
DNS converts domain names into IP addresses. When you visit a website, the client must know the destination address before it can decide whether to connect directly or use a proxy. If DNS requests remain with the local network while web traffic goes through a remote node, the resolution path and access path may not match.
A DNS leak generally means that DNS requests which should be handled by the proxy side or a specified resolver are still visible to a resolver on the local network. This may expose the domains being queried or return an address that does not match the exit region, causing unusual content delivery, failed access, or incorrect routing decisions.
Rule mode depends especially on correct resolution. Domain-based rules can match before resolution, but IP- or region-database rules need the resolved result. If the browser uses its own secure DNS, queries may bypass the client settings; if TUN mode does not properly capture DNS, web traffic may use the proxy while resolution still goes through the local network.
When troubleshooting DNS, do not look only at whether a webpage opens. Also check the domain, resolver, matched rule, and exit in the client log. If changing nodes makes no difference but switching DNS modes restores access, the route itself is usually not the problem. If DNS is handled as expected but the target still times out, check the node, protocol, and network reachability next.
How clients differ across platforms
The same subscription generally shows similar nodes on different platforms, but traffic capture and background restrictions may differ. If a setup works on one device but not another, do not assume immediately that the subscription has failed. First compare the client core, system permissions, proxy mode, and network environment.
Windows
Windows clients commonly offer both system proxy and TUN modes. System proxy suits browsers and apps that follow system settings; TUN is better when more application traffic needs to be captured. If websites remain inaccessible after quitting the client, check whether the system proxy was restored correctly. If TUN will not start, inspect the virtual adapter, permissions, firewall, and conflicts with other network tools.
Android
Android clients generally capture traffic through the system VPNService, and the first connection displays a system authorization prompt. Some systems restrict background activity aggressively, causing the connection to be reclaimed after the screen locks. Adjust battery-management settings to allow the client to keep running, and make sure no other app is using the system VPN interface at the same time.
iOS and iPadOS
Clients on these platforms rely on system network extensions to establish connections. A connection indicator in the system status bar only means that the extension has started; it does not prove that the target node is reachable. Verify through an actual webpage, client logs, and the exit. If some protocols from the subscription do not appear, check the client’s supported range instead of repeatedly importing the same link.
macOS
macOS clients may use the system proxy, a network extension, or a virtual interface. If the browser works but command-line tools do not, a common cause is that the latter do not read the system proxy environment. After enabling TUN, if local development services or LAN access behave unexpectedly, check route exclusions and local-address rules.
A complete check from import to verification
Once you understand the terminology, use the sequence below for a clean setup. The order matters: confirm the configuration source first, check protocol compatibility next, establish the connection, and verify routing and DNS last. If you skip the earlier steps, later errors often become mixed together.
- Get the subscription. Sign in to the service panel and copy the link from the subscription or client page. Make sure it contains no extra spaces, and do not expand or convert the subscription with public tools.
- Choose a compatible client. Check which protocols the subscription contains and confirm that the client supports those protocols and transport methods. A client that supports only Shadowsocks cannot directly read a complete VLESS, Trojan, or Hysteria2 configuration.
- Import and update. Add the subscription through the URL import option, run an update, and check that the node names are complete. If the update reports an authentication error, return to the account panel and obtain the link again; do not guess at or edit its fields.
- Start with a simple mode. Choose a node at a reasonable distance from your current network and temporarily use global mode. If the client provides connection logs, keep them visible so you can distinguish DNS, handshake, and timeout errors.
- Check the actual exit. Open a commonly used website and check whether the exit region matches the node description. Do not rely only on the client’s built-in latency button: a successful probe does not prove that the target application’s complete request will succeed.
- Switch to rule mode. After confirming the basic connection, enable rule-based routing. Test services that need proxying and those that need direct access separately, and review which rules handled the requests.
- Verify DNS. Confirm that resolution requests are handled by the expected component. If the browser behaves differently from other apps, check the browser’s independent DNS, system proxy, and TUN capture scope.
- Save a reproducible configuration. Record the client version, mode, and key switches, but do not record subscription credentials. Change one setting at a time when troubleshooting so you can identify which change took effect.
Once you know these terms, the client interface is no longer a collection of isolated switches. The subscription handles configuration delivery, the node provides the connection entry, the route determines the transport path, the protocol handles communication, the operating mode selects traffic, and DNS affects name resolution and rule matching. Follow this chain layer by layer when troubleshooting; it is usually more effective than repeatedly changing clients or importing the configuration again.