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

Subscriptions and subscription links: billing and configuration are different things

“Subscription” commonly has two meanings. A plan subscription refers to billing and service access; a client subscription is a source for retrieving node configurations. Data packages may also be imported into a client through a subscription link, so an “Update subscription” button does not mean your plan is renewing or that you’re being charged again.

A subscription link is usually a URL containing access credentials. When a client requests it, the link returns node server details, ports, authentication information, and other parameters. Some full configurations also include routing rules and DNS settings. The link itself is not a network connection; importing it simply gives the client the information it needs to connect.

Updating a subscription fetches the configuration again. Changes made on the server do not necessarily sync to an older local configuration, so refresh it as described in your client’s documentation. An update will not fix every connection problem: incompatible formats, unsupported protocols, network restrictions, and an inactive plan each require separate checks.

Treat your subscription link like a credential. Don’t post it publicly, include it in screenshots, or paste it into untrusted online conversion tools. If it has been exposed, reset the link if your panel allows it, then update the configuration on each device. Deleting the post won’t revoke credentials that have already been copied.

A single-node share link is different from a subscription link: the former usually describes one node, while the latter can return multiple nodes or an entire configuration. Similar file extensions don’t guarantee compatible formats. Before importing, check whether your client expects a subscription URL, a configuration file, or a single-node link.

Nodes and routes: labels don’t tell you the full path

A node is a connection configuration you can select in your client, typically including an endpoint address, authentication method, and protocol parameters. A route describes the network path and transport between your device, the entry point, and the exit point. A node name may summarize a route, but it is not a complete network topology.

The entry point is the server location your client connects to first; the exit point is the apparent source of requests seen by the destination website. With a relay, the entry and exit points may be in different regions. So the region in a node label, the location resolved from its entry domain, and the exit region detected by a website may not match.

A node test typically checks only a specific probe request. Passing the test doesn’t guarantee that video calls, streaming, or persistent API connections will work. Test with the app you actually need. Account region, content licensing, and how a site identifies the exit IP are also factors that route labels can’t determine.

IEPL private lines, relays, and direct routes: what’s the difference?

IEPL refers to an international Ethernet private line, where a dedicated transport is used for a particular segment. An “IEPL private line” label describes a route type; it doesn’t mean the entire path from your device to a website is dedicated. Your home network, wireless signal, entry-point load, and the route from the exit point to the destination can all affect performance.

A relay connects to an intermediate server first, which then forwards traffic to the exit point. Relays can change the cross-border route, but an extra hop isn’t automatically slower or faster; what matters is the quality of each segment. A relay can also use a private line, so these are not mutually exclusive categories.

In proxy services, a “direct route” usually means your device connects straight to an overseas server without an additional relay entry point configured by the provider. It doesn’t mean the connection bypasses all carrier routing equipment, nor does it mean that data is unencrypted.

Also distinguish this from DIRECT in routing rules, which means a request does not use the proxy. Selecting a “direct route” can still mean you’re using a proxy, while matching a website to DIRECT sends its traffic over your local network. The same term describes different things in a route list and in routing configuration.

What names like Shadowsocks tell you about protocols

In everyday discussions, encrypted proxies and traditional VPN tunnels are often both called VPNs, but they don’t handle traffic in exactly the same way. The protocol defines how the client and server communicate; a system proxy or TUN determines how requests on your device reach the client. Support for a protocol does not automatically route all device traffic through it.

Shadowsocks, VMess, Trojan, and VLESS

Shadowsocks is an encrypted proxy protocol. The client and server need matching parameters, such as the password and encryption method. VMess has its own authentication and encryption mechanisms and can be combined with different transport methods. Don’t import a configuration based on its name alone; transport and security parameters must also match.

Trojan typically uses TLS to protect communications alongside password authentication, making certificate validation and server name configuration important. VLESS does not encrypt data by itself and is usually paired with security mechanisms such as TLS or REALITY. When you see VLESS, check the security layer rather than assuming the connection is encrypted.

Hysteria2 and TUIC

Both Hysteria2 and TUIC are based on QUIC, which uses UDP as its transport. Whether they connect depends on how the current network handles UDP, as well as the server configuration and client support. Some networks allow TCP but restrict UDP; in that case, switching node regions may not solve the transport issue.

