When you first start using a VPN, the most confusing part is often not the buttons but the terms: subscriptions, nodes, routes, protocols, and split tunneling. Each belongs to a different stage of the connection flow. A subscription delivers configuration, a node provides a connection endpoint, the route determines how traffic travels across the network, the protocol defines communication between the client and server, and split-tunneling rules decide which requests use that route. Once this complete path is clear, most client settings stop feeling disconnected.
This guide follows a real connection from start to finish, explaining how these concepts relate and what direct connections, relays, IEPL private lines, global mode, rule mode, system proxy, TUN mode, and DNS leaks mean. The goal is not to memorize abbreviations, but to know where to look when something goes wrong.
The complete connection flow
After opening the client and importing a subscription, the client reads settings such as the server address, port, protocol parameters, and node name. Once you select a node and connect, requests from your apps are handed to the client. Based on the current split-tunneling mode, the client decides whether to send each request directly or encapsulate it and pass it to the remote node. The remote node then accesses the destination service and returns the response through the connection.
App request
→ System proxy or TUN takes over
→ Split-tunneling rule check
→ Direct connection or selected node
→ Network route used by the node
→ Destination service
→ Response returns along the same pathIn this flow, “node” and “route” are not synonyms. A node is usually a connection profile the client can select, containing details such as a host, port, and protocol. A route describes the network path behind that node. One region may offer multiple route types, while one route may have several entry profiles. A node name alone cannot reveal the complete path, so read the provider’s notes about route types and intended use cases as well.
What are subscriptions, configs, and nodes?
A subscription is an updateable configuration source
A subscription is usually provided as a link, though some clients retrieve it through an in-app login session. After accessing the subscription, the client receives a set of node profiles and related parameters. When the service updates node addresses, route names, or available configurations, you can select “Update subscription” in the client instead of entering every field again.
A subscription link is not an ordinary public webpage URL. It may contain credentials that identify your subscription, so protect it like a password and never post it on a public page, in a screenshot, or in a shared document. If you suspect the link has been exposed, regenerate it through the service panel or contact support.
Also distinguish between “local configs” and “subscription configs” in the client. Nodes you create manually are usually stored only on your device, while nodes received from a subscription are maintained by the subscription source. Some clients overwrite local changes to subscription nodes during an update, so avoid storing long-term custom parameters directly in those nodes. When adjustments are necessary, use the client’s override, rule-set, or separate-config features.
A node is a set of connection parameters
At minimum, a node must tell the client where to connect and how to communicate. Required fields vary by protocol and commonly include the server address, server port, authentication details, transport method, TLS settings, and server name. The client combines these fields into selectable profiles and uses region or route names to help identify them.
The region shown for a node usually describes its egress location or route label, but the region an app ultimately detects can also be affected by the egress IP database, DNS results, browser storage, account details, and system time zone. A node name therefore cannot prove a region by itself. To verify the egress, use IP Check after connecting and review the public address and DNS results.
Updating a subscription is not the same as upgrading the client
“Update subscription” retrieves configuration such as nodes and rules again, while “upgrade client” installs a newer version of the application. If a subscription contains a protocol the client cannot recognize, refreshing the subscription will not help. Check whether the current client supports that protocol and its transport parameters. Conversely, a client that launches successfully does not mean the subscription data is up to date.
Direct connections, relays, and IEPL private lines
A route type describes the path data takes from the local network to the egress node. It affects how much the connection depends on public-network congestion, inter-network peering, and route changes, but its name cannot predict performance at every hour. Evaluate a route using the local network, destination region, and actual time of use.
| Route type | Typical path | Key characteristics | What to evaluate |
|---|---|---|---|
| Direct | The local network connects directly to the remote node | Simple structure; performance depends more on public routing | Peering quality between the local carrier and the destination region |
| Relay | Traffic reaches a relay entry point before moving to the egress | Can avoid some unfavorable public-network segments | Entry quality, the relay path, and egress status |
| IEPL private line | Connected through an international Ethernet private line or equivalent transport path | Uses a different routing structure from a standard public-network direct connection | The provider’s stated entry point, egress, and supported scope |
“Direct” does not mean that a local app bypasses the proxy. In the context of node routes, it usually means the user connects directly to a remote server. In split-tunneling rules, however, “DIRECT” means the request does not pass through a proxy node. The two terms may look identical in the interface, but they refer to different layers. When reading client logs, first determine whether the entry describes a node path or a rule action.
A relay route adds one or more controlled forwarding steps. Its purpose is to reorganize the path between the entry and egress, not simply to make data “take one extra hop.” If the local connection to the relay entry is stable and the network between the entry and egress is strong, a relay may be better for sustained transfers than a public-network direct connection. If the entry is a poor fit for the current network, the result may be the opposite.
IEPL stands for International Ethernet Private Line and usually refers to an international Ethernet private line. It describes network transport and route organization, not a proxy protocol or a special button the client must support. The client may still use protocols such as Shadowsocks, Trojan, or VLESS to connect to the entry point, after which the traffic is carried by the provider’s network. When you see an “IEPL node,” understand it as a node using that route type—not as an encryption protocol called IEPL.
What common protocols are designed to do
A protocol defines how the client and server establish a session, authenticate, encrypt, or carry data. Both sides must support the same protocol and compatible parameters, or the connection cannot be established. The protocol name alone is not a complete configuration: the transport layer, TLS, server name, and other extension parameters can all affect compatibility.
Shadowsocks
Shadowsocks is a widely used encrypted proxy protocol. Its configuration typically centers on the server, port, password, and encryption method. Supported encryption methods vary between implementations. If an imported profile reports an unsupported encryption method, first check the client version and core implementation rather than repeatedly changing split-tunneling modes.
VMess and VLESS
VMess is a proxy protocol with identity fields and a defined protocol structure, often combined with different transport methods. VLESS has a lighter design and does not provide complete transport encryption by itself; deployments commonly pair it with TLS or another secure transport layer. The names are similar, but their configuration fields and server implementations are not interchangeable.
If a node appears after importing a subscription but cannot connect, check whether the client read the transport method, TLS settings, server name, path, and other parameters in full. Copying only the server address and port is often not enough to reproduce the original configuration.
Trojan
Trojan typically runs over a TLS connection, making authentication details, the server name, and certificate verification key settings. A significantly incorrect system clock, an incorrect server name, or failed certificate validation can prevent the handshake from completing. Permanently disabling certificate verification for troubleshooting is not appropriate; correct the time, domain, or configuration source instead.
Hysteria2 and TUIC
Hysteria2 and TUIC both focus on modern UDP-based transport and are often used on networks with packet loss or instability. They depend on normal UDP support from the local network, routing equipment, and server. If TCP-based protocols in the same subscription connect while both of these protocols continue to fail, check whether the current network restricts UDP, whether the client core is compatible, and whether the system firewall allows the relevant application to communicate.
There is no need to chase the newest abbreviation when choosing a protocol. Client compatibility, route fit, and current network conditions matter more than the name itself. When the provider supplies parameters through a subscription, start with the original configuration and avoid changing transport or security options without understanding them.
System proxy, TUN, and in-app proxies
A successful node connection only confirms that a channel between the client and server has been established. You must also decide how app traffic enters the client. Common takeover methods include the system proxy, TUN mode, and proxy settings built into the app itself.
System proxy
A system proxy writes the proxy address into the operating system’s network settings. Browsers and apps that follow those settings send requests to the client, but some programs ignore the system proxy and open network connections directly. As a result, a browser’s egress may change while a command-line tool or specific app continues using the local network.
TUN mode
TUN mode uses a virtual network interface to take over more types of IP traffic. Its coverage is usually broader than a system proxy, making it useful for apps that do not read system proxy settings. Enabling it may require system permission and can conflict with other network filters, enterprise security software, or existing virtual network interfaces.
TUN does not mean every request must pass through a remote node. After traffic enters TUN, rules can still choose between a proxy and a direct connection. “Traffic takeover” and “split-tunneling policy” are therefore separate dimensions: the former determines which traffic the client can see, while the latter determines how that traffic is handled.
In-app proxy
Some browsers, download tools, and developer tools let you enter an HTTP or SOCKS proxy separately. This has a clearly defined scope and is useful for testing a specific app, but make sure the address is the client’s local listening address—not remote node parameters pasted into an incompatible proxy field. These settings also do not automatically follow changes in the client’s status after the app exits.
Global, rule-based, and direct modes
The split-tunneling mode determines what happens next to requests already taken over by the client. Names vary slightly between clients, but the core choices usually fall into global, rule-based, and direct modes.
- Global mode: Most intercepted requests are sent through the selected node. This is useful for verifying that the node works and for ruling out rule-matching problems.
- Rule mode: Domains, IP addresses, apps, or rule sets determine whether traffic uses the proxy, connects directly, or is rejected. This is the more common choice for everyday use.
- Direct mode: Intercepted requests are still sent directly through the local network. It is commonly used to temporarily disable the proxy path or test the local connection.
Rules are usually matched in the order defined by the client. Common conditions include full domains, domain suffixes, IP ranges, process names, and geographic database categories. Once a rule matches, its corresponding action runs; otherwise, the final rule is used. If a website does not use the selected node, check the connection log to see which rule matched the request instead of looking only at whether the main interface says Connected.
Domain rules and IP rules can also produce different results. An app may request a domain first, allowing the client to split traffic by domain. If the app resolves the domain itself and submits only an IP address, the domain may be invisible, leaving IP rules or sniffing as the only options. Sniffing changes how the client identifies traffic, so configure it according to the client’s documentation rather than treating it as a universal fix.
The most effective way to troubleshoot split tunneling is to switch temporarily to global mode for comparison. If global mode works but rule mode does not, the issue is usually in rule matching, DNS resolution, or app takeover. If neither mode works, return to the node connection and local-network layers.
DNS resolution and DNS leaks
DNS converts domain names into IP addresses that can be reached. An established proxy connection does not guarantee that DNS requests follow the same path. System resolution, the client’s built-in DNS, encrypted DNS in the browser, and app-specific resolution may all coexist, making DNS an often-overlooked layer when troubleshooting split tunneling.
A DNS leak generally means that queries which should be handled by the proxy side or a specified resolver are still being sent to the local network’s DNS service. This may reveal the range of domains being queried or produce inconsistent region detection. When checking, do not look only at the public egress IP; also verify whether the DNS resolver locations shown on the test page match the expected configuration.
Rule mode depends heavily on DNS design. A client may match rules by domain first and then choose local or remote resolution, or it may use a virtual-IP mechanism to preserve the mapping between a domain and its connection. Implementations differ, so do not copy another app’s DNS settings unchanged. If a domain stops opening while its IP remains reachable, check resolver reachability, whether a rule sends DNS requests along the wrong path, and whether the browser has enabled its own encrypted DNS.
Browser and system DNS caches can also retain old results. If content looks unchanged after switching routes, that does not necessarily mean the node change failed. Try a new private window, close and reopen the target app, and, if necessary, clear the DNS cache using the operating system’s standard method before checking the egress and DNS results again.
Client differences across platforms
A subscription can be used across platforms, but client capabilities are not identical. Differences usually come from operating-system network interfaces, background limits, proxy core versions, and each client’s feature design.
- Windows: Common clients usually support both the system proxy and TUN. When enabling TUN, pay attention to administrator permissions, the firewall, and other virtual network adapters.
- macOS: The system proxy works well for apps that follow system settings. Broader traffic takeover may use a network extension or TUN and will trigger system authorization.
- iOS: Clients establish connections through the network extension provided by the system. Background behavior, on-demand connections, and rule capabilities depend on the client implementation and system limits.
- Android: Clients generally use the system VPN interface to take over traffic and often support per-app routing. Battery-saving policies may affect the client’s ability to maintain a background connection.
- Linux: Distributions and desktop environments vary widely. You can use a graphical client, system proxy, TUN, or a command-line core, but you must verify permissions and DNS integration yourself.
When moving from one platform to another, import the subscription again instead of copying only the server and port from a screenshot. Also confirm that the new client supports the subscription’s protocols, transport methods, and rule format. If the service offers an official client, using a version that matches the subscription configuration usually reduces compatibility checks.
From subscription import to connection verification
Beginners can follow a fixed sequence, verifying one layer at a time. Even when a connection fails, this makes it easier to tell whether the problem is in the configuration, node, traffic takeover, split tunneling, or DNS.
- Get a trusted subscription.Copy the subscription from the service panel or obtain it by logging in within the client. Do not use public configurations from unknown sources.
- Choose a compatible client.Confirm that the client supports the protocols included in the subscription and permits the network access required by the system.
- Import and update the subscription.Check that node names appear. If the list is empty, troubleshoot subscription retrieval first.
- Select a node and connect.Review the client log to confirm a successful protocol handshake rather than relying only on the button color.
- Confirm the traffic takeover method.Enable the system proxy or TUN according to the app coverage you need, and avoid stacking multiple proxy settings whose purpose is unclear.
- Start with global mode.Confirm that the target request can pass through the node, then switch back to rule mode.
- Check the egress and DNS.Compare the public IP, egress region, and DNS results to determine whether traffic is being sent as expected.
- Restore everyday split tunneling.See which rule matches the target domain and adjust only the relevant rule when necessary instead of resetting all network settings.
Common mistakes and quick checks
The node says connected, but webpages will not open
“Connected” may only mean that the client completed its handshake with the node. Next, check whether the app is covered by the system proxy or TUN, whether a rule marked the request as direct, whether DNS can resolve the domain, and whether the browser uses its own proxy settings. Compare results in global mode and across different apps.
Changing protocols does not change the speed
Performance depends not only on the protocol but also on local access, route path, the destination service’s response, and current network congestion. If several protocols use the same entry and egress route, switching protocols alone may not change the main bottleneck. A more meaningful test compares different route types while keeping the testing time, destination, and app consistent.
Custom nodes disappeared after updating the subscription
This usually happens because the change was made to a subscription-managed config and was overwritten by the server version during the update. Put custom rules in the client’s override section or save them as a local config. Export a backup before making changes, and confirm that the exported content will not be shared publicly.
The egress region is correct, but a service still detects another region
Region detection may combine the egress IP, DNS, account details, browser cache, location permissions, and the system environment. Clear the old session and check DNS again before frequently switching between many nodes. If the destination service applies separate account-region rules, follow its public documentation; changing the network egress does not automatically change account attributes.
Rule mode works for only some apps
First determine whether the app that is not working has entered the client at all. A system proxy cannot cover every program, and TUN app-exclusion settings may skip specific processes. If the app has no connection records in the log, the issue is more likely at the takeover layer. If records exist but the action is Direct, inspect the rules.