Skip to main content

VPN terminology for beginners: subscriptions, nodes, routes, protocols, and traffic rules

A clear guide to VPN terminology: subscriptions vs. nodes, IEPL lines vs. relays and direct connections, common protocols, and global vs. rule-based mode.

This beginner’s guide puts subscriptions, nodes, routes, protocols and traffic rules into context. A subscription provides configuration, a node is a connection option, a route describes the path traffic takes, a protocol defines how it communicates, and traffic rules determine which path requests follow. Understanding the distinctions helps you decide whether to refresh a subscription, switch nodes or adjust client settings.

Subscriptions, Nodes and Routes: Configuration vs. Connection Paths

On a plan page, “subscription” usually refers to an ongoing service or billing arrangement. In a client, it often means a set of connection configurations that can be refreshed. The terms are related, but they are not interchangeable. Buying a monthly subscription does not automatically import it into your client. A data package may also deliver configuration through a subscription link; check the service dashboard for the available method.

A subscription link is an address a client uses to retrieve configuration, usually with credentials that identify access permissions. Once the client reads the link, it can display a list of nodes. A node configuration may include a server address, port, protocol, authentication details and transport settings. Country or city names in the list are display labels and cannot, by themselves, verify the actual exit location.

TermWhat it meansCommon actions
Subscription linkAn address for retrieving or refreshing connection configurationImport, refresh or reset using the dashboard’s available options
NodeA connection configuration you can select in a clientSelect, connect or test availability
RouteThe path traffic takes through an entry point, intermediate networks and an exitChoose based on your network conditions and destination region
ProtocolThe rules governing communication between a client and serverCheck that the client’s core supports it
Traffic rulesConditions that direct requests to actions such as direct connection, proxy or rejectionCheck which rules match and adjust the policy group

A node does not necessarily correspond to a dedicated server. Multiple nodes may share an exit or part of a route, so switching to a similarly named node does not necessarily change the entire path. When troubleshooting, check the exit region, actual access results and client logs rather than treating the number of nodes as the number of separate physical devices.

Direct Connections, Relays and IEPL Lines: Understanding the Route

In the context of a service’s routes, a direct connection usually means the client connects to an overseas server without an additional relay entry point configured by the provider. Internet traffic still passes through carrier routing. A relay connects to an intermediate server first, which then forwards traffic to the exit. Adding a relay introduces another hop, but a better peering route may improve performance. The number of hops alone does not determine which route is better.

IEPL generally refers to an international Ethernet private line, an Ethernet connectivity service provided by a carrier. When an acceleration service refers to an “IEPL route,” it may mean that only one segment of the route uses this type of line—not that the entire connection, from your device to the destination website, uses a dedicated link. Home broadband, the access point and the network between the exit and the website can all affect the connection.

Note that “direct” has two meanings here. In a route description, it refers to the path to the server. In a rule, DIRECT usually means that a request does not go through a proxy. The former may still use a proxy service; the latter determines how the request is routed out.

Common Protocols: Compatibility Matters More Than the Name

A protocol determines how a connection is established, how data is transmitted and how authentication works. It does not determine the exit region or guarantee access to a particular platform. Clients with similar interfaces may use different cores and versions, with different protocol and parameter support. A successful import only means the client read the configuration; it does not prove that every node will work.

  • Shadowsocks: An encrypted proxy protocol commonly used to proxy app traffic. The client and server must use matching encryption methods and authentication details. It is not, by itself, a system-wide virtual private network.
  • VMess: A proxy protocol with authentication and encryption mechanisms that can use different transport methods. An inaccurate system clock can interfere with authentication, so check that time is synchronized when troubleshooting.
  • Trojan: Typically uses TLS to protect connections. The certificate, domain and handshake settings must be configured consistently. If you see a certificate error, check the configuration and system clock rather than disabling verification.
  • VLESS: A lightweight proxy protocol that does not encrypt payloads by itself. Connection protection depends on accompanying mechanisms such as TLS or REALITY. The protocol name alone does not tell you whether the full configuration is secure.
  • Hysteria2: A QUIC-based proxy protocol that relies on UDP. If the network blocks UDP, the connection may fail. The version in the name also matters for client compatibility.
  • TUIC: Also based on QUIC. Its performance depends on congestion control, implementation and configuration. A client that supports other QUIC protocols may not support TUIC, so check for it specifically.

No single protocol works on every network. Hotel Wi-Fi, corporate networks and public hotspots may each impose different restrictions. If a protocol fails to connect, first check whether the current network allows its transport method, then look for authentication or certificate errors. Avoid changing parameters supplied by the service just to try an “advanced protocol.”

Rule-Based vs. Global Mode: Where Your Traffic Goes

Rule-based mode uses domains, destination addresses, processes or other conditions to choose whether traffic connects directly, uses a proxy or is rejected. It suits everyday use when you need to access both local services and international websites. Rules are usually checked in order, but the order and syntax depend on the client. A broad rule near the top may take precedence over more specific rules below it.