Protocol, transport, and security layer are related but distinct concepts. For example, WebSocket is a transport method and TLS is a security layer; neither should be confused with a node’s region. Using a matching configuration provided by the service is generally safer than assembling parameters by hand. Don’t disable certificate verification as a troubleshooting shortcut.

Global mode, rule mode, and TUN

Global mode usually sends all requests that reach the proxy client through the selected proxy. Rule mode decides where requests go based on domains, addresses, apps, or other conditions. Rules are generally matched in the order defined by the configuration, so a broad rule near the top may override more specific rules below it.

The biggest misconception about “global” mode is that it captures all traffic from the device. If the client only enables a system proxy, apps that don’t use the system proxy may still connect directly. If a browser works but a game or terminal tool doesn’t, check the app’s proxy support and how traffic is routed before assuming the node is faulty.

TUN uses a virtual network interface to send traffic covered by its routing settings to the client, usually capturing more traffic than a system proxy alone. It also depends on permissions, routes, DNS, and exception rules. TUN is a traffic-capture method, not a proxy protocol or a guarantee that no further checks are needed.

1. Note the current mode, selected node, and target app first. Avoid changing several settings at once.
2. Connect to the same node, temporarily switch from rule mode to global mode, and try the same destination again.
3. If global mode works but rule mode doesn’t, check the client logs for the matched rule and exit point. Look for accidental direct routing or an incorrect policy group.
4. If the browser works but another app doesn’t, check the app’s proxy settings or consult the client documentation to see whether TUN is required.
5. After testing, switch back to the rule mode that suits everyday use and check that local devices, campus networks, and office intranets remain accessible.

On Windows and macOS, the system proxy and virtual network interface are often separate settings. Mobile platforms typically route traffic through VPN permissions provided by the operating system, but available features depend on the app. On Linux, desktop environments, command-line apps, and routing configurations can also differ. Don’t assume a setting has the same name or behavior across platforms.

DNS leaks and connection checks

DNS translates domain names into network addresses. A DNS leak generally means that lookup requests expected to be protected or sent through a proxy instead go through the local network or an unintended resolver. A webpage loading confirms that the site was reached, but it doesn’t prove that DNS followed the intended route.

When troubleshooting, check the client’s DNS settings, routing rules, encrypted DNS in the browser, and the app’s own behavior. With encrypted DNS enabled, a browser’s lookups may not use the resolver expected by the client, though they may still travel through the proxy. So seeing a different resolver in a test is not enough on its own to prove a leak.

DNS test pages provide clues, not a definitive diagnosis. Check the client logs, resolution rules, and connection path together; cached results can also make changes appear ineffective for a while. A correct public exit IP doesn’t replace a DNS check, since website requests and DNS lookups may follow different routes.

• ✅ After importing a subscription, confirm that the configuration parses, the node list is populated, and the client supports the required protocol.
• ✅ Enable the system proxy or TUN as documented, then test the connection in the app you need—not just the client’s connection indicator.
• ✅ Check the rule, policy group, and exit point matched by the destination domain to distinguish misrouting from an unreachable route.
• ✅ Compare DNS test results with the client logs to check whether lookups follow the expected path.
• ❌ Don’t treat a successful node test, a region label, or one webpage loading as proof that every app works.

Use network terminology to choose a plan and configure your client

Network terminology helps you troubleshoot configuration; plans cover data and billing. VPNNV monthly plans offer ¥9.9/60GB, ¥18/250GB, and ¥28/500GB, with data resetting each month on the activation date. Data packages offer ¥158/300GB, ¥358/1000GB, and ¥658/3000GB; they never expire and remain available until used. Updating a subscription configuration does not reset plan data.

VPNNV has no limit on the number of devices online at the same time and offers a 60-day no-questions-asked refund. No email address is required to register. The no-logs policy is a privacy practice; it does not mean a website cannot identify a logged-in account or that client configurations need no protection.

Find the client in your user panel and get your subscription after signing in. Download access depends on the active plan shown in the panel. For setup and access, see the Quick Start Guide; for available regions and route types, see the Route List; for billing details, see the Plans.