Complete VPN Beginner's Guide: Subscriptions, Nodes, and Split Tunneling Explained

This VPN beginner's guide starts with the concepts most often confused: subscriptions, nodes, and split tunneling. When connecting to international routes for the first time, an app may show server names, protocols, proxy modes, rule updates, and DNS settings all at once. Treating these as unrelated switches makes it easy to keep changing settings after a failed connection without knowing which layer is actually responsible.

A more practical way to understand the process is to view the connection as a chain: the subscription delivers route details to the client, the node identifies a connection entry point, the protocol defines how the client communicates with it, the route carries traffic across networks, and split-tunneling rules decide which requests enter that path. Once this chain is clear, route selection and troubleshooting become much easier.

What subscriptions, clients, and nodes each do

A subscription link is a configuration list that can be updated

A subscription link is usually generated by the service dashboard. After the client accesses it, the client retrieves node names, server addresses, ports, protocol settings, and group information. It is more like a configuration endpoint than an ordinary web page meant to stay open in a browser. The client's “Update subscription” action simply reads the list again so added or removed routes, renamed entries, and changed parameters are reflected locally.

Subscription links often contain the identifying information needed to access configuration, so they should not be shared publicly or pasted into conversion pages of unknown origin. If a link is exposed, the safer response is to reset the subscription from the service dashboard rather than only deleting the old configuration in the client. Removing local data does not invalidate a link that has already been leaked.

The client reads configuration and handles network requests

A client is software installed on Windows, macOS, iOS, Android, or Linux. It parses subscription data, establishes an encrypted connection, and receives application traffic through a system proxy or virtual network interface. Protocol support, rule formats, and system permissions vary between clients. If the same subscription shows a different number of usable nodes on different platforms, that does not necessarily mean the subscription is damaged; a client may simply lack support for one of its transport methods.

A node is a selectable connection entry point

Nodes are usually displayed by region, city, or purpose, and correspond behind the scenes to a server address, protocol, and route parameters. Choosing a “Japan” node does not mean the data travels through Japan for the entire journey; it usually describes the exit location or the region defined by the service. The client first connects from the current network to the entry point, the server then forwards the request to the destination, and the destination usually sees the network address on the exit side.

How direct, relay, and IEPL routes differ

“Node region” tells you where the exit is, while “route type” tells you how the data gets there. These two dimensions are often mixed together. Nodes in the same region can use different paths and feel different in practice. When evaluating a route, look beyond the city in its name and consider the current access network, the destination's location, and the type of application.

A direct route does not mean there is no encryption, nor does it mean the device is exposed directly to the destination website. Here, “direct” mainly means that there is no additional relay between the client and the service entry point. A relay adds an access layer that forwards traffic to the exit. It may improve routing in some network environments, but it also adds path complexity, so no route type should be assumed to be faster in every situation.

IEPL commonly refers to international Ethernet private-line resources. Its key difference from ordinary public-Internet relays is how critical transmission segments are carried and managed, not that the node name sounds more premium. Local Wi-Fi, the access carrier, device performance, exit congestion, and destination-site limitations can still affect the user experience, so “dedicated route” should not be understood as a guarantee of consistently low latency in every scenario.

Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC

These names are often grouped together as “protocols,” but their design priorities differ. Some are closer to encrypted proxy protocols, some depend on transport and security-layer combinations from a particular ecosystem, and others are built on QUIC and UDP. Beginners usually do not need to change protocol parameters manually, but compatibility and network conditions can affect the result.

Shadowsocks

Shadowsocks is an encrypted proxy solution whose configuration typically includes a server, port, password, and encryption method. Its structure is relatively straightforward and client support is broad, but successful import depends on whether the client supports the encryption method and any extended parameters in the subscription. It is not by itself a complete solution that automatically takes over all system traffic; which apps use the proxy depends on whether the client uses a system proxy, virtual network interface, or in-app settings.

VMess and VLESS

VMess is common in the V2Ray ecosystem and includes parameters such as an identity and transport method. It is also relatively sensitive to device time accuracy. A significantly incorrect system clock can cause authentication failures. VLESS focuses on lean authentication and does not itself provide a complete transport-security layer; it is commonly combined with TLS, REALITY, or other transport settings. Copying only the server address while omitting security-layer and transport parameters will usually prevent a correct connection.

Trojan

Trojan typically uses TLS to establish a connection, with configuration covering the server name, certificate verification, and transport parameters. When a certificate error appears, disabling verification should not be treated as the standard fix. A better approach is to check the system clock, server name, configuration completeness, and whether the subscription is up to date. Certificate verification helps confirm connection identity, and bypassing it casually weakens that protection.