Global mode generally routes requests handled by the proxy core through the selected proxy policy, but it does not necessarily send all device traffic through the core. With system proxy enabled alone, some apps may ignore the system proxy settings. TUN or system VPN mode typically captures more traffic, but routing rules, exclusions and platform limitations still apply.

Use rule-based mode day to day, and switch to global mode temporarily when troubleshooting. If a website works in global mode but fails in rule-based mode, first check which rule matched and which policy group was selected. If it fails in both modes, check the node, protocol, DNS and destination website. Switching modes is a diagnostic step, not a permanent fix.

Before accessing a company intranet, local network devices or workplace apps, check your organization’s requirements. An enterprise VPN, system proxy and other network tools running together may conflict over routing or DNS settings. Do not change security settings configured by your organization without permission; contact your network administrator if you need to confirm compatibility.

DNS and Region Detection: A Connection Does Not Guarantee the Expected Result

DNS translates domain names into addresses. A DNS leak usually means DNS requests that should follow a proxy or tunnel policy instead take an unexpected resolution path, potentially exposing queried domains to the local network or resolver. This is separate from the exit IP a website sees: the correct exit does not necessarily mean DNS requests followed the expected path.

Conversely, a test page showing a resolver in a particular region does not, by itself, prove that a leak occurred. Public DNS services may use distributed servers, and IP geolocation data can be inaccurate. Consider the client’s DNS settings, connection logs and the test method together rather than drawing conclusions from a map location alone.

A website’s region detection may also depend on account location, payment region, browser cache and the platform’s own detection rules. A node that opens a website does not necessarily provide access to content for a particular region. To troubleshoot a region issue, check the exit first, then the account and website requirements. There is no need to keep changing unrelated protocol settings to alter your region.

Importing and Refreshing a Subscription: Check Permissions on Each Platform

A typical setup starts with getting a subscription link from a trusted user dashboard, importing it into a compatible client, refreshing the configuration, selecting a node and enabling the required traffic-capture method. Refreshing a subscription only retrieves configuration; the connection toggle, system proxy or VPN permissions may need to be enabled separately. Automatic refresh intervals depend on the client’s settings—there is no one schedule that applies to every client.

  1. Get the configuration: Copy the subscription link from the official dashboard. Do not use account-specific configuration forwarded in a group chat. If the dashboard offers formats for different clients, choose the one that matches yours.
  2. Import and check: Confirm that the node list appears correctly. If the format is unsupported, check the client core and configuration format. Do not give a link containing credentials to an unfamiliar online converter.
  3. Choose a traffic-capture method: Follow the client’s instructions to enable the system proxy, TUN or system VPN permission. If you only have a node list and have not enabled traffic capture, apps may still use the original network.
  4. Test access: After selecting a node, check the exit and the destination website, then review which rules matched. After refreshing the subscription, make sure no policy group still points to a node that has been removed.

Windows and macOS clients may offer different options, such as a system proxy or TUN; TUN may require additional permissions or network components. iOS and Android typically use system VPN authorization to capture traffic, but app exclusions, background behavior and on-demand connection support vary by client. On Linux, also check service permissions, routing and how the system manages DNS.

Connection Problems: Find the Cause Before Changing Settings

A “low latency” result only describes the round-trip time of a particular test request. It does not mean high download speeds or stable video playback. Some clients test server connectivity; others test a web response through the proxy. Their results are not directly comparable. For troubleshooting, keep the network, node and destination app consistent, and change one setting at a time.

  • ✅ No nodes in the list: First check whether the subscription was retrieved successfully, whether the service is running normally and whether the client supports the returned configuration format.
  • ✅ Nodes are listed but none connect: Check for authentication, certificate or timeout errors, verify the system clock and, if the network allows it, try another compatible node.
  • ✅ Browsing works, but other apps do not: Check whether those apps follow the system proxy and whether your traffic-capture method covers them.
  • ✅ Only some websites have problems: Check the matching rules, DNS handling and account region. Do not assume every issue is caused by bandwidth.
  • ✅ Connection fails only on a particular network: Complete any web-based sign-in required by the public network, then compare with another trusted network. For corporate network policies, check with your administrator.
  • ❌ Do not change the protocol, edit DNS, disable certificate verification and reinstall the client all at once. Changing several variables together makes the cause harder to identify.

Keep plan selection separate from technical terminology. A protocol is not a billing period, and the number of nodes is not your data allowance. VPNMove monthly plans offer ¥9.9 / 60GB, ¥18 / 250GB and ¥28 / 500GB, with monthly data resetting on the activation date. Data packages remain available until used and never expire. Decide whether your usage is ongoing, then compare allowances and prices on the plans page.

Remember the sequence: subscriptions provide configuration, nodes are connection options, routes show the path, protocols determine compatibility, and traffic rules decide where requests go. Check each step in order to troubleshoot more effectively than by switching modes at random. To learn about the routes and setup options available on this site, see the route and protocol guide and setup guides.

Try Free