VPN Terms Explained: Subscriptions, Nodes, Routes, Protocols and Traffic Rules

When you first open a client, the most confusing part is often not the buttons but terms such as VPN subscription, node, route, protocol and traffic rules. They belong to different layers: a subscription delivers configuration, a node is a connection endpoint, a route describes the network path, a protocol defines how the client and server communicate, and traffic rules decide which requests use that path. Once these layers are separated, most client settings become much easier to understand.

The term “VPN client” is also sometimes used for software that manages proxy protocols, so VPN in the interface does not always mean a traditional tunneling protocol. When judging what an option does, focus less on whether its name is technically precise and more on whether it handles configuration, connection, transport or traffic selection. The sections below follow that order.

What are subscriptions, nodes and routes?

A subscription is a configuration list that keeps updating. After importing a subscription link into a compatible client, the client reads node names, server addresses, protocol parameters and authentication details. When the provider changes a node, you usually only need to refresh the subscription instead of entering every field again.

A subscription link may contain access credentials, so treat it like an account key. Do not paste it into forums, screenshots or shared documents, and do not import it into online conversion tools from unknown sources. When moving to another client, use a trusted device whenever possible, or retrieve the link again from the service panel.

A node is a selectable connection profile in the client. Node names often include a region, city or route label, but the name is only an identifier; the actual connection depends on the server address, protocol and authentication parameters. Multiple nodes can exist in the same region, using different entry points, exits or transport paths.

A route describes the network path between your local network and the exit. The node is what you choose in the client; the route explains how that node gets there. More nodes do not automatically mean better paths. To assess performance, also consider the destination region, local carrier network, cross-border links and evening congestion.

Term	Layer	Primary role	Common actions
Subscription	Configuration delivery	Provides and updates connection profiles in one place	Import, refresh, migrate
Node	Connection endpoint	Specifies the region, server and protocol parameters	Select, switch, test
Route	Network path	Determines how data reaches the target exit	Compare by region and network conditions
Protocol	Communication rules	Defines encapsulation, authentication and transport	Check compatibility, troubleshoot faults
Traffic rules	Traffic decisions	Decides whether requests connect directly, use a proxy or are blocked	Choose a mode, maintain rules

Quick distinction: A subscription is not a node, and a node is not a route. The subscription contains configuration, the node is what the client selects, and the route is the actual path behind that node.

Direct, relay and IEPL routes: what is the difference?

A direct route usually means the client connects straight to an overseas server, with data traveling mainly over the public internet to the exit. Its structure is simple and has fewer hops, but performance depends more heavily on the local carrier network and public cross-border links. A direct route that performs well on one network may behave differently on another.

A relay route first connects to a nearby entry point, then uses a relay network to reach an overseas exit. The entry and exit can be optimized separately, and the provider can adjust the path more easily when congestion changes. The trade-off is more hops: instability in any relay segment can affect the connection overall.

An IEPL route generally describes an international Ethernet private-line connection. Its key difference from an ordinary public-internet connection is that the cross-border backbone segment uses dedicated transport rather than relying entirely on random public-internet routing. Note that an “IEPL node” does not mean every segment from your device to the destination website is off the public internet; local access and the final exit may still include public networks.

✅ When the local network is stable and the destination region is nearby, try a direct route first.
✅ When the public cross-border segment is unstable, compare relay and IEPL nodes.
✅ For content in a specific region, confirm the exit region first, then assess the route type.
❌ Do not judge real-world performance solely by words such as “high speed” in a node name.
❌ A successful connection in the client does not guarantee that the target website is reachable.

Shadowsocks, VMess, Trojan and VLESS: how to understand them

Shadowsocks is an encrypted proxy protocol with a relatively simple configuration and broad client support. It mainly handles application traffic and does not automatically take over every connection on the device. Whether it covers more programs depends on the client’s support for a system proxy, virtual network interface or relevant forwarding features.

VMess is common in the V2Ray ecosystem and includes authentication and transport settings. After import, a client may also show additional fields such as the transport layer, TLS and WebSocket. These must match the server configuration; do not change them simply because an option looks more advanced.

VLESS uses a more streamlined protocol design and is often combined with TLS, REALITY or other transports. VLESS and the transport carrying it are separate layers: the former handles protocol and identity, while the latter determines how data travels across the network. Troubleshoot them separately rather than looking only at whether “VLESS” is selected.

