What do nodes, subscriptions and routing mean? These terms refer to the connection destination, how configuration is delivered, and how traffic is handled. When you first use cross-border networking tools, you may also see terms such as protocols, latency, global mode, system proxy and DNS. They may appear together in the interface, but each belongs to a different part of the connection process. Separate those parts first, and choosing routes, importing configurations and troubleshooting become much clearer.
A node is a set of connection parameters, not a button
“Node” is one of the most common—and most oversimplified—terms. In plain English, a node is the remote entry point the client is ready to connect to. A node usually includes a server address, port, protocol type, authentication details, encryption parameters and a display name. Labels such as “Hong Kong,” “Tokyo” or “Los Angeles” only make the list easier to scan; the actual connection uses the configuration behind the label.
Node names often include a region, line type or intended use. The region usually indicates where the exit network is located, but the name itself is not a test result. To verify the exit location, check the exit IP after connecting and test the actual path used by both your browser and application. With routing enabled, some sites may use the node while others continue using the local network, so one page cannot represent all traffic.
What the entry point, relay and exit each do
A connection path may include only the client and a remote server, or it may pass through relay infrastructure. The entry point receives the client connection; the relay forwards data between networks; and the exit makes requests to the destination website. Everyday interfaces often refer to the entire path as one node, so users may not see every segment directly.
Do not choose a node based only on its place name. A shorter physical distance often helps reduce transmission distance, but inter-provider connectivity, evening congestion, route detours and the region hosting the destination service also affect performance. When accessing a service in another region, whether the exit location meets that service’s regional requirements is often more important than whether the node name is “popular.”
- ✅ Connecting to ordinary websites: start with a nearby node that has a stable route, then watch whether pages load consistently.
- ✅ Using a region-limited service: first confirm that the exit region matches the service region instead of comparing latency labels alone.
- ✅ Long-running work connections: watch for frequent reconnects and check whether the connection recovers after switching networks.
- ❌ Judging route quality from the node name alone: a name is a configuration label, not a substitute for checking the actual exit and route.
A subscription is a configuration list, not a network protocol
A subscription usually means a configuration URL generated by the service. After the client reads it, the client can obtain a node list, node names and other supported fields. It solves the problem of “how to deliver configuration to the client”; it does not transport data and is not a protocol such as Shadowsocks, VMess or Trojan.
After you import a subscription link into the client, the client parses it and creates a node list. Selecting “Update subscription” essentially fetches the configuration again. When the service adds, changes or removes nodes, you do not need to edit each item manually. If an update fails, the old list may remain, but it will not automatically include later changes; handling varies by client.
Why subscription links should be stored carefully
A subscription URL may contain access credentials used to identify an account configuration. Anyone who obtains it may be able to read the same node list. Do not paste the full URL into a public page, public code repository, screenshot or shared document. When sharing screenshots for troubleshooting, hide the address bar, QR code and complete configuration.
A subscription may also be displayed as a QR code. The QR code is only an encoding format; scanning it still produces a subscription URL or a single-node configuration. It does not change the configuration’s access permissions. Before importing, make sure you are using a trusted client and that the permissions it requests match its features.
The correct order for importing and updating
- ✅ Copy the currently valid subscription URL from the service dashboard instead of repeatedly forwarding it from chat history.
- ✅ In the client, choose “Import from link” or the equivalent option and let the client parse the configuration automatically.
- ✅ After importing, check that node names and protocols appear correctly before selecting a node to connect.
- ✅ Update the subscription after the server configuration changes; if the update reports an error, first confirm that the URL was not truncated.
- ❌ Do not confuse “update subscription” with “switch node”: the former refreshes the list, while the latter changes the current connection target.
The protocol determines how the client communicates with the server
A protocol defines how a connection is established, authenticated, packaged and transmitted. A node answers “where to connect”; a protocol answers “how to connect.” The same region may offer nodes using different protocols, and a client may not support every protocol. An empty node list, field errors or failed connections after import can all result from incompatibility between the client and the subscription’s protocols.
| Protocol | Key characteristics | What to check |
|---|---|---|
| Shadowsocks | A relatively simple structure that uses a pre-shared key and a specified encryption method to establish a proxy connection. | Whether the client supports the configured encryption method, and whether the password and port are complete. |
| VMess | A protocol used by the V2Ray ecosystem; its configuration commonly combines transport-layer and security parameters. | Whether the user ID, transport method, path and TLS fields are consistent. |
| Trojan | Usually runs over a TLS connection and depends on correct certificate and server-name settings. | Whether the domain, certificate validation, server name and local time are correct. |
| VLESS | Separates authentication from the transport layer and is often combined with TLS, REALITY or other transport methods. | Whether the client core supports the configured security layer and flow-control parameters. |
| Hysteria2 | Based on QUIC and designed for networks with jitter or packet loss. | Whether the current network permits the required UDP traffic, and whether the authentication and TLS fields match. |
| TUIC | Also based on QUIC, using UDP as the transport and supporting concurrent transmission. | Client version, congestion-control support and UDP reachability on the current network. |
A protocol name alone does not indicate speed. Actual performance also depends on server load, entry quality, relay path, exit bandwidth, access network and destination site. QUIC-based protocols may work better in some packet-loss environments, but they may fail to connect entirely if the access network restricts UDP. In that case, switching to a transport method supported by the current network is more effective than repeatedly clicking the same node.
TLS is a transport security layer, not a proxy protocol. Configurations such as Trojan and VLESS may use TLS to establish an encrypted connection; incorrect certificate validation, server names or system time can all cause the handshake to fail. Disabling certificate validation may hide the error temporarily, but it weakens identity verification and is not a suitable routine fix.
The difference between IEPL, relays and direct connections
Direct connections, relays and IEPL describe transmission paths, not client protocols. They can be combined with different proxy protocols. This distinction matters: seeing Trojan or VLESS in the interface only tells you how the client communicates with the entry point, not whether the backend uses a relay or a dedicated line.
Direct connection: straight from the client to the remote entry point
A direct connection has a shorter structure, with the client connecting straight to the remote server. Its advantages are a simpler path and fewer forwarding stages; its limitation is that performance depends heavily on public-network connectivity between the local and remote networks. If the carrier route takes a detour or inter-network connectivity is congested, access may be unstable even when the remote server itself is working normally.
Relay: reach an access point first, then forward to the exit
A relay route first sends traffic to a more suitable access location, then forwards it over another link to the exit. This can avoid some poor public-network routes and allows the entry and exit to be deployed separately. A relay is not, however, a fixed quality grade. The access-point location, relay capacity, exit connectivity and scheduling method all affect the result.
IEPL: an enterprise-grade international Ethernet private line
IEPL generally refers to an international Ethernet private line that provides dedicated Layer 2 transport between specified locations. Consumer services often use local access and backend networking to send user traffic into this type of link, so the client may not connect directly to the other end of the complete private line. Its main difference from ordinary public-network relaying is how the cross-border backbone segment is carried, but the final experience still depends on the local entry, private-line capacity and exit network.
| Line type | Path concept | Metrics worth watching | Common limitations |
|---|---|---|---|
| Direct connection | The local network connects directly to the remote entry point | Public-network routing, inter-network connectivity and exit location | Can be strongly affected by carrier route changes |
| Relay | Reach an access point first, then forward to the exit | Entry quality, relay capacity and exit connectivity | A problem at any forwarding stage may affect the connection |
| IEPL | The backbone segment is carried over a private line between specified locations | Local access, backbone transport and exit quality | The private-line label cannot replace end-to-end testing |
Line labels should be treated as clues for choosing a route, not as a guarantee of results. If a hotel, corporate guest network or public network restricts certain ports or UDP, the client may still fail to connect to the entry point even when the backend uses a private line. End-to-end performance always includes local access, entry, backbone, exit and destination service; do not judge it from one segment alone.
Routing rules decide which path each request takes
Routing sends traffic based on domains, IPs, applications, network types or rule sets. The most common destinations are proxy, direct and reject. Proxy means the request goes through the selected node; direct means it uses the local network; reject means the client actively refuses the request. Rules may be built into the client or supplied with the configuration.
Rule mode matches requests one by one. If a domain matches a proxy rule, it is accessed through the node; if it matches a direct rule, it stays on the local path; if nothing matches, the final rule applies. Rule order can affect the result: a broad rule placed first may take effect before a more precise rule.
Global mode, rule mode and direct mode
Global mode generally means that all traffic within the client’s scope is handled by the current node. It is useful for testing whether a node works and for checking whether an application failed because a rule was missing, but it also sends requests that do not need cross-border routing through the node.
Rule mode processes traffic according to a routing list and is better suited to everyday use. Common local services stay direct, while services requiring cross-border access use a node. The challenge is maintaining the rules: a service may change domains, call new APIs or use a content delivery network. If older rules do not cover those endpoints, the page may load while images or login APIs fail.
Direct mode usually sends requests without using a node. It can pause proxying, support side-by-side troubleshooting or access resources available only on the local network. It does not necessarily mean exiting the client; some clients keep a virtual network interface active and simply send traffic out according to direct rules.
- ✅ A website will not open: switch to global mode for comparison and determine whether the problem is the node or a missing rule.
- ✅ A local service is clearly taking a detour: check whether global mode is enabled by mistake or whether a broader rule overrides the direct rule.
- ✅ A page loads but login fails: check whether authentication, static-resource and API domains are using different paths.
- ✅ Results differ between an app and a browser: confirm the client’s traffic scope and whether the app bypasses the system proxy.
- ❌ Do not change several rules at once without understanding them; it becomes difficult to identify which change caused the effect.
System proxy, virtual network adapters and in-app proxies are different
After the client establishes a connection, application traffic still needs to enter it. A system proxy provides a proxy address to applications that follow the system proxy settings. Browsers can usually read this setting, but some games, command-line tools and apps with their own networking stack may ignore it. Therefore, a client showing “Connected” does not mean every app is using the node.
Virtual network adapter mode is often called TUN mode. The client creates a virtual network interface, takes over a broader range of IP traffic through routing, and then applies routing and forwarding. It usually covers more applications than a system proxy alone, but it is also more likely to conflict with firewalls, enterprise network software, other virtual adapters or system routes. If local resources become unreachable after enabling it, check LAN bypass rules and route priority.
An in-app proxy is configured inside a particular application. It does not depend on whether other apps follow system settings, giving you more precise control, but each app must be configured separately. If the local proxy port changes with the client configuration, update the address in the app as well.
Why client interfaces differ across platforms
Windows and macOS clients can usually switch between system proxy and virtual network adapter modes, but driver installation, permission prompts and route handling differ. Android and iOS generally use the system-provided VPN interface to handle traffic; the system displays the connection status and asks for explicit authorization. Linux clients may offer a graphical interface or rely mainly on command-line tools, service processes and manual routes.
The same subscription may expose different features on different platforms. Causes include client-core support, operating-system API limits, rule formats and protocol implementation versions. Being able to import it on one platform does not mean an older client on another platform can recognize it. When fields are unsupported, update a trusted client or choose a compatible configuration rather than casually removing security parameters.
DNS leaks and exit IPs are two separate checks
DNS resolves domain names to IP addresses. Before opening a website, the system or client often sends a DNS query first. If web traffic goes through a node while DNS queries still go to a resolver provided by the local network, the DNS path and web exit may not match. This is commonly called a DNS leak.
An inconsistent DNS path may expose queried domain information and may also produce results that do not match the exit region. For example, a destination service may return different addresses based on resolver location while the web request exits from another region, causing detours, incorrect regional detection or unavailable resources.
Clients may offer remote DNS, encrypted DNS, proxy DNS or DNS hijacking features. Names vary, but the goal is to handle DNS queries along the intended path. With virtual network adapter mode enabled, also check whether another system interface retains a higher-priority resolver. A browser may also enable its own secure DNS and bypass the client’s settings.
How to verify that everything is working
- ✅ After connecting, check whether the exit IP changed and confirm that its region matches the selected node’s purpose.
- ✅ Check the resolver path used for DNS queries and confirm that they did not unexpectedly return to the local network.
- ✅ Test the browser and target application separately because they may use different proxy and DNS settings.
- ✅ Check again after switching networks; the existing connection may be rebuilt or become invalid when the address changes.
- ❌ Do not stop after the client status changes to “Connected”; routing and DNS problems may still be present.
Beginner troubleshooting should follow the connection path
When a connection fails, the most effective approach is not to change the protocol, node, rules and DNS all at once, but to eliminate causes one link at a time. First check whether the subscription updates, then whether the node completes its handshake, then whether traffic enters the client, and finally inspect routing, DNS and the destination service. Change only one variable at a time so the results remain comparable.
The subscription will not update
First confirm that the subscription URL is complete, contains no extra spaces and was not truncated by a chat app. Then check whether the client supports the subscription format. If the service dashboard has generated a new URL, use the current one to import it again instead of repeatedly refreshing an expired link. An incorrect system time can also cause validation to fail for subscription requests using TLS.
No nodes can connect
If nodes in different regions and using different protocols all fail, check the local network, client permissions, firewall and system time first. Public networks may require web authentication before access; corporate networks may also restrict specific transports. Switching to another node of the same type is unlikely to help, so first confirm that the access network allows client traffic.
Only some applications are unavailable
This usually means the underlying connection is established and the problem is more likely in the application-handling or routing layer. Check whether the app follows the system proxy, whether it requires virtual network adapter mode and whether its domains are being sent direct by mistake. If global mode works but rule mode fails, focus on routing; if the browser works but a standalone app fails, focus on the traffic-capture method.
Local resources are unavailable after connecting
Check whether global mode is enabled, whether LAN addresses are set to direct and whether virtual-network routes cover the local subnet. Corporate intranets, printers and router admin pages usually need to remain on the local path. If restoring direct access fixes the issue immediately, adjust routing or LAN bypass settings rather than changing the remote node.
Once you understand these terms, the client interface no longer looks like a row of switches with no obvious meaning. Choose nodes by region and path, check subscription and protocol compatibility when importing, use routing for everyday traffic, and troubleshoot by checking application handling, exit IP and DNS together. The terms themselves are not complicated; the key is placing each one in the right part of the connection flow.