Hysteria2 and TUIC

Hysteria2 and TUIC are commonly used in QUIC-based connection schemes that rely on UDP, with one focus being networks that have high latency or packet loss. They are not faster on every network: if the public network restricts UDP, a router handles UDP sessions poorly, or the client version lacks support, the connection may fail outright. In that situation, switching to a compatible route based on TCP and TLS is often more effective than repeatedly changing unknown parameters.

Choosing global, direct, and rule modes

Proxy mode determines how the client handles a request after receiving it. Global, direct, and rule modes are common local traffic-routing strategies, not different subscription plans. When the node stays the same, changing the mode still changes which websites use international routes, so the current mode must be checked when one app works but another does not.

Global mode

Global mode generally sends most requests handled by the client through the current node. It is useful for temporarily testing whether a node can reach a target service and for checking whether a problem comes from rule matching. Long-term use may send local websites, LAN devices, or services that do not need international access along an unnecessary path. Global mode may not cover every type of traffic either; coverage depends on how the client takes control of connections.

Direct mode

Direct mode sends requests without using the selected node and is commonly used to pause proxying or test the original network. When the client shows “Connected” but the mode is still direct, the external address will not change to match the node. This is a common beginner mistake: the tunnel may already be established, but the rules explicitly require traffic to go directly, so the destination still uses the original network.

Rule mode

Rule mode decides where traffic goes based on domains, network addresses, application processes, or rule sets. It suits everyday use because local services can connect directly while requests needing international routes enter the proxy. The challenge is that rules can expire, matching order can conflict, and a new domain may not yet belong to an existing category.

Request enters the client
├─ LAN and local services → Direct
├─ Proxy rule matched → Select a node
├─ Blocking rule matched → Block the request
└─ No rule matched → Apply the default policy

Rules typically match from top to bottom or according to the priority defined by the engine; the exact behavior depends on the client implementation. Domain rules and network-address rules can also produce different results: an app may resolve a domain first and then connect to the resolved address. If the DNS resolution path and proxy rules do not align, a domain may appear to match a proxy rule while the actual connection takes another path.

Why DNS leaks, resolution failures, and split tunneling are connected

DNS resolves domain names to network addresses. After you enter a website name in a browser, the device typically sends a DNS query before connecting to the resolved address. If web traffic goes through a node while DNS queries are still handled by the local network, the observed resolution path may not match the proxy path. This is commonly called a DNS leak and can lead to incorrect region detection, unsuitable resolution results for the current exit, or rules that fail to match as expected.

Common DNS handling methods include using the system resolver, querying through the proxy channel, selecting a resolver by domain category, and using virtual addresses with a rule engine. Clients name these features differently, so labels such as “enhanced mode” are not enough to judge the result. A more reliable check is to identify who sends the DNS request, which path carries it, and whether the resulting connection remains controlled by the same rules.

• If a domain will not open after the connection is established, try accessing a known-reachable service directly to distinguish a resolution problem from a connection problem.
• If global mode works but rule mode does not, check whether the domain rule matches and whether the rule file has finished updating.
• If the browser has its own secure DNS enabled, resolution may bypass the client's intended settings. Check for conflicts between the browser and system configuration.
• If LAN devices are unreachable, confirm that the local subnet was not incorrectly sent through the proxy. Local resources should usually have direct-connection rules.
• If old resolution results remain after switching nodes, restart the affected app and, if necessary, clear the system or client DNS cache.

A DNS leak is not the only way to judge whether a webpage opens, and a single result from an external test page cannot reveal the path of all traffic. Modern browsers, operating systems, and apps may each use different resolution mechanisms. During troubleshooting, consider application DNS, system DNS, client DNS, and the exit connection as one chain.

How clients differ across platforms

The same subscription can behave differently across platforms. The usual causes are system network interfaces, background-execution limits, and client protocol support—not a special preference of the node for one device. When choosing a client, first confirm that it supports the protocols in the subscription, then consider rule editing, log access, and automatic updates.

Windows and macOS

Desktop systems generally offer two ways to take over traffic: a system proxy and a virtual network interface. A system proxy mainly affects apps that honor proxy settings; some games, terminal programs, and software with its own network stack may bypass it. A virtual network interface can cover more traffic, but may conflict with firewalls, virtual machines, enterprise networking software, or other network tools.

macOS apps may also use a system network extension to establish a tunnel, which requires the relevant permission the first time it is enabled. If the client reports a successful connection but terminal requests do not use the node, check whether the terminal tool reads proxy environment variables and whether the client is using a system proxy or a virtual network interface.

