The hardest part of learning VPN terminology is rarely a single difficult word. It is that subscriptions, nodes, routes, protocols, and clients often appear together in one interface. In practice, they belong to different layers: a subscription delivers configuration, a node provides endpoint details, a route describes the path data takes, a protocol defines how the client communicates with the server, and routing rules decide which requests use that path.
Once separated, a connection can be understood like this: the client reads node settings from the subscription, matches traffic against routing rules for the current mode, and uses the selected protocol to send qualifying traffic to the node. The node accesses the target site remotely, so the site sees the node's exit address rather than the public address of the user's current network. A mismatch at any layer can appear as a failed connection, an unexpected region result, incomplete app coverage, or abnormal domain resolution.
What are subscriptions, subscription URLs, and clients?
A subscription is an updatable configuration list
A subscription is neither a standalone route nor an installer. It is usually a configuration list maintained by the service, containing node names, server addresses, ports, protocol types, authentication details, and transport settings. Once the client reads it, selectable nodes appear in the interface.
When subscription content changes, the client must update or refresh it to retrieve the latest node settings. Simply switching app screens does not update a subscription; conversely, updating a subscription does not necessarily switch the active node. Auto-update behavior varies by client: some refresh at startup, some require manual action, and others let you define an update policy.
A subscription URL is a configuration entry point—do not share it publicly
A subscription URL is an entry point for retrieving a configuration list and may contain a token used to identify subscription access. Anyone who obtains it may be able to read the associated configuration, so do not post the full URL on public pages, in screenshots, or in public code repositories. If you need to show its structure while troubleshooting, remove authentication parameters and query content after masking the domain.
After copying a subscription URL, look in the client for an option such as “Import from URL,” “Add subscription,” or “Remote configuration,” rather than pasting it into a browser address bar, downloading it, and trying to run it directly. Some services provide formats for specific clients. If no nodes appear after import, common causes include an incomplete copy, an unsupported response format, an outdated subscription, or a local network that could not retrieve the configuration.
The client reads configuration and manages traffic
A client is a program running on your device. It handles subscription management, node selection, protocol implementation, traffic routing, DNS processing, and connection-status display. After the same subscription is imported into different clients, the nodes may be identical, while available rule modes, system proxy support, TUN handling, and logging tools can differ.
| Term | Primary role | Common misconception |
|---|---|---|
| Subscription | Stores and distributes an updatable set of node configurations | Assuming the subscription itself is the node currently in use |
| Subscription URL | Lets the client retrieve remote configuration | Assuming it is merely an ordinary download URL that can be forwarded publicly |
| Client | Parses configuration, implements protocols, and manages device traffic | Assuming every client has exactly the same modes and capabilities |
| Configuration file | Stores node, routing, DNS, and route parameters | Assuming a successful import means every app is already covered |
- ✅ Copy the complete subscription URL from the service dashboard and make sure it contains no extra spaces or line breaks.
- ✅ Import it through the client's subscription or remote-configuration entry instead of guessing server parameters one by one.
- ✅ Update the subscription manually after importing and confirm that the node list appears.
- ✅ Select a node and start the connection, then use the target app to check the actual exit.
- ❌ Do not display the full subscription URL in public screenshots, chat-group files, or code repositories.
Why nodes, servers, and routes are different concepts
A node is usually a selectable configuration entry in the client. It contains the information needed to connect to an entry server and may include labels for region, purpose, or route type. A server is the actual device or instance providing the network service. Multiple node configurations can point to the same underlying infrastructure, or appear separately because their ports, protocols, entry points, or exits differ.
A route describes the path data takes from the current network to the remote exit. You select a node, but the actual experience also depends on the local carrier network, entry location, inter-network routing, relay method, exit quality, and the target site's return path. Similar node names do not guarantee identical routes, and the same region does not guarantee identical performance.
Direct, relay, and IEPL routes compared
A direct route means the client connects straight to the remote server's public entry point. Its structure is simple and relies less on service-side relays, but public cross-border routing can vary with the local network and time of day. Whether direct access is suitable depends not only on map distance, but also on the actual route from the local network to that entry point.
A relay route first connects to a nearby or well-connected entry point, then the service forwards traffic to the remote exit. Relays are generally used to avoid problematic public-network segments or to give the entry and exit separate roles. A relay is not automatically faster; detours, forwarding congestion, or a poor return path can still reduce performance.
IEPL usually refers to an Ethernet private line used in enterprise international communications. When a service page labels a route “IEPL,” understand it as a specific cross-border backbone segment using private-line or dedicated transport—not as a promise that every segment from the device to the target site avoids the public internet. The connection to the entry point and the path from the exit to the target service may still use ordinary networks, so the label cannot replace evaluating the actual route.
| Route type | Path characteristics | What to evaluate |
|---|---|---|
| Direct | The device accesses the remote public entry point directly | Observe the route and stability from the local network to the entry point |
| Relay | Reaches an access point first, then forwards traffic to the remote exit | Compare entry quality, forwarding path, and target region |
| IEPL private line | Some backbone segments use private-line transport | Evaluate the entry point, exit, and target service together |
The protocol determines how the client and server communicate
A protocol defines how the client organizes, authenticates, and transports data. It is separate from the route: routes in the same region can use different protocols, and the same protocol can run over a direct or relay path. The client must support the node's protocol and related transport settings; otherwise, a connection cannot be established even when the server address is correct.
Shadowsocks
Shadowsocks is an encrypted proxy protocol. Its configuration usually includes a server, port, password, and encryption method. It has many implementations and broad client compatibility, but both ends must use mutually supported encryption. If authentication fails or no traffic flows after connection, first check the encryption method and plugin parameters rather than changing ports at random.
VMess and VLESS
VMess is a common protocol in the V2Ray ecosystem, with settings for user identity, transport, and security. VLESS uses a different authentication and protocol design and is often combined with TLS, REALITY, or other transport-layer settings. The names may look similar, but they are not interchangeable; the client must parse every field according to the protocol type supplied by the subscription.
Trojan
Trojan typically runs over TLS, with connection settings such as the server name, certificate validation, and password. Certificate validation is an important part of establishing a TLS connection. If the system time, server name, or certificate chain is abnormal, the client may reject the connection. Disabling certificate validation just to suppress an error is not a sound long-term fix.
Hysteria2 and TUIC
Hysteria2 and TUIC both rely heavily on QUIC and UDP transport, with a focus on maintaining efficient delivery across complex links. Their suitability depends on local UDP support, the client implementation, and server-side settings. If the current network restricts UDP, these nodes may be unstable or completely unavailable; compare them with other protocols provided by the service.
| Protocol | Configuration focus | Troubleshooting direction |
|---|---|---|
| Shadowsocks | Encryption method, password, and plugin parameters | Confirm that both ends support the same encryption method and plugins |
| VMess | User identity, transport method, and security parameters | Check the client core and the complete transport configuration |
| VLESS | TLS, REALITY, flow control, and transport settings | Do not replace the import with VMess-style configuration |
| Trojan | Password, server name, and certificate validation | Check the system time, domain, and certificate chain |
| Hysteria2 | UDP reachability, authentication, and congestion-control parameters | Confirm that the current network does not restrict the relevant UDP traffic |
| TUIC | UDP reachability, authentication, and QUIC parameters | Compare with other protocols to determine whether the network is restricting traffic |
What system proxy, TUN, and virtual network adapters each handle
A connection button showing “Running” does not mean every type of traffic on the device automatically enters the node. The client must also capture requests through the system proxy, TUN, or a VPN interface provided by the platform. Differences in coverage are the main reason a browser may work while a game or command-line tool shows no change.
System proxy coverage depends on whether apps follow proxy settings
A system proxy registers a proxy address with the operating system. Browsers and many desktop apps read this setting and can pass HTTP or SOCKS requests to the client. Some apps use their own network stack, a fixed proxy, or direct connections and may not follow the system proxy. The client can be running normally while that app still connects directly.
TUN mode captures traffic at a broader network layer
TUN mode receives IP traffic through a virtual network interface and forwards it according to the client's rules. It can usually cover more apps that do not support system proxies and is better suited to scenarios involving UDP. It may also require additional system permissions and can conflict with other virtual adapters, security software, or enterprise network policies.
On mobile platforms, clients usually use the system VPN interface to capture traffic, relying on standard network capabilities provided by the operating system. Desktop platforms may offer both a system proxy and TUN. A “global mode” with the same name can mean different things across clients: it may change only routing rules rather than the capture method. Check both the operating mode and the route mode.
- ✅ If the browser works but other apps do not, check whether those apps follow the system proxy.
- ✅ To cover programs that do not read the system proxy, check whether the client supports TUN or the system VPN interface.
- ✅ If TUN fails to start, check system permissions, virtual adapter conflicts, and leftover routes.
- ✅ If the network remains unavailable after closing the client, confirm that the system proxy has been restored.
- ❌ Do not equate “node connected” with “all app traffic now uses a different exit.”
How to choose global, rule, and direct modes
The operating mode answers “which requests should be sent to the node?” Clients commonly offer global, rule, and direct modes, although the exact names may vary. Choosing a mode does not change the node's region or fix protocol incompatibility; it only determines where matched traffic goes.
Global mode
Global mode generally sends all requests captured by the client to the current node. It is useful for a short diagnostic test: if a site fails in rule mode but works globally, the issue is more likely that its domain or IP did not match the expected rule. Global mode does not necessarily cover every device connection, because apps outside the system proxy or TUN can still bypass the client.
Rule mode
Rule mode determines whether traffic uses the node, a direct connection, or is rejected based on the domain, IP, app, or network category. It can keep local services direct while sending requests that require a specific exit through the node. When rules have an order, the first matching rule usually determines the result. If domain rules and the final connection IP resolve to different classifications, the route may differ from expectations.
Direct mode
Direct mode generally lets captured requests use the current network exit. It is useful for pausing proxy behavior or running comparison tests. It is not always the same as fully quitting the client: the client may still handle DNS, maintain a virtual adapter, or log connections. To restore the original network state, stop the service as documented by the client and check the system proxy.
| Mode | Traffic handling | Suitable use |
|---|---|---|
| Global | All captured requests are sent to the current node | Quickly compare whether the issue involves the node or the rules |
| Rules | Choose a path by domain, IP, app, or category | Daily use with local and international traffic handled separately |
| Direct | Captured requests use the current network exit | Compare the exit, pause the proxy path, or troubleshoot the local network |
How DNS, DNS leaks, and regional results are related
DNS resolves domain names to IP addresses. Whether a web request travels through a node and who resolves its domain are related but separate questions. If the client captures the connection but not DNS, queries may still go to a resolver supplied by the local network. When the client enables remote DNS, encrypted DNS, or TUN interception, the query path may change.
A DNS leak generally means that a resolution request expected to use a controlled path is instead sent to a local or otherwise unintended resolver. This may reveal the resolution service used by the current network or return region-specific domains that do not match the node's exit. The resolver location shown by a test page is not necessarily the user's location: public resolvers may use anycast networks, so the displayed location is only a clue.
Streaming services, search engines, and content delivery networks may evaluate exit IP, DNS results, account region, cache data, and app location signals together. After switching nodes, an app may retain an old connection or cache and temporarily continue showing the previous region. A safer sequence is to stop playback, switch nodes, rebuild the connection, and reopen the target app for another check.
Browsers may also enable their own secure DNS and bypass the operating system's resolver settings; managed devices may use policy-defined resolvers. During troubleshooting, check the client's DNS mode, the operating system settings, and the browser settings together instead of repeatedly overriding them in different places.
- ✅ Confirm that the client has enabled DNS handling compatible with the current mode.
- ✅ After switching nodes, close the old connection and reopen the target app.
- ✅ Check whether the browser specifies its own secure DNS service.
- ✅ When the region result is unexpected, check the exit IP, DNS, and account region together.
- ❌ Do not treat the resolver facility location shown by a test page as the device's location.
Why clients look different across platforms
Windows, macOS, Linux, iOS, and Android have different network permissions and system interfaces, so their clients will not look identical. Desktop systems generally offer more detailed control over the system proxy, TUN, routes, and background services. Mobile systems rely more on the system VPN interface and are affected by background-execution and battery-saving policies.
Common Windows issues include a system proxy that was not restored, virtual network adapter driver conflicts, and inconsistent local-network sharing settings. macOS displays clear prompts for network-extension permissions, and the first use of related modes may require approval in system settings. Linux clients may require familiarity with desktop proxy environment variables, daemons, or route permissions; command-line programs may not read the desktop system proxy.
iOS clients generally capture network traffic through the system VPN configuration, while the subscription import method depends on the app's supported features. Android clients also use the system VPN interface and may offer per-app routing. If battery-saving policies restrict background activity, the connection may be reclaimed after the screen locks. Platform differences do not change the basic relationship between subscriptions, nodes, and protocols; they change how traffic is captured.
| Platform type | Common capture method | What to watch for |
|---|---|---|
| Desktop systems | System proxy, TUN, and virtual network adapter | Permissions, leftover proxy settings, route conflicts, and conflicts with other network tools |
| Mobile systems | System VPN interface | Background limits, battery-saving policies, and per-app routing |
| Command-line environments | Environment variables, explicit proxy, or TUN | Terminal programs may not read desktop proxy settings |
From importing a subscription to diagnosing connection problems
For beginners troubleshooting connection problems, the most effective approach is to verify each layer step by step rather than changing every setting in succession. Changing multiple variables at once makes it impossible to tell which adjustment helped. The sequence below starts with the configuration entry point and progressively checks the protocol, route, traffic capture, and DNS.
- Verify the subscription source. Copy the current subscription URL from the service dashboard, import it into a supported client, and update the subscription manually.
- Verify the node configuration. Check that the nodes appear completely, choose one whose region matches the target service, and do not draw conclusions from descriptive words in the name alone.
- Verify protocol support. Check that the client core supports the node's Shadowsocks, VMess, Trojan, VLESS, Hysteria2, or TUIC protocol and its associated transport settings.
- Verify the capture method. Use the system proxy for browser testing; when broader app coverage is needed, check whether TUN or the system VPN interface is running.
- Verify the routing mode. Start with global mode for comparison, then return to rule mode to locate unmatched domain, IP, or app rules.
- Verify the DNS path. Check whether the client, system, and browser use different resolution settings, and rebuild the connection after switching nodes.
- Keep the error details. Record handshake, certificate, authentication, timeout, or UDP error types from the client log, and provide support staff with a redacted description of the configuration environment.