Trojan usually carries traffic over TLS and resembles a conventional encrypted connection. It still requires the correct certificate, domain and server configuration. TLS does not automatically improve route quality or eliminate every connection problem; it mainly provides transport encryption and authentication, while congestion belongs to another layer.

These protocols do not have a fixed ranking that works in every environment. Compatibility depends on the client implementation, while connection performance depends on the route, transport layer and current network. When a subscription already provides a working configuration, beginners generally do not need to edit protocol parameters manually—just confirm that the client supports the relevant type.

Protocol takeaway: Prefer configurations supplied by the subscription and fully supported by the client. A protocol name alone cannot predict speed; route quality and network conditions are often more decisive.

When are Hysteria2 and TUIC a good fit?

Hysteria2 and TUIC often use modern UDP-based transport capabilities and are designed with high latency, jitter or some packet loss in mind. They can reduce the delays caused by repeated waiting in traditional transports on unstable networks, provided the current network can carry UDP normally.

Some office, public or restricted networks limit UDP. In that case, the client may time out, fail the handshake or disconnect shortly after connecting. Do not immediately assume the node is offline. Compare it with a compatible TCP-and-TLS configuration. If the alternative protocol works, the issue is more likely related to the UDP path or its forwarding settings.

Neither protocol is an “instant speed boost.” Throughput is affected by server scheduling, local Wi-Fi, device performance and the destination site. On mobile devices, also consider background keep-alive and battery use; on desktops, confirm that the firewall allows the client to establish the required connections.

System proxy, TUN and virtual network interfaces: what is the difference?

A system proxy writes the proxy address into the operating system’s network settings. Browsers and applications that follow the system proxy are forwarded through the client, while programs that ignore it may continue connecting directly. It starts quickly and has an easy-to-understand scope, making it suitable for web browsing and common desktop software.

TUN mode usually uses a virtual network interface to take over a broader range of IP traffic, after which the client applies routing and traffic rules. It can cover programs that do not support a system proxy and is better suited to handling multiple applications consistently. However, it requires more from permissions, routing tables and DNS settings; after an abnormal exit, the client may need to restore the network configuration.

A virtual network interface is a system component that enables this kind of traffic capture, not a protocol itself. A client may place TUN, virtual interfaces and enhanced modes near one another because they all involve lower-level traffic handling. If you only need browser access, a system proxy is usually enough. Consider TUN when a game launcher, command-line tool or another application does not follow the system proxy.

Start with the system proxy to confirm that the node itself can connect.
Check whether your browser and everyday applications can access the network normally.
Enable TUN or a virtual network interface only when some programs are not being handled.
After enabling it, check local services, LAN devices and DNS resolution again.
If the network goes offline, exit the client first and let it restore the system network settings.

Global, rule-based and direct modes: how to choose

Global mode generally sends all traffic the client can take over through the current node. It is useful for testing: if a website fails in rule mode but works globally, the problem is often rule matching or DNS classification. Global mode does not mean every piece of device traffic is necessarily captured; the scope still depends on system proxy or TUN settings.

Rule mode determines where traffic goes based on domains, IPs, applications or rule sets. Common outcomes are proxy, direct connection and blocking. It is better suited to everyday use because local services and domestic resources can connect directly, while requests needing international routes use a node, avoiding unnecessary detours.

Direct mode generally means requests do not pass through a proxy node. It can temporarily disable forwarding or help troubleshoot the local network. A running client does not mean traffic is still going through a node, so check the current mode whenever you verify connection status.

“Bypass the LAN” means keeping local connections when accessing a router, printer or home storage device. If the rules are missing, LAN requests may be sent to a remote node and device discovery can fail. After a rule update causes problems, compare global and direct modes first, then check the priority of custom rules.

✅ For everyday browsing, use a rule mode that is properly maintained.
✅ When checking for a misclassified rule, briefly switch to global mode for comparison.
✅ Keep direct-connection rules for local subnets when accessing LAN devices.
❌ Do not permanently stack rule sets from unknown sources that conflict with one another.
❌ Do not repeatedly add rules for the same domain without understanding their priority.

DNS leaks and resolution paths: how to check them

DNS converts domain names into network addresses. After connecting to a node, if domain lookups still go directly to the local network’s resolver while web traffic uses a remote exit, the resolution and access paths no longer match. A DNS leak generally means that queries meant to be handled by the tunnel or proxy unexpectedly traveled through the local path.