iOS and Android

Mobile operating systems usually take over traffic through the system-provided VPN interface. Background power saving, switching between Wi-Fi and cellular access, system restarts, and permission changes can all trigger a tunnel reconnection. Mobile clients also differ in subscription-format and protocol support, so a successful import does not mean every node type will work.

Android devices vary widely in system customization, and battery management may restrict client activity in the background. On iOS, clients are constrained by the system network-extension mechanism. If the connection drops after the screen locks, first check whether the system allows the client to keep network activity running before assuming a node failure.

Linux

Linux is commonly used through graphical clients, command-line cores, or service processes. A desktop environment's system proxy does not necessarily affect command-line tools. Command-line programs may need proxy environment variables or may require a virtual network interface for unified traffic handling. With a service process, also confirm that the configuration-file permissions, listening address, DNS settings, and routing rules are loaded by the correct user.

From importing a subscription to verifying the connection

Beginners often switch between several settings repeatedly. A more efficient approach is to work in dependency order and verify the result after each step. Even if the connection fails, this shows exactly where the problem stopped.

1. Choose a compatible client. Confirm that the client supports the protocols provided by the subscription and the current operating system; do not choose based only on its appearance.
2. Copy the subscription link. Obtain the link from the service dashboard and add it through the client's subscription-import feature. Avoid processing it with public conversion tools.
3. Update the subscription. Confirm that node names appear in the client. If the list is empty, check the update message and client logs instead of immediately switching proxy modes.
4. Choose the target region. Select an exit based on the location of the target website or service, then compare direct, relay, or dedicated routes in the same region.
5. Connect in rule mode first. If the target is unreachable, switch briefly to global mode for comparison and determine whether rule matching is the cause.
6. Verify the traffic path. Check that the external address matches the selected region, and test whether local websites and LAN resources still connect directly as expected.
7. Restore everyday settings. After testing, return to a rule mode suitable for long-term use and keep usable nodes available as alternatives.

How to troubleshoot common failures by layer

Subscription update fails

First confirm that the original network can reach the subscription endpoint. Then check whether the link is complete, has been reset, or was mistakenly added as a single-node configuration. If the client provides update logs, look for network timeouts, format-parsing errors, and authentication failures. Do not create multiple identically named subscriptions by repeatedly importing the same link; that makes the source of later nodes harder to identify.

No nodes can connect

When every node fails at once, first check the current network, client core, system time, firewall, and protocol support. If UDP-based options such as Hysteria2 and TUIC fail while other transports work, the current network may be restricting UDP. If Trojan or another TLS connection reports a certificate problem, verify the system time and subscription parameters instead of simply disabling verification.

Only one node fails

If one node fails while others in the same region work, switch routes first and update the subscription later. Similar node names do not mean identical paths. If a particular route remains problematic, send the client log and node name to service support so the entry point, exit, or transport parameters can be investigated.

Connected, but the app still uses a direct connection

Check whether direct mode is active, whether the app follows the system proxy, and whether the virtual network interface was established successfully. Terminal tools, games, and some desktop apps may not read the system proxy. Depending on the client's capabilities, use a virtual network interface or set an explicit proxy environment for the app instead of relying only on the client's connection icon.

Web pages work, but video or downloads fail

A working webpage only shows that a basic request was established; it does not prove that sustained transfers are stable. Video, downloads, and real-time communication are more sensitive to throughput, jitter, packet loss, and long-lived connections. Compare route types in the same exit region and temporarily stop bandwidth-heavy background tasks. If only one service is affected, also check that its split-tunneling domains are complete and that the exit region meets the service's own requirements.

Build configuration habits for everyday use

Stable use does not depend on constantly changing advanced parameters. More important factors are keeping the subscription up to date, maintaining client and protocol compatibility, using clearly sourced rules, and keeping alternative routes for frequently used regions. When a node briefly fluctuates, switch to another route in the same region. If the entire subscription fails, then check the local network and client instead of turning a single-node issue into a full reinstall.

Split-tunneling rules should also remain explainable. Knowing why local services connect directly, why international websites use the proxy, and what default policy handles unmatched requests is more reliable than stacking rules from many unknown sources. For work systems, online banking, or region-sensitive services, follow the applicable terms and local requirements, and confirm the exit region and network environment before handling important accounts.

Once the relationship is clear—“the subscription provides configuration, the client executes the connection, the node represents the entry point, the route carries the traffic, the protocol defines communication, and split tunneling determines where it goes”—the terms in the interface are no longer isolated switches. Route selection becomes evidence-based, and connection failures can be located layer by layer instead of guessed through trial and error.