When you first use a VPN or proxy client, subscriptions, nodes, route types, protocols, split tunneling, global mode, and rule mode can seem interchangeable. They actually belong to different layers: a subscription distributes configuration, a node is a set of server connection parameters, a route describes how data reaches the node, a protocol defines communication between the client and server, and split tunneling determines which requests enter the proxy path.
You do not need to memorize networking theory to understand these terms. A more useful approach is to follow one connection from start to finish: the client reads the subscription and receives a node list; after you choose a node, it establishes a connection using the relevant protocol; system traffic is then directed through the proxy or directly according to global or rule mode. Once the layers are separated, most settings pages become much easier to understand.
Start by separating subscriptions, nodes, and servers
A subscription link is an updateable configuration entry point
A subscription link is usually generated by the service. When the client accesses it, it retrieves node names, server addresses, ports, protocol parameters, and required authentication details. It is more like a remote configuration list than a specific node. When the service changes its routes, you can select “Update subscription” or “Refresh configuration” in the client instead of entering every item again.
A subscription link may return encoded text or a configuration format recognized by clients such as Clash and sing-box. If you open it directly in a browser and see a long string of characters, that does not necessarily mean the link is broken. The usual procedure is to copy the complete link and paste it into the client’s subscription import field.
A node is a selectable connection profile in the client
A node generally includes a destination server, port, protocol, authentication parameters, and transport settings. Names such as “Tokyo,” “Singapore,” or “United States” in a client list are usually labels for convenience. Nodes with the same name may use different underlying servers, entry points, or network paths; nodes with different names may share part of the same infrastructure.
“Server” generally refers to physical or virtual computing resources, while “node” refers to a connection profile the user can select. One server can host multiple protocols or ports and therefore provide several node profiles. Conversely, a displayed node may use load balancing and connect to different backends. Choose nodes based on actual performance and purpose, not just their names.
- ✅ After updating a subscription, check whether existing nodes were replaced or renamed.
- ✅ When importing multiple subscriptions, give each source a clear group name.
- ✅ If a node stops working, refresh the subscription first, then check the client’s clock and network permissions.
- ❌ Do not treat a subscription link as a single node address and split it manually.
- ❌ Do not infer route quality or the exact path from a location name alone.
What IEPL, relays, and direct connections mean
A route type describes how your local network reaches a remote node. It is not the same thing as a protocol such as Shadowsocks or Trojan. Two nodes using the same protocol may use different routes, and the same route type can carry different protocols. Confusing routes with protocols is one of the most common mistakes beginners make when choosing a connection.
| Route type | Connection path | Key characteristics | What to look for |
|---|---|---|---|
| Direct connection | The local network connects directly to the remote node | A simple structure whose performance depends heavily on the local carrier and international gateway | Whether the route takes a detour, evening fluctuations, and packet loss |
| Relay | The connection first reaches a nearby or more stable entry point, then continues to the remote exit | Can improve some poor direct routes, but both the entry point and relay path affect the result | Entry-point location, forwarding path, and performance during congestion |
| IEPL | Part of the path is carried over international Ethernet private-line resources provided by a carrier | Usually emphasizes link stability, though actual quality still depends on the service configuration and local access | Entry access, exit resources, and real-world application performance |
A direct connection is not necessarily faster
A direct connection removes the relay step, but the network route is not necessarily the shortest. Cross-carrier traffic, regional links, or congested international gateways can cause data to take a detour. Conversely, a well-positioned relay entry point can keep the local-to-entry segment on a more stable path before the backend handles international transmission. Speed therefore cannot be judged simply by counting servers along the way.
A relay is not the same as the node’s displayed location
If a node is shown as Japan, that usually means its exit is in Japan or that Japan is its primary exit location; the relay entry point may be elsewhere. The exit IP shown by a website and the entry point the client connects to first are not always in the same place. When troubleshooting, distinguish between an entry connection failure and an exit service problem.
IEPL is a route resource, not an encryption protocol
IEPL commonly describes an international Ethernet private-line connection. It addresses part of the network transport path; it does not define client authentication, encryption, or traffic encapsulation. The client still needs a specific protocol to connect to the server. When you see an “IEPL node,” understand it as a node whose transport path partly uses the corresponding private-line resource, not as a client protocol called IEPL.
What common protocol names mean
A protocol determines how the client and server authenticate, package, and transmit data. The client must support the protocol and transport parameters used by the node; otherwise, a connection cannot be established even when the server address and port are correct. These names often appear in subscription configurations, but each has a different design focus.
| Protocol | Primary role | Configuration details | Common misconception |
|---|---|---|---|
| Shadowsocks | A lightweight encrypted proxy protocol | The encryption method, password, server, and port must match | Treating it as identical to every system-level VPN protocol |
| VMess | A proxy protocol widely used in the V2Ray ecosystem | User ID, transport method, TLS, and path parameters | Entering only the server address and ignoring the transport layer |
| Trojan | A proxy protocol commonly used with TLS | Password, domain, certificate verification, and TLS settings | Assuming connection verification remains complete after disabling certificate checks |
| VLESS | A lightweight proxy protocol framework | User ID and outer security settings such as TLS and REALITY | Assuming the protocol automatically provides every form of encryption |
| Hysteria2 | A QUIC-based transport designed to maintain throughput on challenging networks | UDP availability, authentication, TLS, and bandwidth parameters | Repeatedly switching among similar nodes on a network that restricts UDP |
| TUIC | A QUIC-based proxy protocol | UDP environment, user credentials, certificates, and congestion-control settings | Ignoring local network restrictions on QUIC or UDP |
Shadowsocks configurations are relatively compact and supported by many clients, but the encryption method must match the server. VMess and VLESS are often combined with transport and security layers such as WebSocket, gRPC, TCP, TLS, or REALITY. This is where subscription imports help: related parameters can be delivered to the client as one complete configuration, reducing omissions during manual entry.
Trojan is commonly used with TLS and domain certificate verification. If the device clock is significantly wrong, the domain does not match, or certificate verification fails, the connection may not be established. When you encounter a certificate error, check the system time and subscription configuration instead of disabling certificate verification.
Hysteria2 and TUIC both depend on QUIC and primarily run over UDP. They may perform well on some high-latency or lossy networks, provided the local network allows the required UDP traffic. If a company, campus, hotel, or public network restricts UDP, these nodes may fail to connect. In that case, compare them with an available TCP-based node.
How to import a subscription link into a client
Button names vary between clients, but the import process is broadly the same. Copy the subscription link from a trusted service panel, then add a remote configuration or subscription in the client and wait for it to parse before selecting a node. Do not rewrite subscription content line by line as a manual configuration unless you clearly understand what each field does.
- Copy the complete link: Make sure the beginning, parameters, and final characters are all present. Some chat apps truncate long links, so check that the copied text is complete.
- Open subscription management: In the client, look for “Subscriptions,” “Configuration,” “Remote configuration,” or “Import from URL.”
- Paste and save: Give the subscription a recognizable name, then update it. If the client asks you to choose a configuration format, follow the service instructions.
- Select a node: Choose the target location in the proxy group or node list instead of leaving an empty configuration with no specified exit.
- Choose a running mode: For everyday use, start with rule mode. Switch temporarily to global mode when you need to test the complete proxy path.
- Verify the connection: Visit a network testing page to confirm that the exit IP and DNS match expectations, then test the websites or apps you actually need.
Updating a subscription usually overwrites the nodes generated by that subscription. If you directly edit internal parameters in a subscription node, the original values may return at the next update. Custom rules that need to persist are better placed in the client’s supported overrides, extended configuration, or local rule files rather than edited directly in a remote node.
Subscription link
→ Client retrieves the remote configuration
→ Parse nodes and proxy groups
→ Select a node
→ Establish the protocol connection
→ Split-tunneling rules determine the request destination
→ Proxy or direct connection- ✅ After importing, check that the node list appears normally rather than relying only on an “Added successfully” message.
- ✅ Use the client’s built-in subscription update function regularly to retrieve configuration changes.
- ✅ Before changing clients, confirm that the new client supports the protocols and transport methods in the subscription.
- ❌ Do not convert subscription links containing credentials on websites of unknown origin.
- ❌ Do not run multiple clients that take over system networking at the same time while troubleshooting.
How to choose between global, rule, and direct modes
The running mode determines how traffic is handled after entering the client. It does not change the node itself or turn a direct route into a relay route. Beginners often assume “global” means faster, but it simply means that more requests are sent through the current proxy node.
Global mode: Most traffic uses the proxy
Global mode is useful for temporarily checking whether a rule is missing or whether a website is reachable through the proxy path. Its drawback is that local websites, LAN services, and apps that do not need a proxy may also take a detour, adding latency and potentially affecting printers, router admin pages, or local development services.
Rule mode: Classify traffic by domain, IP, or application
Rule mode evaluates requests against rule sets. Common logic includes sending LAN addresses directly, connecting local websites directly, routing domains that require international access through the proxy, and blocking advertising or malicious domains according to rules. Rules may be based on domain suffixes, full domains, IP ranges, process names, or rule sets; the exact capabilities depend on the client and platform.
Rules are usually matched in order. More specific rules should come before broader ones, while traffic that matches nothing is handled by the fallback rule. For example, once a domain matches an earlier direct-connection rule, a later proxy rule will not apply. If a website does not use the expected node, check the matched rule in the connection log instead of repeatedly switching nodes.
Direct mode: Bypass proxy nodes
Direct mode is commonly used to pause proxying, compare local network performance, or access LAN devices. In some clients, “Turn off system proxy” only stops handling apps that follow the system proxy; an enabled TUN mode may still process traffic. When pausing a connection, check the client status rather than only the system proxy switch.
| Use case | Recommended mode | Reason |
|---|---|---|
| Everyday browsing and office work | Rule mode | Reduces unnecessary detours while retaining proxy access for target websites |
| Checking whether a website was missed by the rules | Temporary global mode | Quickly distinguishes a rule problem from a node problem |
| Accessing a router or LAN device | Direct connection or LAN bypass rules | Prevents local addresses from being sent to a remote node |
| Allowing only selected apps to use the proxy | Application-based split tunneling | Controls the proxy scope but requires client and platform support |
System proxy, TUN, and application split tunneling
A system proxy is a proxy setting provided by the operating system for apps to read. Browsers and some desktop software follow it, but certain games, command-line tools, or apps that create their own network connections may ignore it. As a result, the browser may work while other apps still connect directly.
TUN mode uses a virtual network interface to take over a broader range of IP traffic, then lets the client decide whether it should use the proxy or connect directly. It works better for apps that do not read system proxy settings, but usually requires additional system permissions and is more likely to conflict with other networking tools, firewalls, virtual machines, or enterprise security software.
Application split tunneling determines the destination by process or app. Mobile platforms commonly offer “Proxy selected apps only” or “Bypass selected apps,” while desktop clients may provide process rules. If an app update changes the executable path, an old rule may no longer match, so check the actual process name when troubleshooting.
- ✅ If the browser works but a game does not, check whether the game ignores the system proxy.
- ✅ If LAN access fails after enabling TUN, check LAN bypass and routing rules.
- ✅ If application split tunneling fails, verify the process name and the client’s permissions.
- ❌ Do not let the system proxy, TUN, and other networking tools take over the same traffic at once and then diagnose the failure by guesswork.
Why DNS leaks and split tunneling are connected
Before accessing a domain, a device usually uses DNS to resolve it to an IP address. If web traffic goes through the proxy but DNS requests still go to an unexpected local resolver, the domain lookup activity may be exposed and the returned address may not match the proxy exit location. This is commonly called a DNS leak or an inconsistent DNS path.
When rule-based routing depends on domains, the client needs domain information at the right stage. If an app resolves the domain early and passes only an IP address to the client, domain-only rules may not match. If DNS returns a region-dependent address, a content delivery network may also choose an unsuitable entry point. Modern clients therefore often handle DNS, rule matching, and proxy connections as one configuration.
Common troubleshooting sequence
- Confirm that the client’s DNS module is enabled and check the current resolution method.
- Confirm that the browser’s own encrypted DNS setting is not bypassing the client configuration.
- Check whether the target domain matched a direct, proxy, or fallback rule.
- Clear the operating system and browser DNS caches, then test again.
- On a network testing page, compare the exit IP and DNS resolver with what the current mode is expected to produce.
Do not judge DNS test results only by the resolver name. Some public resolvers use global routing, so the displayed location may differ from the actual network path. More importantly, confirm that requests are being handled by the client as expected, that no local carrier resolver appears, and that changing modes produces a reasonable change in results.
Client differences across platforms
The same subscription may be displayed differently and offer different capabilities across platforms. The subscription itself usually has not changed; the differences come from operating-system permissions, the client core, and the way network traffic is intercepted.
Windows
Windows clients commonly provide both a system proxy and TUN. A system proxy suits browsers and software that follows system settings; games, Store apps, or some command-line programs may require TUN. When TUN is enabled, the client may request administrator privileges to create a virtual network adapter and add routes.
macOS
On macOS, the system proxy likewise does not cover every app. When using a network extension or virtual interface, the system asks the user for authorization. If the connection behaves unexpectedly after a client update, check whether the network extension permission is still valid and whether other VPN configurations remain on the system.
Android
Android clients usually take over traffic through the system VPN interface and may provide per-app split tunneling. The system generally allows only one active VPN channel at a time, so other firewall, ad-blocking, or enterprise-network apps may replace or conflict with the proxy client.
iOS and iPadOS
iOS and iPadOS clients rely on the network extension capabilities provided by the system. Protocol cores supported by different clients are not identical. If an import succeeds but a node will not start, first check whether its protocol and transport method are supported. The system’s per-app controls also depend on the app’s capabilities and device-management policies.
Troubleshoot connection failures by layer
Effective troubleshooting is not about clicking through multiple nodes in succession; it is about identifying the layer where the failure occurs. Check the local network first, then the subscription and node, followed by the protocol connection, and finally the rules and DNS. Change only one variable at a time so you can tell which adjustment made a difference.
- ✅ Local network layer: Turn off the proxy and confirm that ordinary websites load normally.
- ✅ Subscription layer: Update the subscription and check that it returns nodes rather than a login page or error text.
- ✅ Node layer: Compare with another available node from the same subscription.
- ✅ Protocol layer: Check the log for timeout, certificate, authentication, UDP, or unsupported-parameter messages.
- ✅ Interception layer: Confirm that the system proxy or TUN is enabled as expected and that no other tool is conflicting with it.
- ✅ Rule layer: Check which rule and proxy group matched the target connection.
- ✅ DNS layer: Check the resolution path, caches, and the browser’s independent settings.
- ❌ Do not change the node, protocol, DNS, and running mode at the same time, or you will not be able to identify the cause.
“Timeout” in a log only means that the connection did not complete within the allowed time; by itself, it does not identify whether the server, route, or local network is at fault. “Authentication failed” points more toward credentials or the system clock. “Certificate name mismatch” usually calls for checking the domain, TLS configuration, and system time. “Unsupported protocol or transport” means you should check the client core version.
Once you understand these layers, the terms on a settings page fit together: the subscription provides configuration, the node provides the connection target, the route affects how that target is reached, the protocol defines communication, the system proxy or TUN intercepts traffic, rule mode determines where requests go, and DNS participates in domain resolution and routing decisions. You do not need to chase the longest feature list; the practical standard is stable compatibility with your platform and network environment.