VPN Terms for Beginners: Subscriptions, Nodes, Routes, Protocols & Traffic Rules

This VPN glossary explains what each term does: a subscription provides configuration, a node is a connection endpoint, a route describes the path data takes, a protocol defines how devices communicate, and traffic rules determine where requests go. These pieces work together, but they are not interchangeable. Seeing “Connected” does not mean every app is using the selected exit.

In everyday use, “VPN” can also refer broadly to proxy services used for network access. Strictly speaking, system-wide virtual networks and app-level proxies work differently. This guide explains terms as they are commonly used in client apps; no protocol, route type, or mode should be treated as a guarantee of service quality.

Subscriptions, nodes, and clients

A paid subscription is a billing arrangement; a subscription link is a way to import configuration. The former determines your data allowance and billing period. The latter lets a client retrieve connection settings provided by the service. “Update subscription” usually means fetching the configuration again—not renewing a paid plan or resetting its data allowance.

A client is the software that uses these configurations. A node is a connection option within it and may include a server address, port, authentication details, protocol, and transport settings. A node name is just a label for identification; it cannot, on its own, confirm the actual exit location, network path, or how a destination platform identifies the connection.

Start with what each term does
Term	What it does	Common point of confusion
Paid subscription	Sets the plan, data allowance, and billing period	Not the same as updating the client configuration
Subscription link	Provides configuration that the client can refresh	Not a regular webpage and should not be shared publicly
Node	Provides connection settings for the client to use	A node name does not prove the actual exit location
Route	Describes how traffic travels between the entry point, relay, and exit	A route type is not a communication protocol
Protocol	Defines how the client and server communicate	Support for a protocol does not guarantee every configuration variant will work
Traffic rules	Determine whether a request connects directly, uses a proxy, or is rejected	Selecting a node does not mean every request will use it

Whether a subscription link works across different clients depends on the configuration format and core support. Seeing a node list after importing does not mean the rules, DNS settings, and policy groups are all in place. Some subscriptions provide a complete configuration; others provide node details only. Check the service documentation and the import result.

Routes: IEPL, relayed, and direct connections

Routes describe where data travels. The path from your device to the entry point, from the entry point to the exit, and from the exit to the destination website can all affect performance. The region shown in a client usually refers to the exit location, not necessarily the entry point. The full path may not be clear from a node name alone.

Direct routes vs. direct connections in traffic rules

In route classifications, “direct” usually means the client connects to an overseas server over the public internet, without an additional configured relay. The connection may still follow the ISP’s usual routing. A “direct route” can carry proxy traffic; “direct” in a traffic rule means connecting to the destination without a proxy. They are not the same thing.

Relayed routes

A relay adds a forwarding step between the client and the exit. It may improve reachability to the entry point or avoid a poor network path, but it can also introduce another point of congestion. Whether it works better on your network depends on the entry point, relay link, and exit load—not just the “relay” label.

IEPL

IEPL generally refers to an international Ethernet private line used to connect networks in different locations. When a service uses IEPL, it usually describes one segment of the route; it does not mean the entire connection from your device to the destination website uses a private line. Your home network, hotel Wi-Fi, and the link from the exit to the website can still be bottlenecks.

Route type can affect stability, but it cannot replace testing in real-world conditions. Compare using the same device, local network, and destination app, then check performance during peak hours and over extended use. One successful connection is not proof of long-term performance.

Protocols: names and compatibility

A protocol defines how two sides exchange data. The protocol, encryption method, transport, and TLS settings in a configuration are related but distinct layers. Knowing the protocol name alone is usually not enough to recreate a working node manually. It is safer to use a configuration provided by the service and compatible with your client.

Shadowsocks: A widely used encrypted proxy protocol. The client and server need matching encryption methods and authentication settings. Support can vary between versions and extensions.
VMess: A proxy protocol commonly used in the V2Ray ecosystem. A working connection also depends on the configured transport and related settings; copying the server address alone is not enough.
Trojan: Often uses TLS to carry proxy traffic. Certificate validation, server name, and authentication details must match for the connection to work.
VLESS: The protocol itself does not encrypt traffic. Security depends on the security layer used with it and the complete configuration. Differences in the name alone do not indicate a higher or lower security level.
Hysteria2 and TUIC: Both are based on QUIC and generally require the network to allow the relevant UDP traffic. If UDP is restricted on your network, a correctly configured node may still fail to connect.

These are general explanations, not a list of protocols supported by VPNKM. Client support depends on the app version, core version, and specific configuration. A significantly incorrect system clock can also affect connections that rely on certificates or time checks. When an error occurs, read the logs before changing the configuration.

Routing: rule-based and global modes

