You do not need to memorize an entire networking theory course to understand VPN terminology. A subscription is the configuration entry point, a node is a selectable exit, a protocol defines how the client and server exchange data, and routing rules decide which requests use the node. Once these layers are clear, issues such as import failures, slow routes and inaccessible websites can be troubleshot step by step instead of by randomly switching settings.
In everyday use, “VPN” may refer broadly to a complete network acceleration service or to the virtual private network capability built into an operating system. Shadowsocks, VMess, Trojan and VLESS are closer to proxy protocols or transport solutions within the proxy ecosystem. A compatible client can manage them, but their appearance in the same client does not make them the same technology.
What subscription links and configuration files actually contain
A subscription link is not an ordinary saved webpage or a single fixed route. It usually points to a configuration set generated dynamically by the server, which may include node addresses, ports, protocol types, credentials, transport settings, node names and group information. After requesting the link, the client parses it and displays multiple available configurations in the node list.
That is why “import subscription” and “connect to a node” are two separate actions. The first synchronizes remote configuration with the client; the second selects one item and establishes a connection. After an update, old nodes may be replaced, renamed or given new parameters. If the client keeps using its local cache, it may show configurations that are no longer valid.
Why subscription links should be stored carefully
Subscriptions commonly include access credentials used to identify an account or plan. Anyone who obtains the link may be able to read its node configuration, so it should not be posted in screenshots, forums, ticket titles or public code repositories. When troubleshooting, describe the client, the stage where the error occurs and the node type, but hide the full link and its credential fields.
“Subscription conversion” is another common term. It means converting one configuration format into a format readable by another client; the process may also merge nodes, rename policy groups or generate routing rules. Because conversion requires reading the original subscription, use an entry explicitly provided by the service provider whenever possible, rather than giving credentials to an unknown website.
- ✅ Before importing, confirm that the link comes from the control panel you currently use, not a forwarded copy from a chat.
- ✅ After importing, run an update first, then check whether the expected protocols and regions appear in the node list.
- ✅ When changing clients, copy the subscription again from the control panel to reduce interference from old caches and formats.
- ❌ Do not include the full subscription in public speed-test screenshots, shared documents or public repositories.
- ❌ Do not judge whether a subscription is valid by whether a browser can display its contents directly.
The difference between nodes, servers and exit addresses
A node is a set of connection settings that can be selected in a client. It usually points to a server or access endpoint, but a node name does not necessarily correspond to one physical server. Multiple nodes may share an access system or be routed to different backends based on load, carrier or routing policy. Names in the list are therefore best used to identify a configuration’s purpose, not as an inventory of data-center assets.
After connecting to a node, requests usually reach the node’s entry point first, and the service then accesses the target website. The target website generally sees the service’s public exit address rather than the public address of the local network. The “exit region” is the region the target service infers from that address, which may affect content availability, search results and service access.
Latency, bandwidth and real-world speed
Latency describes the time needed for a request to make a round trip, while bandwidth describes how much data can be carried per unit of time. They are different metrics. A low-latency route is useful for frequent interaction but does not necessarily offer faster downloads. A high-bandwidth route may also underperform during congestion, packet loss or local network instability. The latency shown by a client is usually a probe of the entry point, not the complete path to a specific website.
Load describes the connection or traffic pressure currently handled by a node. Different clients and services calculate it differently: some use server reports, while others infer it from local probes. Treat it as supporting information, not as a reason to judge an entire route from one status label.
| Term | What it describes | Common misconception | What to check |
|---|---|---|---|
| Node | A set of connection parameters in the client | Assuming the node name identifies one unique physical server | Protocol, entry point, authentication and transport parameters |
| Entry point | The server address the client connects to first | Assuming the entry region must match the exit region | Domain resolution, port reachability and the local network |
| Exit | The public address used by the server to access the target website | Assuming every website will assign the same region | Exit address, DNS results and the target service’s policies |
| Latency | The round-trip time of a probe request | Equating low latency directly with high download speed | Local network, distance to the entry point, congestion and packet loss |
| Bandwidth | The data-carrying capacity of the link | Assuming the advertised bandwidth can always be fully used by one connection | Local access, shared route capacity and target-site throttling |
Protocols and transport: how do Shadowsocks, VMess, Trojan and VLESS differ?
A protocol defines how both sides package, authenticate and transmit data. The client must implement the same protocol and have matching authentication and transport parameters to establish a connection with the server. Even identical protocol names do not mean configurations can be mixed freely, because the underlying transport, encryption layer, server name, path and certificate-validation method may still differ.
Shadowsocks
Shadowsocks is a lightweight encrypted proxy protocol. Its configuration usually centers on the server address, port, encryption method and password. Its structure is relatively straightforward and it is widely supported by clients. It mainly provides a proxy channel; it does not automatically send all system traffic through the proxy. Whether application traffic is captured still depends on the system proxy, virtual network interface mode and routing rules.
VMess and VLESS
VMess is common in the V2Ray ecosystem. It includes authentication and protocol-level processing, and can work with different underlying transports. VLESS has a more streamlined design and typically delegates encryption and secure transport to an outer layer such as TLS. Their names are similar, but their authentication fields and data formats differ, so they cannot be swapped directly. If an imported configuration reports that the protocol is unsupported, the client core may be outdated or the current build may lack the required capability.
Trojan
Trojan typically runs over TLS. Key settings include the server address, authentication password, server name and certificate validation. It relies on correct TLS parameters to establish a secure connection. A significantly incorrect system clock, an incorrect server name or an unverifiable certificate chain can all cause the handshake to fail. Disabling certificate verification may bypass an error temporarily, but it weakens connection validation and should not be a routine fix.
Hysteria2 and TUIC
Hysteria2 and TUIC both use QUIC capabilities built on UDP, with an emphasis on packet loss, congestion control and multiplexing. These approaches may perform flexibly on networks with noticeable quality fluctuations, provided that the local network, routing equipment and server can all pass UDP correctly. If the current network restricts UDP, the client may time out while other TCP- or TLS-based configurations still connect.
| Protocol | Common transport characteristics | Configuration focus | Typical troubleshooting direction |
|---|---|---|---|
| Shadowsocks | Lightweight encrypted proxy | Encryption method, password, address and port | Whether parameters match and whether the client captures traffic |
| VMess | Authentication included; can use multiple underlying transports | User identifier, transport type and additional parameters | Core compatibility, transport parameters and system time |
| VLESS | Streamlined authentication, often paired with outer secure transport | User identifier, TLS and transport configuration | Server name, certificate and transport compatibility |
| Trojan | TLS-based proxy connection | Password, server name and certificate validation | TLS handshake, time and certificate chain |
| Hysteria2 | QUIC- and UDP-based | Authentication, TLS and congestion parameters | UDP reachability, network packet loss and client support |
| TUIC | QUIC- and UDP-based, with multiplexing support | Authentication, certificates and congestion control | UDP restrictions, core version and parameter matching |
Direct connections, relays and IEPL: how to read route names
A direct connection means the client accesses an overseas or remote server entry point without passing through an additional domestic access relay deployed by the provider. The structure is simpler and has fewer stages, but the actual path is determined by the local carrier and public routing. Detours, congestion or packet loss may occur during peak periods.
A relay connection means the client first connects to a nearby access server, which then forwards traffic to the remote exit. Its value lies in replacing a volatile section of the public route with a forwarding path the provider can manage. A relay is not necessarily faster than a direct connection: performance can still decline if the access point is poorly located, the forwarding link is congested or the exit itself is constrained.
IEPL is a common abbreviation for International Ethernet Private Line, typically describing a cross-border enterprise network connection with dedicated transport characteristics. In subscription node names, “IEPL” may indicate that access and cross-border transport use dedicated resources, but the name alone cannot confirm the full topology, resource tier or whether the entire path is exclusive. Evaluate such routes by peak-hour stability, performance across different carriers and the provider’s clear explanation of the route structure.
A dedicated line describes the transport path and capacity arrangement; it is not the same as an application-layer encryption protocol. Even when a route uses dedicated transport, the client and server still require correct protocol, authentication and encryption settings.
Global mode, rule-based mode and direct mode
A successful route connection only means that the client can communicate with the server. The routing mode determines which application requests enter that channel. Common modes include global, rule-based and direct. Button labels vary slightly between clients, but the underlying logic is broadly the same.
Global mode attempts to send all traffic within the client’s capture scope through the selected node. It is useful for quickly checking whether a request works through a node, but local websites, LAN devices and region-sensitive services may also be affected. “Global” remains limited by the client’s capture capabilities: when only a browser proxy is configured, applications that do not read the system proxy may not use the node.
Rule-based mode decides whether a request uses the proxy, connects directly or is rejected based on domains, address ranges, applications, ports or rule sets. It is better suited to long-term use but depends on accurate, up-to-date rules. If a domain rule does not match, a service changes addresses or DNS results change, some webpage resources may connect directly while others use the proxy.
Direct mode generally means that requests do not pass through a remote node. It can temporarily pause proxying or serve as an exit action in a rule system. Direct mode does not mean the client is closed: the client may still run and handle DNS, rules or LAN requests, while the final traffic exits through the local network.
System proxy and virtual network interface mode
A system proxy writes the proxy address into the operating system’s network settings. Applications that follow those settings send proxy requests themselves. Browsers generally support this well, but some applications, command-line programs and software with its own network stack may ignore the system proxy.
Virtual network interface mode is also commonly called TUN mode. It uses a virtual network interface to capture a broader range of IP traffic, then lets the client handle protocol conversion and routing decisions. It is better suited to applications that do not support system proxies, but it requires the relevant system permissions and is more susceptible to conflicts involving the local firewall, other networking software and the routing table.
- Connect to a node with a normal status in rule-based mode first, then confirm that commonly used webpages open.
- If a specific application has no traffic, check whether it follows the system proxy; if necessary, test virtual network interface mode next.
- If only one domain fails, inspect the rule match result and final exit in the connection log.
- If local services are affected, add direct-connection rules for LAN addresses and required domains.
- After changing rules, start a new request so that an old connection does not continue using the previous route.
DNS leaks, incorrect resolution and routing conflicts
DNS converts domain names into network addresses. A DNS leak usually means that queries expected to use a controlled channel or specified resolver are still sent to the local network’s default resolver. This makes DNS requests inconsistent with the actual access path and may expose information about queried domains. It does not mean the proxy protocol itself has necessarily failed; rather, domain resolution did not follow the intended path.
DNS poisoning or incorrect resolution appears as a domain returning an incorrect, unreachable or unsuitable address for the current route. The node may connect normally while the target website remains inaccessible. Changing nodes can sometimes appear to fix the issue, when the actual cause is that the new connection triggered a different DNS-resolution process.
Routing conflicts often occur when domain rules and address rules reach different conclusions. For example, a domain may be routed through the proxy while its DNS query uses the local resolver, producing an address that address rules then send directly. Alternatively, the main page may use the proxy while images, login APIs and media resources match other rules. The result may be a page that opens but cannot log in, incomplete regional content or a player that waits indefinitely.
Remote DNS, local DNS and Fake IP
Local DNS usually uses a resolver supplied by the current network or specified by the system. With remote DNS, the client sends queries to a remote or specified resolver, often keeping resolution aligned with the proxy exit. They can be used by domain: local domains can use local resolution, while international services use remote resolution.
Fake IP is a mechanism some clients use to improve domain-based routing. The client first returns a temporary address from a reserved range to the application and stores its mapping to the original domain internally. When the application connects to that temporary address, the client restores the domain and applies the rules. It does not mean the target website actually uses that address. If certain LAN applications, games or security software are incompatible, add the relevant domains to an exclusion list instead of deleting all routing rules.
Client import and platform differences
A client is a connection tool running on a device. It parses subscriptions, implements protocols, selects nodes, establishes a system proxy or virtual network interface, and applies DNS and routing rules. The provider, protocol and client are different layers: the provider supplies the account and routes, the protocol defines communication, and the client is the software that executes the configuration.
Windows and macOS clients commonly offer both system proxy and virtual network interface capabilities, but their permission models differ. On Windows, pay attention to virtual network interface drivers, the firewall and other network-filtering software. On macOS, confirm permissions for network extensions or VPN configurations and resolve conflicts between the system proxy and other network tools. Restore the system proxy before quitting the client to prevent the system from continuing to point to a local port that is no longer listening.
Android clients generally capture traffic through the system VPN interface, which can usually be occupied by only one such networking tool at a time. Per-app routing is common, but background restrictions imposed by different vendors can interrupt connections. iOS and iPadOS rely on the network-extension capabilities provided by the system; the protocols and rules a client supports depend on its integrated core and system permissions.
Linux environments commonly use command-line cores, desktop front ends or service processes. If a browser works but terminal commands do not, only the desktop proxy may be configured while command-line programs are not reading the relevant environment variables. Conversely, when a virtual network interface has captured traffic, focus on the routing table, DNS and firewall rules.
Import subscription
↓
Client parses configuration
↓
Select node and protocol
↓
Establish proxy or virtual network interface
↓
DNS resolution and rule matching
↓
Proxy / Direct / Reject
↓
Access target serviceHow to troubleshoot import failures
If the client says it cannot recognize the subscription, first confirm that the copied content is complete, the link is still valid and the client supports the format output by the server. If the subscription updates but the list is empty, check filters, node groups and client logs. If nodes exist but all connections fail, check the system clock, local network restrictions, protocol core version and authentication parameters.
- ✅ Subscription cannot be downloaded: check the link’s integrity, network connectivity and control-panel status.
- ✅ Subscription downloads but cannot be parsed: check client format support and core version.
- ✅ Only some nodes fail: compare the protocols, entry types and transport parameters they share.
- ✅ Node connects successfully but the application has no traffic: check the system proxy, virtual network interface and per-app routing.
- ✅ Part of a webpage is broken: check DNS, rule matches and the exits used by different resource domains.
- ❌ Do not repeatedly reinstall the client before checking the logs, because an incorrect configuration will usually be imported again unchanged.
Concept map: which layer should you check first?
Putting every term back into the connection flow creates a reliable troubleshooting method. The control panel generates the subscription, the subscription contains node settings, the client parses them and calls the protocol core, the protocol connects to the entry server, the route carries data to the exit, and DNS plus routing rules determine how requests are resolved and routed. Each layer has distinct symptoms and corresponding fixes.
Subscription-layer issues usually appear as update failures, parsing failures or abnormal node lists. Node and protocol issues more often appear as handshake failures, authentication failures or connection timeouts. Route-layer issues tend to appear as speed fluctuations, packet loss or poor paths for a particular carrier. Routing and DNS issues often appear as certain websites failing, inconsistent region detection or applications with no traffic.
Logs are observable records of the connection flow. You do not need to understand every internal implementation detail; start by finding key events such as whether the subscription request succeeded, which node was selected, which protocol was used, which rule matched the domain and which exit was ultimately used. Assign the error to the relevant layer, then decide whether to update the subscription, switch nodes, change modes or correct the rules.