“What do nodes, protocols, and split tunneling mean?” is one of the most common questions when importing a subscription for the first time. These terms describe different layers: a subscription delivers configuration, a node is a connection entry point, a route describes the network path, a protocol defines client-server communication, and routing rules decide which path each request takes. Once these layers are separated, most client settings become much easier to understand.
A common beginner mistake is to blame every connection result on whether a node is “good.” In practice, the experience depends on the local network, protocol support, entry location, cross-network path, exit location, DNS resolution, and the destination website. Nodes with similar names may use different underlying paths, while different protocol names do not automatically determine a fixed speed ranking.
Where do subscriptions, nodes, and routes fit?
A subscription link is not the route itself
A subscription link usually points to configuration generated by the service. After accessing the address, the client reads data such as node names, server addresses, ports, protocol parameters, authentication details, groups, and rules, then displays them as selectable configurations. Clients do not support exactly the same fields, so one subscription may appear with different groups or options in different apps.
The subscription link itself does not continuously carry web traffic. After an update, the client connects to the relevant servers using the imported configuration. In other words, the subscription address retrieves configuration, while the node address establishes the connection. Updating a subscription only fetches the configuration again; it does not reinstall the client or automatically fix every network problem.
A subscription address may contain access credentials used to identify the configuration, so do not post the full link on public pages, in screenshots, or in shared documents. If the link has been exposed, generate a new one or replace it from the service panel rather than simply deleting the old local configuration. Removing a local record does not invalidate an address that has already been leaked.
A node combines entry and exit configuration
Node names such as “Hong Kong,” “Japan,” or “United States” in a client usually indicate the exit region, but the name is only a label supplied by the service. A node configuration must at least tell the client where to connect, which protocol to use, and how to authenticate. After receiving the traffic, the server accesses the destination through its own network path, so the destination website will usually see the server’s exit address.
A node should not be understood simply as one fixed machine. A service may route traffic between entry points, transit paths, and exits, or aggregate multiple entries behind one exit. When evaluating a node, prioritize the exit region, route type, protocol compatibility, and current network performance rather than decorative words in its name.
A route describes the path in between
A route describes how data travels from the user side to the exit. Direct, relayed, and dedicated paths are common descriptions, but they are not protocol names. The protocol defines the communication format; the route defines the network path. They can be combined: the same protocol can run over different routes, and one route can carry different protocols.
| Term | Primary role | Commonly shown in the client | What it cannot tell you on its own |
|---|---|---|---|
| Subscription | Delivers and updates configuration | Subscription URL, configuration groups | The actual quality of the route |
| Node | Provides selectable connection entry points and exit configuration | Region name, protocol name, route label | The underlying path |
| Protocol | Defines how the client and server communicate and authenticate | Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUIC | The exit region or bandwidth |
| Route | Describes the network path between entry, transit, and exit | Direct, relayed, and IEPL dedicated route labels | Actual connection performance |
| Split tunneling | Chooses proxy or direct paths for different requests | Rule mode, global mode, direct mode | Whether the service itself is available |
How to read common protocol names
A protocol is a communication rule that both the client and server must understand. If the client does not support a protocol, the connection cannot be established even when the server address, authentication details, and network are all correct. Protocols may also be combined with transport methods, TLS, security parameters, or an obfuscation layer, so the protocol’s main name alone does not reveal the full configuration.
Shadowsocks
Shadowsocks is an encrypted proxy protocol. A typical configuration includes a server address, port, password, and encryption method. Its structure is relatively straightforward and it is supported by a wide range of clients. The encryption method must match the server; an older client that does not support the method used by the subscription may fail to connect or import an unusable configuration.
Shadowsocks handles data transfer and authentication between the client and proxy server. It does not automatically provide sophisticated routing; those rules are usually implemented separately by the client. When you see a “Shadowsocks node,” evaluate protocol compatibility and route performance separately.
VMess and VLESS
VMess is common in the V2Ray ecosystem and includes identity authentication, time checks, and multiple transport combinations. If the device clock is significantly wrong, some configurations may fail because of validation errors. VMess can use different transport methods, so nodes labeled VMess may still have different network characteristics.
VLESS uses a lighter authentication design and does not itself provide complete data encryption, so it typically relies on TLS or another secure transport layer to protect the connection. The server name, certificate validation, transport method, and path parameters must match. Disabling certificate validation may bypass certain errors, but it weakens verification of the server’s identity and is not suitable as a long-term fix.
Trojan
Trojan typically runs over a TLS connection. Key settings include the service address, password, server name, and certificate validation. Its connection profile resembles common TLS traffic, but that does not mean every Trojan configuration will automatically deliver better speed or stability. A mismatch between the certificate, domain, and server name is a common cause of connection failures.
Hysteria2 and TUIC
Hysteria2 and TUIC commonly use QUIC-based, UDP transport approaches, with an emphasis on congestion control, multiplexing, and performance on unstable networks. They may perform well on some high-latency or lossy networks, provided the current network allows stable UDP traffic. Some public networks, enterprise networks, or routers restrict UDP, which can result in handshake failures, intermittent disconnects, or an unusable fallback.
Client versions and parameter compatibility also matter for these protocols. Even when the protocol name is the same, substantial differences between implementations can prevent interoperability. When problems occur, update the subscription and client first, then confirm the server requirements instead of copying parameters from another protocol at random.
| Protocol | Configuration focus | Common incompatibility causes | How to assess it |
|---|---|---|---|
| Shadowsocks | Encryption method, password, service address | The client does not support the encryption method | Verify the encryption method first, then test the route |
| VMess | Identity details, device time, transport parameters | Missing parameters or an incorrect clock | Check the complete configuration and client logs |
| VLESS | TLS, server name, transport method | The certificate and transport parameters do not match | Keep certificate validation enabled and verify the domain |
| Trojan | Password, TLS, server name | Certificate validation failed | Check the system time, domain, and certificate |
| Hysteria2 | UDP reachability, authentication, bandwidth parameters | The current network restricts UDP | Cross-test with a TCP-based configuration |
| TUIC | UDP reachability, authentication, congestion control | The client and server implementations are incompatible | Confirm client support first |
What do routing rules actually decide?
Routing rules are the client’s path-selection system. After a browser or app sends a request, the client uses the domain, destination address, application process, network type, or rule set to decide whether the request uses a proxy, a direct connection, or is rejected. Because routing happens on the device, different websites can use different paths through the same node.
Rule mode
Rule mode matches requests one by one. A common strategy is to send local services and LAN resources directly, route domains that need international access through the proxy, and reject ads, trackers, or suspicious addresses. Rule mode is usually better for everyday use because it avoids unnecessary detours and reduces the chance that local websites trigger extra verification when the exit region changes.
Rules do not match only the text in the browser address bar. A webpage may also request images, scripts, APIs, video, and third-party login domains. If the main site uses the proxy but a required API is mistakenly sent direct, the page may open with incomplete functionality. When troubleshooting, inspect related domains instead of adding only the main domain to the rules.
Global mode
Global mode generally sends most traffic handled by the client through the selected node. It is useful for briefly checking whether a rule is missing: if rule mode fails but global mode works, the problem is likely rule matching or DNS resolution. If both modes fail, continue checking the node, protocol, system proxy, and destination service.
Global mode does not mean that every piece of data on the device is necessarily intercepted. The coverage depends on whether the client uses a system proxy, virtual network interface, or application-level proxy. Some apps ignore system proxy settings, while others use their own DNS resolution or network stack and may bypass an ordinary system proxy.
Direct mode
Direct mode bypasses the proxy path. It is commonly used to access LAN devices or local services, or to determine whether the issue comes from the proxy configuration. If both direct and proxied connections fail, check the local network and destination first. If direct works but the proxy fails, check the node and protocol. If the proxy works but direct access fails, the cause may be the local network path or differences in access by region.
- ✅ For everyday browsing, prefer rule mode so local services and international routes use suitable paths.
- ✅ When some page resources fail to load, switch briefly to global mode to check for a missing rule.
- ✅ When accessing a router, storage device, or LAN service, make sure the relevant address remains direct.
- ❌ Do not treat long-term use of global mode as a replacement for fixing routing rules.
- ❌ Do not import a configuration file that may overwrite existing rules when you do not know its source.
What is the difference between direct, relayed, and IEPL dedicated routes?
Here, “direct” describes the route structure, not the direct mode in a client. A direct route means the client connects straight to a proxy server in the target region without an additional transit entry arranged by the service. The structure is simple, but cross-carrier and cross-region paths depend more heavily on public-network routing, so evening congestion or detours are reflected more directly in the connection experience.
A relayed route first connects to an entry point that is nearby or easier to reach, then forwards traffic to the target exit. This separates optimization of the user-to-entry segment from the entry-to-exit segment. Relaying can avoid some poor public routes, but it adds another component to maintain. A healthy entry with a faulty exit, or a problem between entry and exit, can still make the node unusable.
IEPL is a common abbreviation for International Ethernet Private Line, originally describing point-to-point enterprise network connections provided by carriers. In subscription-service terminology, an “IEPL dedicated route” usually means that a private or similarly controlled transport path is used between entry and exit, while the user-to-entry segment still passes through the local access network. It does not mean the entire path from the device to the destination avoids the public network, nor that local network conditions can never affect it.
Route labels therefore help explain the architecture but cannot replace real-world testing. A more reliable approach is to choose an entry point that matches your network, observe sustained connections, initial page loads, video buffering, and file transfers, then compare routes. A brief test reflects only the conditions at that moment and should not be used to draw long-term conclusions.
| Route type | Basic path | Main characteristics | What to check |
|---|---|---|---|
| Direct route | The user connects directly to the exit | Simple structure; greater reliance on public-network routing | Cross-network detours, exit reachability, local network |
| Relayed route | The user connects to an entry point, then traffic is forwarded to the exit | The access and cross-border segments can be optimized separately | Entry status and the forwarding path from entry to exit |
| IEPL dedicated route | After reaching the entry point, traffic uses controlled transport to the exit | The intermediate path is usually more controlled | Local access from the user to the entry and exit status |
Why do DNS leaks and domain resolution affect the result?
After a user enters a domain, the device must first resolve it to a network address. DNS performs this lookup. If web traffic uses a proxy while domain queries are handled by a local resolver, a DNS leak may occur: the local resolver can still see the requested domains, and the results may not match the proxy’s exit region.
A DNS leak does not necessarily make a site completely unreachable. More common symptoms include being directed to an unsuitable content delivery node, inconsistent regional detection, a main page that loads while its API fails, or looping decisions in rule mode. Clients may offer system resolution, proxy resolution, encrypted resolution, or virtual mapping, each with different effects on compatibility and routing precision.
When rules depend on domain information, the order of resolution is especially important. If an app resolves a domain to an address before the client receives the request, domain-based rules may not match. Clients with a virtual network interface can usually take over traffic and resolution more completely, but they are also more likely to conflict with security software, enterprise network policies, or other network tools.
When checking DNS issues, do not look only at the exit address. Also verify the resolver’s region, whether the browser has independent encrypted resolution enabled, whether the client controls DNS, and whether any rule mistakenly sends DNS requests direct. After making changes, clear the system and browser resolution caches before reconnecting.
How to import subscriptions and update clients on different platforms
The subscription import process is broadly similar: obtain the subscription address from the service panel, add the remote configuration in a compatible client, wait for the nodes to download, then choose a group, node, and operating mode. The part most likely to fail is not pasting the link, but whether the client supports the subscription format, protocol, and complete parameters.
Desktop platforms
Windows and Linux clients usually offer comprehensive system proxy, virtual network interface, routing-rule, and connection-log features. A system proxy affects only apps that read proxy settings; virtual interface mode can handle more traffic but requires the relevant system permissions. If an app does not use the proxy, first confirm how traffic is currently being intercepted rather than assuming the node has failed.
macOS clients may likewise offer system proxy and virtual network interface modes. System updates, security policies, and network-extension permissions can affect whether the virtual interface starts. When a client shows “Connected,” that only means the local service is running; it does not necessarily confirm a successful handshake with the remote node. Check the connection log or actual access results.
Mobile platforms
Android clients generally use the system VPN interface to handle device traffic and can decide which apps use the proxy. App-based routing and domain-based routing are separate dimensions: the former decides which apps enter the client, while the latter decides which path they use afterward. Conflicting settings can make a browser work while a specific app cannot connect.
Clients on Apple mobile platforms also rely on the system network extension. Background policies, low-power state, and network changes can affect connection persistence. After switching from Wi-Fi to a mobile network, if the connection appears active but requests stall, reconnect first and then decide whether the subscription needs updating.
- Copy the subscription address for the current client from the service panel; do not type it manually from a screenshot in a chat history.
- Add the remote configuration in the client and confirm that nodes and policy groups appear after import.
- Choose a node compatible with the client and keep the default protocol parameters for the first test.
- Enable rule mode, open a regular webpage to verify the basic connection, and then test the specific app.
- When checking for a routing-rule issue, switch briefly to global mode for comparison, then restore rule mode.
- Update the subscription after server-side configuration changes. If the update fails, check that the subscription address is complete and that the configuration server is reachable.
How to troubleshoot connection failures layer by layer
Effective troubleshooting depends on comparison, not on changing every option in succession. Change one variable at a time so you can identify the affected layer. Check the local network first, then the subscription and client, followed by the node, protocol, route, routing rules, and DNS. If you change the client, node, and mode at once, even a restored connection will not reveal the real cause.
- ✅ Turn off the proxy and confirm that the local network can access commonly used services normally.
- ✅ Update the subscription and check that the node list is complete; note any import error shown by the client.
- ✅ Confirm that the client supports the node’s protocol, encryption method, and transport parameters.
- ✅ Switch between different routes in the same client to distinguish a single-node issue from a broader configuration issue.
- ✅ Compare rule mode with global mode to determine whether a routing rule is missing.
- ✅ Check the system time, certificate validation, DNS interception, and virtual network interface permissions.
- ✅ Read resolution, handshake, timeout, or certificate errors in the client log before choosing the next step.
- ❌ Do not permanently disable certificate validation just to remove an error.
- ❌ Do not change congestion control, transport paths, or low-level routing parameters when you do not understand their purpose.
“Resolution failed” in a log usually points to DNS or domain configuration. “Connection timed out” may involve an unreachable network, a restricted port, or a faulty route. For a “certificate error,” check the device time, server name, and certificate chain. For “authentication failed,” check whether the subscription has expired, whether the configuration is complete, and whether the client has modified authentication fields incorrectly.
If a node works on one network but not another, compare carrier paths, UDP support, and local device settings. If every node fails in one client while the same subscription works in another compatible client, the likely cause is the client version, permissions, or interception method. If no client can update the subscription, first confirm the subscription address and the reachability of the configuration server.