VPN Basics: Subscriptions, Nodes, Protocols and Split Tunneling Explained

When you first use a VPN, the hardest part is often not finding the right button, but understanding how subscriptions, nodes, protocols, routes and split tunneling fit together. They all relate to a “connection,” but they serve different roles: a subscription delivers configuration to the client, a node is the specific connection target, a protocol defines how the client and server communicate, a route describes the network path data takes, and split tunneling determines which requests the proxy handles.

Once these concepts are separated into layers, many problems become easier to isolate. A failed subscription import does not mean the route is unavailable; a node that connects but cannot open webpages is not necessarily suffering from a protocol issue; and when an app fails in rule mode, traffic may not be under the client’s control or DNS may be taking the wrong path. The sections below explain each term in practical order and provide actionable ways to diagnose issues.

How subscriptions, nodes and clients work together

A client is software installed on your device. It reads configuration, establishes connections, applies split-tunneling rules and sends matching traffic through the appropriate node. A subscription is usually a link containing access credentials. After requesting that link, the client receives a node list and may also receive names, protocols, ports, transport methods and rule information. A subscription is not a node, and it is not a continuously running network tunnel.

Think of a subscription as an updateable configuration list. When a provider changes routes, adds entry points or modifies parameters, the client can retrieve the latest list through “Update subscription.” Importing a subscription once does not mean your local node information will stay current forever; automatic updates and their timing depend on the client’s settings.

A node is a specific connection target in that list. A node configuration usually needs at least a server address, port, protocol and authentication credentials. Some protocols also require transport-layer, TLS, server-name or path parameters. A node name is only a label for identification. A name mentioning a region, dedicated route or streaming service cannot replace an actual connection test.

A subscription link usually contains a token used to identify your account or plan, so treat it like a credential. Do not include the full link in public screenshots, forum posts or shared documents. When moving to another device, retrieve it again from a trusted user panel. If you suspect the link has been exposed, use the reset method provided by the service provider instead of only deleting the local client.

Standard subscription import workflow

1. Copy the complete subscription link from the service dashboard. Make sure there are no extra spaces at either end and that the link was not truncated by a chat app.
2. In a client that supports the subscription format, choose “Import from URL” or an equivalent option. Do not select “Add a single node manually” by mistake.
3. After importing, run a subscription update once and check whether a node list appears. Only a visible list confirms that the client successfully parsed the configuration.
4. Choose a nearby node or one that matches your intended use, then enable system proxy or tunnel mode. Selecting a node without starting the connection does not send system traffic through it automatically.
5. Open a webpage and check real connectivity. A client showing “Connected” usually only means that the local tunnel has been established; verify the exit address, DNS and app access with actual requests.

What proxy protocols do: Shadowsocks, VMess, Trojan, VLESS, Hysteria2 and TUIC

A protocol defines how the client and server authenticate, encapsulate and transmit data. It affects the handshake, transport layer, software compatibility and behavior under different network conditions, but the protocol name alone does not determine speed. Server load, entry quality, cross-border paths, congestion and the local network matter too. Check client support first, then consider whether the current network restricts TCP, UDP or TLS.

Shadowsocks

Shadowsocks is a lightweight encrypted proxy protocol. Its core settings typically include a server, port, password and encryption method. It is widely supported and relatively straightforward, making it suitable for general web, app and streaming traffic. It is not a traditional enterprise VPN protocol; whether it can capture traffic from the entire device depends on whether the client provides system proxy, a VPN interface or TUN mode.

VMess and VLESS

VMess is a common protocol in the V2Ray ecosystem, with configuration that may also include an identity, transport method and security parameters. VLESS has a more streamlined design and does not provide content encryption by itself; it is usually combined with TLS, REALITY or another secure transport. Seeing “VLESS” alone does not confirm that a connection is fully configured—you must also check the transport layer, security layer, server name and client core support for that combination.

These two configuration types require careful parameter matching. The address and port may look correct, yet a mismatched transport method, TLS setting or server name can still cause the handshake to fail. When entering settings manually, compare every field rather than copying only the most prominent server address.

Trojan

Trojan typically runs over TLS, making authentication details, the server name and certificate validation key configuration points. A badly misaligned client clock, an incorrect server name or a failed certificate-chain check can terminate the connection during the handshake. Disabling certificate validation may make an error disappear temporarily, but it weakens authentication and should not be a routine troubleshooting step.

Hysteria2 and TUIC

Hysteria2 and TUIC both rely heavily on QUIC and UDP, with transport scheduling designed for high-latency, lossy or unstable links. That does not make them faster on every network. If the current Wi-Fi, corporate network or carrier path heavily restricts UDP, you may see handshake failures, unstable speeds or complete unavailability. In that situation, compare a working TCP or TLS option instead of repeatedly changing unrelated parameters.

Where direct connections, relays and IEPL dedicated lines differ

