Skip to main content

VPNBasics: Subscriptions, Nodes, Routes, Protocols, Routing, and Global Mode Explained

A clear guide to subscriptions, nodes, route types, protocols, split tunneling, global mode, and rule mode—so you can make sense of your client’s settings.

Here’s a quick map of the key VPN terms: a subscription provides configuration, a node is a connection endpoint, a route is the path traffic takes, a protocol defines how devices communicate, split tunneling determines where traffic goes, and global mode changes routing choices. Each term describes a different layer; they aren’t interchangeable.

In everyday conversation, a “VPN client” might mean a system-level tunneling app or a proxy client. They handle traffic differently. Seeing a connection button turn on only tells you that a connection or configuration is active; it doesn’t mean every app is using the same route. This guide explains the terms in the order you’re likely to encounter them.

The difference between subscriptions, configurations, and plans

“Subscription” commonly has two meanings. A plan subscription covers billing and service benefits; a subscription link is an address a client uses to fetch configuration. The plan determines which resources are available to your account, while the link delivers nodes, credentials, and related settings to the client. Importing a link doesn’t complete payment, and updating a subscription doesn’t renew your plan.

What a subscription link returns depends on the provider and the client’s configuration format. It may contain only a list of nodes, or it may also include policy groups, rules, and DNS settings. Don’t assume every subscription includes a complete split-tunneling setup, or that one client’s configuration will work in another.

“Update subscription” usually means downloading the configuration again to sync node changes or updated settings. If the update fails, first check that the link is complete, your account is in good standing, and your current network can reach the configuration address. Switching nodes repeatedly is unlikely to fix a configuration download problem.

Understanding nodes, regions, and exit IP addresses

A node is a connection configuration you can select in a client. It may include a server address, port, protocol, and authentication details. A region name in the interface is a label for identification; it doesn’t necessarily indicate the physical location of the entry server. With a relay, the entry and exit points may be in different regions.

An exit IP address is the network origin a destination website sees. The region a site displays can also depend on its IP geolocation database, account settings, and platform policies. A node name alone can’t confirm which regional content a platform will provide. Check the actual exit IP and the destination service.

A policy group adds a layer of selection logic: it can let you choose a node manually or select one automatically using a strategy supported by the client. Automatic selection may be based on measured latency, not actual download speed or whether a particular website is reachable. A node with a faster latency test isn’t necessarily the best choice for every use.

Route types: direct, relayed, and IEPL

A route describes the path data takes; a protocol describes how the two ends communicate. The same protocol can run over different routes, and nodes in the same region may use different paths. A less familiar protocol name isn’t evidence of a better route.

What route labels mean—and what they don’t tell you
Type Typical meaning What to check
Direct The client connects to the proxy server over the public internet, without an additional provider-operated relay server in between. Local ISP routing, congestion between networks, and the destination server’s load.
Relay Traffic first connects to an entry server, which forwards it to a subsequent server or exit point. Whether the entry point is reachable, the onward connection is stable, and your actual use works smoothly.
IEPL dedicated line Usually refers to some part of the route being carried over an international Ethernet private line. Which segment uses the private line, and how the entry point, exit point, and local connection perform.

An IEPL label doesn’t mean every segment from your device to a website uses a private network, nor can it tell you the bandwidth or service availability. Wi-Fi quality, exit server load, and the destination site’s response can all be bottlenecks. Test routes for your actual needs instead of judging by their names alone.

Protocol names and client compatibility

Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC are names of different proxy protocols or protocol schemes—not speed settings for the same feature. Whether a client can connect depends on kernel support and whether the protocol parameters, transport, and security layer are compatible. These are technical explanations; they don’t mean VPNMH offers every protocol listed.

  • Shadowsocks: An encrypted proxy protocol family. The client and server must use compatible encryption methods and credentials.
  • VMess: Uses its own authentication and communication mechanisms. Preserve the associated transport settings when importing; copying only the server address isn’t enough.
  • Trojan: Usually uses TLS to protect the connection. Domain and certificate validation settings can affect whether it connects.
  • VLESS: Doesn’t encrypt payloads by itself. Consider it together with an appropriate secure transport; the protocol name alone doesn’t tell you whether traffic is encrypted.
  • Hysteria2 and TUIC: Built on QUIC and rely on UDP, so local network restrictions on UDP may affect connectivity.

TLS, WebSocket, and QUIC aren’t in the same category as the protocol names above. When a client shows several fields, they often describe a combined configuration. Beginners are better off using a compatible, complete subscription than guessing at each field. If you see a certificate error, check the domain, device clock, and official configuration. Disabling certificate validation isn’t a general fix.

Choosing routing, rules, or global mode

Split tunneling routes traffic according to specific conditions. Rules can send requests to a direct connection, a proxy policy group, or a reject action based on domains, destination addresses, app processes, or other supported criteria. Which criteria are available depends on the client and its permissions.

