This VPN terminology guide puts subscriptions, nodes, routes, protocols, and traffic routing in context. Subscriptions provide configuration, nodes are connection endpoints, routes describe the path data takes, protocols define how devices communicate, and rules determine where requests go. Understanding these layers makes it easier to choose a setup and troubleshoot issues than relying on node names alone.
Everyday use of the term VPN client sometimes refers to software that handles proxy connections and traffic routing rather than a traditional VPN protocol. This guide explains terms as they commonly appear in client apps. For specific features, supported protocols, and configuration formats, check the client documentation and account dashboard. General industry concepts should not be taken as a list of VPN82 features.
Subscription Links and Paid Plans
“Subscription” can mean two different things. A paid subscription is an account billing arrangement that determines available traffic and service duration. A subscription link is an address a client uses to retrieve configuration. Copying a link or importing a configuration does not complete a payment; updating a subscription does not renew it or add traffic.
When a client requests a subscription URL, it typically retrieves node settings. Some configuration formats can also include policy groups, rules, or DNS settings. Clients do not all support the same formats, so a successful import does not guarantee that every setting is active. If nodes appear but will not connect, check protocol compatibility, configuration completeness, and account status.
Subscription URLs often contain credentials that can retrieve your personal configuration, so protect them like account passwords. Do not publish the full URL or submit it to an online converter from an unknown source. When reporting an issue, share a redacted error message instead. If a link has been exposed, check whether the dashboard lets you reset it or contact support for help.
Nodes, Routes, and Exit IPs
A node is a selectable connection entry in a client, usually containing a server address, port, authentication details, and protocol settings. A route describes the path from your local network through an entry point and backbone transport to an exit. Providers use different naming conventions, so node names are only labels—not a substitute for details about the actual route.
The entry point is the first server the client connects to; the exit is where a request leaves the proxy network to reach its destination. Websites generally see the exit IP, not the node name. A node labeled with a region does not mean every part of the route is in that region, nor does it guarantee that a particular platform will accept the exit.
The same region can have different entry or exit points, and different entries may share some resources. To assess the differences, check client connection logs, how the destination website behaves, and the dashboard details—not just labels such as “high speed” or “dedicated route.”
| Term | What it describes | What it does not guarantee |
|---|---|---|
| Node | A connection configuration you can select in a client | A dedicated exit or fixed bandwidth |
| Route | The path made up of an entry point, transport links, and an exit | Consistent performance at all times |
| Exit IP | The network address a destination website sees | That a platform will identify your region or account permissions as expected |
| Policy group | How a client organizes nodes and selects among them | That nodes in the group have the same quality or region |
Direct, Relayed, and IEPL Routes
In the context of service routes, direct usually means the client connects straight to an overseas server without an additional relay entry point set up by the provider. The path is more direct, but performance still depends on your local carrier, international gateways, interconnection between networks, and the destination server. “Direct” does not mean low latency.
A relayed route adds a forwarding step between the client and an overseas exit. A common setup connects first to an entry point that is easier to reach, then forwards traffic to the exit. A well-designed relay may reduce detours and improve connection stability, but congestion at the entry point or limited forwarding capacity can create a bottleneck. An extra relay does not automatically make a connection faster.
IEPL stands for International Ethernet Private Line and usually refers to a dedicated Ethernet connection service provided by a carrier. In cross-border acceleration, it may carry traffic along part of the route between an entry and an exit. It does not mean that every segment—from your local connection to the destination website—is a dedicated link, nor does it automatically provide dedicated bandwidth or an exclusive IP.
How to choose a route: First check whether you can access the destination website normally, then observe how the connection performs during your actual usage hours. Direct, relayed, and IEPL describe how a route is organized; none alone guarantees speed, privacy, or platform access.
Protocols and Client Compatibility
A protocol defines how a client and server establish a connection, authenticate, and transmit data. Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC are common names, but they are not interchangeable configuration labels. The client must support the protocol and required settings, and the server configuration must match.
- Shadowsocks: A family of encrypted proxy protocols. The encryption method, implementation version, and key format must match; seeing the name in a client is not enough.
- VMess: A proxy protocol with an authentication mechanism that depends on configuration settings and accurate system time. If the clock is significantly off, check the device time first.
- Trojan: Typically uses TLS to establish an encrypted connection. Certificate validation and settings such as the server name affect whether the connection succeeds; do not disable certificate checks casually as a troubleshooting step.
- VLESS: Does not provide transport encryption on its own; its security depends on the transport and security layers used with it. The name VLESS alone does not tell you how the complete connection is set up.
- Hysteria2 and TUIC: Both are based on QUIC and rely on UDP being reachable, but they are different protocols. If the network restricts UDP, check for a compatible alternative route rather than assuming the client is broken.
A protocol is only one factor. Even with the same protocol, entry-point load, packet loss along the route, and differences in client implementations can affect performance. These protocols are included to explain general concepts, not to claim that VPN82 supports them all. Check the dashboard and setup guide for currently supported options.
Traffic Routing, Global Mode, and Rule-Based Mode
Traffic routing uses conditions to decide where a request goes: connect directly, use a specified proxy, or block the connection. Conditions may be based on a domain, destination IP, process, or rule set. Rules are generally checked in order, though precedence depends on the client. A broad rule near the top may override more specific rules below it.
Rule-based mode uses conditions in the configuration to route requests, making it useful for everyday use that combines local services and international websites. Global mode generally sends requests handled by the client through the selected proxy policy, but it does not mean that every app on the device must use the proxy. Apps that ignore the system proxy and connections not captured by the client may still use their original route.
Also distinguish “direct” as a route type from “direct” as a rule action. In a rule, DIRECT generally means bypassing the proxy and connecting to the destination from the device. It does not select an overseas node named “Direct.” If the client is connected but a website sees a local exit, check which rule matched first.
The system proxy affects only apps that follow that setting. TUN mode captures traffic through a virtual network interface and usually requires additional permissions. Its coverage still depends on routes, exclusions, DNS, and the client implementation. Switching to global mode cannot replace enabling the right traffic-capture method or grant account permissions on a destination platform.
- ✅ Everyday use: Start with rule-based mode. Confirm that local services connect directly and that domains requiring a proxy use the expected policy group.
- ✅ Temporary troubleshooting: Keep the node unchanged and compare rule-based and global modes to see whether rule matching is causing the issue.
- ✅ One app is behaving differently: Check whether it follows the system proxy, then see whether it needs TUN capture supported by the client.
- ❌ Do not change the node, DNS, mode, and rules all at once. Changing multiple variables makes it difficult to identify the cause.
DNS Resolution and Leak Checks
DNS translates domain names into IP addresses. Routing a webpage connection through a proxy does not mean its DNS requests take the same path. Browser encrypted DNS, the system resolver, and the client’s built-in resolver may all work independently. If DNS requests do not follow the expected route, domain lookups may be sent over the local network.
A DNS leak generally means that DNS requests bypass the intended protection path and are exposed to a resolver or network you did not intend to use. A test showing a resolver in a particular region is not enough on its own to prove a leak; consider who operates the resolver, how the client is designed, and how the test works. Encrypted DNS protects queries in transit to the resolver, but does not automatically make every app use the same exit IP.
Some clients use Fake-IP, mapping domain names to synthetic addresses so they can apply rules by domain later. These are not the destination website’s real addresses and are not a measure of anonymity. If an app is incompatible with this resolution method, configure an exception according to the client documentation rather than copying DNS settings from an unknown source.
Import, Connect, and Troubleshoot in Order
Windows, macOS, iOS, Android, and Linux use different proxy settings and permission models, and client menus vary. Desktop clients commonly offer system proxy and TUN options; mobile clients typically use the system-provided VPN interface to capture connections. A VPN indicator in the system tray does not confirm that the exit, rules, and DNS are all configured as expected.
- Get the client: Check the user dashboard download page for the version and instructions for your platform, and confirm which configuration formats it supports.
- Import the subscription: Use the import method or subscription URL provided in the dashboard. Confirm that the configuration updates without errors and that nodes appear in the list.
- Choose a connection: Select the destination region and policy, grant the permissions required by the system, and avoid running other network tools that may also change routing.
- Verify requests: Visit the website you intend to use and check the client logs for matched rules, the node in use, and error messages. Do not rely only on the connection button’s status.
- Troubleshoot step by step: If the subscription cannot be retrieved, check the URL and account. If the connection fails, check the protocol and network. If the connection succeeds but access does not work as expected, check routing rules, DNS, and restrictions imposed by the destination platform.
VPN82 supports Windows / macOS / iOS / Android / Linux, with no limit on the number of devices connected at the same time. This device policy does not mean traffic is unlimited. Monthly subscriptions reset traffic each month on the activation date; traffic packages never expire. You can create an account with a username and password—no email address required. You can request a full refund for any reason within 7 days of your first payment. For details on how to use the service and billing, see the Help Center and Plans.
Quick recap: Get configuration from a subscription, choose a node for the connection, check the route for the data path, check the protocol for compatibility, and use rules to control where requests go. Follow these steps in order when troubleshooting to avoid mistaking a billing issue for a network problem—or a destination platform restriction for a connection failure.