Protocols answer “how data travels”; routes answer “where it travels.” The same protocol can run over different routes, and one route can carry different protocols. Comparing only protocol names while ignoring the path rarely produces a stable conclusion.

A direct connection usually means the device reaches the remote node entry point without a provider-managed relay in between. The structure is simple and has fewer extra stages, but cross-region performance depends more heavily on the local carrier and public routing. Detours or congestion can cause an unstable experience even when the remote server has sufficient resources.

A relay route first connects to a nearby entry server, which then forwards traffic to the target exit. This can avoid some poor-quality public routes and gives the provider more flexibility when adjusting the path between entry and exit. However, the relay’s capacity, entry distance and forwarding path all affect the result; “relay” describes topology, not guaranteed speed.

IEPL is an industry term for international Ethernet private-line services, commonly used for enterprise network interconnection. When a consumer network acceleration service labels a route “IEPL dedicated line,” it usually indicates that part of the backbone path uses private-line resources or access. You still reach the entry point through the local internet, and the exit must still access the target website, so it should not be understood as a completely private path from your device to every destination.

• ✅ Check the entry location: if it is too far from the access point, the local segment can still be the bottleneck.
• ✅ Check the path structure: distinguish direct connections, regular public-internet relays and relays carried over dedicated lines.
• ✅ Check the intended use: webpages, file transfers and real-time communications place different demands on a route.
• ✅ Check busy periods: a brief speed test during a quiet period cannot represent long-session stability.
• ❌ Do not rely only on node names: labels help with classification but cannot replace route and real-transfer tests.
• ❌ Do not rely only on latency rankings: low latency does not mean high throughput or guarantee no packet loss.

“Latency tests” in clients also require context. Some only check TCP establishment, some request a specific webpage, and others measure only the response from your device to the entry point. Test figures can quickly rule out completely unreachable nodes, but they do not fully represent download bandwidth, video buffering or long-connection stability. A reliable approach is to narrow the choices with latency, then validate them with real workloads.

How to choose between global mode, rule mode and direct mode

Modes determine which traffic enters a node. Global mode generally sends all traffic the client can capture through the current node, making it useful for troubleshooting rules or briefly checking whether an app works through the proxy. It does not necessarily mean every packet on the device is captured: if the client only sets a system proxy, apps that ignore system proxy settings may still connect directly.

Rule mode decides whether traffic is proxied, sent directly or rejected according to domains, IPs, apps or rule sets. It is usually better for everyday use because local services can stay direct while cross-border access uses international routes. Rules must match real requests continuously; changing domains, app-specific DNS, direct IP connections or incorrect rule order can all cause misrouting.

Direct mode generally bypasses the node and is useful for temporarily pausing the proxy or checking whether the proxy path is causing a problem. Some clients also offer “Global direct” and “Disconnect.” The former may still let the client capture traffic and apply a direct policy, while the latter stops the local proxy service entirely. Their handling of DNS and the TUN interface may differ.

System proxy and TUN mode are not the same

A system proxy writes an HTTP or SOCKS proxy address into the operating system. Browsers and apps that follow this setting send requests to the client. It has low overhead and is convenient to toggle, but some games, command-line tools, store apps and software using custom network stacks may ignore system proxy settings.

TUN mode captures IP traffic through a virtual network interface, then lets the client decide whether to proxy or connect directly. It usually covers more apps and is better suited to scenarios requiring UDP, but it needs additional system permissions and may conflict with other VPNs, virtual-machine networks, endpoint security software or local firewalls. On mobile platforms, clients typically use the system-provided VPN interface for similar traffic capture, so the status bar may show a VPN indicator even when the underlying protocol is a proxy protocol.

Why DNS leaks, domain resolution and split tunneling are connected

Before a browser accesses a domain, it usually resolves that domain to an IP address. Who handles DNS requests affects privacy, connectivity and routing accuracy. If web traffic goes through a node while DNS is sent directly to the local network, the resolver can still see the domains being queried. This situation is commonly called a DNS leak.

DNS issues are not only about privacy. Rules may route traffic by domain, but if an app resolves names outside the client, the proxy may see only an IP address. Conversely, if every domain is resolved by remote DNS, local services may return addresses unsuitable for your location. Mature split-tunneling configurations usually distinguish local domains from those requiring remote resolution and keep DNS results consistent with subsequent routing.

In clients, “DNS hijacking” or “DNS interception” usually means redirecting the device’s DNS requests to the resolver configured by the client. “Hijacking” here is a technical feature name and does not necessarily imply malicious behavior. After enabling it, confirm that the client supports the protocol in use and avoid overlapping control with encrypted DNS built into the browser or other network-filtering tools.

How split-tunneling rules usually match traffic

Domain rules work well for categorizing websites and services, IP rules for known address ranges, and app rules for separating traffic by process or package. Rules generally have an order of priority: more specific matches should come before broad rules, with a default rule handling anything unmatched. Clients do not all implement rule syntax and priority in the same way, so check the client’s documentation when migrating configurations rather than assuming a rule file is universally compatible.