DNS leaks affect availability as well as privacy. Content services may return different addresses based on the resolver’s location. When local resolution does not match the exit region, you may see redirects, incorrect regional detection or connections to a more distant server. Enabling the client’s remote DNS, encrypted DNS or TUN DNS handling can align resolution with traffic policy, although the exact names vary by client.

When troubleshooting, first check whether the browser has its own secure DNS enabled. The browser’s resolver may bypass the client or duplicate its handling. Then check whether other network tools are running on the system. When multiple tools compete for DNS or routing settings, a common symptom is that the connection succeeds but domains will not open, while a known address still responds.

The right way to import and update a subscription

Subscriptions are usually imported in one of two ways: read the link from the clipboard, or paste it into the client’s subscription manager and refresh. A successful import only means the client read the configuration; it does not verify that every node can connect. After importing, refresh the list, then choose a node near the target region and connect.

If the client says the subscription format is unsupported, common causes include a mismatch between the client and protocol type, an incomplete link, or an incorrect system clock causing secure-connection verification to fail. Do not submit the subscription to an arbitrary online conversion site. A safer approach is to use the client recommended by the service panel or convert the format locally with a trusted tool.

Copy the complete subscription link from the service panel and avoid displaying it in public.
Open subscription management in a compatible client instead of adding individual nodes manually.
Run an update after importing and confirm that the node list appears.
Choose a node in the target region, then check web access and DNS resolution after connecting.
When nodes change later, update the subscription first before deciding whether to reinstall.

“Subscription update failed” and “node connection failed” are separate issues. The first occurs while the client retrieves the configuration list; the second occurs while it uses one profile to establish a connection. If old nodes still connect but the subscription cannot update, the configuration-retrieval stage is at fault. If the subscription updates but every node fails, continue checking protocol compatibility, system time, network restrictions and client permissions.

Import takeaway: The subscription delivers configuration to the client; a connection test confirms whether a node works. Keeping these steps separate makes error messages much easier to understand.

How clients differ across platforms

Windows and macOS clients commonly offer system proxy, rule mode and TUN. On Windows, watch for security software and virtual-interface permissions; on macOS, you may need to approve a network extension. Desktop systems make logs easy to inspect, so when connections fail, use subscription updates, DNS, handshake and routing information to identify the stage of failure.

On iOS, network traffic handling is managed through the system VPN configuration, and the client must use the network-extension capabilities allowed by the system. After switching apps, rely on the system status bar and the client page for connection status. Android devices allow clients to create a local VPN interface, and some apps support per-app routing. However, background policies vary by device maker, so continuous connections may require the necessary background-running permission.

Linux clients commonly come in graphical and command-line forms. A graphical client is convenient for subscription management, while a command-line core suits servers and development environments but requires you to understand configuration files, service processes, routing and DNS. For everyday desktop access, prefer a graphical client that can restore network settings automatically.

A router setup differs from a single-device client. A router handles multiple devices passing through it, so a configuration error in rules or DNS affects a wider scope. Beginners should verify the subscription and nodes on a computer or mobile device first, then consider moving to a router rather than mixing client, route and home-network problems together.

Connection troubleshooting: which layer to check first

When you see “unable to connect,” the most effective approach is to troubleshoot layer by layer instead of switching every option at random. Confirm that the local network works, then confirm that the subscription updates, and only then check the node, protocol and system-level traffic handling. If the connection succeeds but the target website still will not open, move on to DNS, traffic rules and the target service status.

✅ In direct mode, confirm that the local network can access commonly used websites.
✅ Update the subscription to distinguish configuration-retrieval failure from node-connection failure.
✅ Keep the same region and switch to another compatible node for comparison.
✅ Check the system clock, client permissions and current proxy mode.
✅ After connecting, verify DNS, traffic rules and the target exit region.
❌ Do not change the protocol, node, DNS and rule mode at the same time.

Keywords in client logs can also help locate the problem. A resolution failure usually points to DNS or the server address; a handshake failure is more likely related to protocol parameters, certificates, the system clock or network blocking; a timeout may occur at the local firewall, a UDP restriction, a relay link or the remote service. Logs may contain server addresses and account credentials, so hide sensitive fields before submitting a support request.

Once these terms are clear, any client can be understood as the same workflow: the subscription delivers node configuration, the protocol establishes the connection, the system proxy or TUN handles traffic, rules choose its destination, DNS resolves domain names, and the route finally carries data to the exit. Interface labels may change, but the underlying relationships remain largely the same.