Traffic rules determine whether a request connects directly, goes through a proxy policy group, or is rejected after the client receives it. Rules can match domains, destination IPs, processes, or other criteria, depending on the client. Many configurations evaluate rules in order, so an earlier match can determine the outcome. Adding more rules is not necessarily better.

Rule-based mode selects a route based on configured conditions. For example, one set of domains might use a proxy, other requests might connect directly, and unmatched requests might go to a fallback policy. A policy group is a set of exit options or a way to select one—not a new route. If the group selects a direct connection, a request may bypass the proxy.

Global mode usually sends requests already handled by the client through a single policy. The key is “already handled”: if an app does not use the system proxy and is not routed through a virtual network interface, switching to global mode alone will not automatically send its traffic through the client. Global mode also does not necessarily mean all requests use the same exit; check the selected policy.

A system proxy tells apps that honor the setting to send requests to a local proxy port. TUN mode uses a virtual network interface to capture traffic that matches the routing conditions. It usually covers more traffic, but exclusions, routes, and client implementation still matter. Modes with similar names can behave differently across apps.

DNS, exit IPs & leaks

DNS translates domain names into addresses that devices can connect to. An exit IP is the source address a destination website sees. These describe different parts of a connection: seeing a web request use the expected exit does not, on its own, prove that DNS queries used the expected route too.

A DNS leak usually means domain lookups leave the intended resolution path—for example, when queries are expected to be handled through the proxy but are still sent to the local network’s resolver. To determine whether there is a problem, first check the intended configuration. A domain set to connect directly using local DNS is not necessarily leaking.

Browser Secure DNS, app-level resolvers, system caches, and client DNS settings can all affect test results. The resolver region shown on a test page does not, by itself, prove where the query went. Check client logs, DNS configuration, and app settings together; don’t draw conclusions from a map or region label alone.

Check the exit separately for each app. An IP lookup in a browser only describes that browser request; meeting apps, command-line tools, and download clients may use different routes. If your network supports both IPv4 and IPv6, make sure the client’s coverage and your test method are consistent.

Import and verify your client configuration

Windows, macOS, iOS, Android, and Linux differ in their permission systems and network settings. Mobile devices commonly prompt for system VPN permission; desktop clients may have separate system proxy and TUN switches; Linux apps may require separate proxy environment or service permissions. A VPN indicator only confirms that a relevant connection or interface is active—it does not verify how an app is routing traffic.

Check your account and how to get the configuration. Confirm your plan status, then retrieve a compatible configuration using the method provided by the service. VPNKM’s client requires you to sign in and have an active paid plan; get the subscription after signing in. See the client page.
Check the format before importing. Use the client’s subscription or configuration import feature. Check that nodes, rules, and policy groups have been imported successfully. If you see a format error, first check client compatibility; don’t repeatedly submit the link to unfamiliar conversion services.
Choose a node and traffic-capture method. Start with the configuration and mode recommended by the service, and grant any required system permissions. Avoid running multiple clients that capture network traffic at the same time, so you can tell which one is actually in use.
Test the app you need. Check your browser’s exit, then open the app you intend to use. See whether the client records a connection for it, which rule matched, and which policy was ultimately selected.
Troubleshoot one layer at a time. If no node connects, check your local network, configuration, and authentication first. If the browser works but another app does not, check which traffic the client captures. If only certain websites fail, check the rules, DNS, and the destination platform’s status.

A subscription update may replace parts of the configuration. Whether manual changes made in the client are retained depends on the app. Before editing, understand where the configuration comes from and how overrides work. During troubleshooting, change one related setting at a time and check the result before continuing. This avoids turning one identifiable issue into several overlapping variables.

Plan terms to check before you start

Data allowance, connected devices, and route count are separate factors. VPNKM has no device limit, but all devices share the data allowance of the selected plan. Coverage across 110+ countries / 160+ routes describes the service’s reach; it does not guarantee access to every destination website.

VPNKM monthly subscriptions reset data each month on the activation date, not on the first of the calendar month. If you upgrade mid-cycle, the price difference is prorated for the remaining days. Data add-ons last until used and never expire. Check the plans page for current allowances and prices. A data add-on is not a subscription that automatically replenishes every month.

✅ I can tell the difference between a paid subscription and a configuration subscription, and know that refreshing configuration does not renew a plan.
✅ I checked client compatibility instead of treating a protocol name as proof of route quality.
✅ I checked policy groups and traffic rules, and tested both my browser and the apps I actually use.
✅ I concealed subscription tokens and authentication details before sharing logs or screenshots for help.
❌ Don’t infer the route for all traffic from a “Connected” status, a region name, or a single exit IP lookup.

For your first setup, see the getting started guide. If you’ve imported the configuration but still can’t connect, continue with the troubleshooting guide. When contacting support, include your operating system, client, error message, and the checks you’ve already tried. This is more helpful than simply saying “the node doesn’t work.”