If a website loads its homepage but images, sign-in or video fail, it may depend on multiple domains while the rules cover only the main domain. Temporarily switch to global mode for comparison. If global mode works, the node and protocol are probably usable; next inspect resource domains, DNS resolution and rule matches.

Why clients work differently across platforms

Windows and macOS clients usually offer both system proxy and TUN options. System proxy suits browsers and software that follows proxy settings, while TUN is better for apps that do not. Enabling TUN may require a virtual network component or administrator permission. If the client exits without restoring the system proxy, the network may appear disconnected; check the operating system’s proxy settings before reinstalling the software.

Android clients typically use the system VPN interface to capture traffic, and the first activation displays a system authorization prompt. Some clients support per-app routing, allowing you to choose which apps use a node. If always-on VPN or another network-filtering service is also enabled, check whether the system allows them to coexist.

Clients on iOS and iPadOS use the system-provided Network Extension capability. After importing a subscription, the first connection requires permission to add a VPN configuration. Protocol cores vary between clients, so the same subscription may show all nodes in one client but omit some protocols in another. When this happens, check the software version and protocol support instead of repeatedly deleting the subscription.

A proxy on a router provides gateway-level traffic capture. Devices connected to that router can share unified rules, but the router’s processor, firmware core, DNS configuration and hardware acceleration all affect throughput. Whether a router can import a subscription also depends on the formats and protocols supported by its firmware plugin; a configuration that works in a desktop client may not work directly on a router.

• ✅ Windows or macOS: first confirm whether you are using system proxy or TUN, then determine which apps should be captured.
• ✅ Android: check system VPN authorization and per-app routing settings.
• ✅ iOS and iPadOS: confirm permission to add a VPN configuration and check the client’s supported protocols.
• ✅ Router: verify the firmware, plugin core, DNS and hardware capabilities.
• ❌ Running multiple traffic-capture tools at once: routes, DNS and virtual interfaces may override one another.

From “Can’t Connect” to the Root Cause: Troubleshooting Order

Effective troubleshooting depends on changing only one variable at a time. If you change the client, protocol, node and network simultaneously, even a successful recovery will not reveal the cause. Start with the local environment, then check the subscription, node, protocol, route and rules layer by layer.

1. Confirm that the device can directly open ordinary webpages, and verify the system date and time. Without a working basic network, the client cannot update the subscription or complete a protocol handshake.
2. Update the subscription and check whether the node list loads normally. If the subscription request fails, address the link, network access and client-format compatibility first.
3. Choose another node using the same protocol for comparison. If only one node fails, the issue is more likely to be with that node or its route.
4. Try another protocol supported by the client. If a UDP-based protocol fails while a TCP or TLS option works, check whether the current network restricts UDP.
5. Temporarily use global mode for comparison. If global mode works but rule mode does not, focus on rule matches, resource domains and DNS.
6. If only some apps work under system proxy, confirm whether those apps follow system proxy settings. If necessary, test with TUN or the system VPN interface.
7. Close other tools that may capture network traffic, check for conflicts involving the firewall, virtual adapters and local proxy ports, then establish the connection again.

When reading client logs, classify errors by stage: parsing, connection, handshake, authentication, DNS and routing. A subscription format error occurs during parsing; a connection timeout may indicate an unreachable address or restricted port; a TLS certificate error belongs to the handshake stage; authentication failures usually involve mismatched credentials or configuration; if the connection succeeds but domains do not open, focus on DNS and routing.

Logs may contain server addresses, subscription identifiers or connection credentials. Redact sensitive fields before submitting a ticket or screenshot. When describing the issue, provide the operating system, client name, protocol, capture mode, failure stage and comparison tests already completed. This is far more useful than simply saying “it doesn’t work.”

Putting these VPN terms into one real connection

A complete connection works like this: the user imports a subscription link into the client, which parses multiple node configurations. The user selects one node, and the client establishes a connection using the specified Shadowsocks, VMess, Trojan, VLESS, Hysteria2 or TUIC protocol. The connection reaches the exit through a direct, relay or dedicated-line route; system proxy or TUN captures device traffic; rule mode decides whether each request is proxied or direct; and DNS settings keep domain resolution consistent with routing.

An issue at any layer may appear as “the webpage won’t open,” but the solution can be completely different. An expired subscription requires updated configuration; an incompatible protocol requires a different client or core; route congestion requires a different entry path; an inactive system proxy requires a different capture method; a missing rule requires adding the domain; and inconsistent DNS paths require checking resolution settings.

Beginners do not need to memorize every configuration field at once. Start with the layers: the subscription is the configuration source, the node is the connection target, the protocol is the communication method, the route is the transport path, the mode defines the traffic scope, rules determine the destination path, and DNS resolves domain names. When reading any tutorial, first identify which layer it addresses, then decide whether it applies to your device and client.