Rule mode usually checks rules in the order they appear in the configuration. Once a rule matches, its action applies; requests that don’t match are handled by the fallback rule. If a broader direct rule comes before a proxy rule for a domain, that domain may still connect directly. Check the rule content, its order, and the connection logs.

In many proxy clients, global mode sends traffic already handled by the client through the selected proxy policy. It doesn’t automatically ensure that every app, address type, and DNS request is handled. If an app bypasses the system proxy, switching to global mode alone may not help.

Direct mode usually lets connections handled by the client reach their destinations directly; it doesn’t necessarily exit the client entirely. Naming varies by app, so check the documentation for your client. For everyday work or study, start with a well-maintained rules configuration. When troubleshooting one site, compare the results in rule mode and global mode temporarily.

Bottom line: Rule mode routes traffic by use case; global mode is useful for comparison and troubleshooting. If a site works in global mode but not in rule mode, check which rule matched and whether DNS resolution differs before assuming the node has failed.

How system proxies and virtual network interfaces handle traffic

A system proxy sets a proxy address in the operating system. Apps that honor this setting send their requests to the client. Some apps use their own networking stack or a separate proxy setting, so they won’t automatically follow the system proxy. That’s one common reason a browser works while a desktop app doesn’t.

TUN mode uses a virtual network interface and routing to capture traffic. It works differently from a system proxy and usually requires the appropriate permissions. It isn’t a performance boost and may not be compatible with other tunneling software. After enabling it, check routing, DNS, local network access, and the app’s own settings.

Windows and macOS clients may offer separate options for system proxies and virtual network interfaces. Linux may also involve desktop environments, command-line environment variables, or system routing. Android and iOS clients often carry traffic through the system VPN interface, but per-app controls and background behavior still depend on the app and operating system. The same “Connected” status doesn’t mean the same traffic coverage on every platform.

DNS resolution and DNS leaks explained

DNS translates domain names into network addresses. When you open a website, DNS resolution and the subsequent web connection are separate steps. Routing the web connection through a proxy doesn’t mean the DNS request follows the same path. A client may use system DNS, a specified resolver, or different resolution methods based on rules.

A DNS leak usually means a DNS request was sent to a resolver outside the intended path. The key question is whether the request follows your configured expectations—not whether you see a local resolver. In rule mode, using local DNS for local websites may be intentional.

When troubleshooting, check the client’s DNS settings, secure DNS in the browser, system DNS configuration, and whether IPv6 traffic is handled. If the browser uses encrypted DNS on its own, that may change the resolution path. Encrypted DNS protects communication with the resolver; it doesn’t automatically route the subsequent website connection through a proxy.

From import to verification: a practical sequence

Once you understand the terms, follow these steps to set up a connection you can troubleshoot. Change one setting at a time so you can identify what made a difference. Client menus vary, but the troubleshooting logic is much the same.

  1. Get the official configuration. Sign in to the service dashboard, find the subscription option, and confirm the format is compatible with your client. VPNMH subscriptions are available after login. Find the entry point in the Quick Start Guide.
  2. Import and update. Use the client’s subscription import feature and confirm that nodes appear in the list. If the list is empty, troubleshoot the configuration download or format first; don’t rush to change global mode.
  3. Choose a node and policy. Check which node the current policy group points to. Seeing a node in the list doesn’t mean the active policy group has selected it.
  4. Confirm traffic is being handled. Choose a system proxy or suitable virtual network interface for the app, and check any permission prompts. Avoid running multiple tools that compete to control routing.
  5. Test your actual use case. Open the website or app you need, then check the client’s connection logs for matched rules, the selected node, and error details—not just latency test results.
  6. Compare one change at a time. Test other nodes, modes, or available networks one by one. Keep settings that work, and avoid changing DNS, protocol, and routing all at once—you’ll lose track of what helped.
  • ✅ No nodes in the list: Check the subscription link, format, and update result first.
  • ✅ Browser works but an app doesn’t: Check whether the app follows the system proxy and whether its traffic is being handled.
  • ✅ Global mode works but rules don’t: Check rule order, the fallback action, and DNS settings.
  • ✅ Shows as connected but the destination doesn’t work: Check request logs to distinguish authentication, DNS resolution, transport, and destination service errors.

These checks help narrow down the cause; they don’t diagnose a fault on their own. If a website restricts certain exit points or account regions, changing modes may not help. If your local network requires access authentication first, proxy settings can’t replace that step. For more connection troubleshooting, visit the Help Center. For route details, see Global Network.

Quick recap: First confirm the subscription downloads, then check that a node connects, that the client handles your traffic, and finally that the rules and DNS suit your needs. Troubleshooting layer by layer is more effective than repeatedly switching to global mode.

Start Free