This beginner’s VPN glossary starts with using Netflix and AI tools across borders. A subscription provides configuration, a node determines the connection endpoint, a protocol defines how data is transmitted, and routing rules decide which requests take that path. Understanding how each part works is more useful for troubleshooting than repeatedly switching client settings.
Some apps commonly called VPN clients actually use proxy protocols and may not route all of a device’s traffic. A successful connection indicator only confirms that one part of the connection is established; it doesn’t prove that your browser, other apps, and DNS queries are all being routed as expected. Here’s what the terms mean in the order you’ll encounter them.
Subscription Links: Configuration Access, Not Web Addresses
A subscription link is an address a client uses to retrieve configuration, usually with access credentials specific to your account. The client reads it to get node names, server addresses, ports, authentication details, and other settings. Some subscriptions also include routing rules or policy groups. This is different from a paid monthly subscription: one is a way to deliver configuration, the other is a billing plan.
Pasting a subscription link into a browser may display encoded text or configuration that isn’t readable at a glance. That doesn’t necessarily mean the link is broken; what matters is whether your client can read its format. Configuration formats are also distinct from proxy protocols: a client that supports a particular protocol may not be able to read every subscription format.
“Update subscription” means fetching the configuration again. It doesn’t renew your plan or necessarily change your exit route. If the provider updates its nodes, refreshing the subscription can sync those changes. Whether locally added rules are preserved depends on how the client manages configuration. Check what will be overwritten before making changes, and don’t treat temporary edits to subscription content as permanent settings.
Nodes and Routes: Connection Endpoints and Network Paths
A node is usually a selectable connection configuration in the client; a route describes the network path the traffic takes. Providers sometimes use these terms interchangeably, so a node’s name alone doesn’t reveal its actual path. A region label may refer to the final exit location, not the location of the server your device connects to directly.
When you access Netflix, the exit region is an important factor in how the platform determines available content, but account status, licensing, and platform policies also matter. For AI tools, check the platform’s supported regions and account requirements as well. “Unblocking” usually means that a particular exit can access specific content at a given time; it’s no guarantee for every title, account, or occasion.
| Route type | Typical path | What to consider |
|---|---|---|
| Direct | Your device connects to the remote proxy server over its current network, without going through a separate relay entry point provided by the service. | Routing, congestion, and reachability between your local provider and the remote server. |
| Relayed | Your device first connects to a relay entry point, which forwards traffic to another server or exit. | The quality of the entry point and the route after the relay; using a relay doesn’t mean the connection uses a dedicated line. |
| IEPL | Usually refers to a route that uses an international Ethernet private line for part of the connection; it doesn’t mean the entire path from your device to the destination website is dedicated. | Which segments actually use the private line, and the network quality between the exit and the destination platform. |
IEPL is a transport method, not a proxy protocol, and it doesn’t automatically provide end-to-end encryption. A direct route may be shorter, a relay may improve reachability to the entry point, and a private line may reduce the impact of changes along the public internet. Actual performance still depends on your local network, available capacity, and exit conditions. For more, see route and protocol basics; for regional details, visit the server page.
Protocols: Check Compatibility, Then Network Conditions
A protocol defines how a client and server establish a connection, authenticate, and transmit data. Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC may all appear in proxy clients, but they aren’t interchangeable labels. The server must offer the protocol, the client’s core must support it, and the configuration parameters must be correct for a connection to work.
- Shadowsocks: An encrypted proxy protocol. Both ends need to support compatible algorithms and protocol versions. It isn’t the same as a TLS-secured web connection.
- VMess: A proxy protocol that requires matching authentication and transport settings. Client support can also vary depending on the transport in use.
- Trojan: Typically relies on TLS to protect traffic. Certificate verification and server name settings matter; don’t disable verification just to get a connection working.
- VLESS: Doesn’t provide data encryption on its own. It’s usually paired with TLS or another secure transport, so the name alone doesn’t tell you how a connection is protected.
- Hysteria2 and TUIC: QUIC-based protocols that depend on UDP reachability. On networks that restrict UDP, you may need to switch to another compatible transport.
“Supports UDP” and “uses UDP to create a tunnel” aren’t the same thing. The first can refer to whether a proxy carries an app’s UDP traffic; the second describes the transport between the client and server. Protocol names can’t replace real-world testing, nor do they guarantee a particular latency or bandwidth. This glossary doesn’t mean that every VPNQJ route supports all of these protocols; check your panel configuration for actual availability.
Routing Modes: Rules, Global, and TUN
Split tunneling routes requests through different exits according to a set of decisions. Rule mode can send traffic through a proxy, directly, to a block, or to a policy group based on domains, destination addresses, or other conditions; the available options depend on the client core. For everyday use, start with the rules configured for your service: proxy cross-border traffic where needed and route local services directly according to the rules.
Global mode typically sends requests handled by the client through the selected proxy policy. It can help you check whether a rule is failing to match, but “global” doesn’t necessarily mean every app on your device is covered. If only the system proxy is enabled, apps that ignore system proxy settings may still connect directly.
TUN is a way to capture traffic, not a routing policy alongside rules and global mode. It uses a virtual network interface to receive traffic, then the core handles routing and traffic distribution. Enabling TUN often involves system permissions, routes, and DNS settings. It can work with either rule or global mode, so it’s not simply a “more powerful global mode.”
Recommended starting point: Use the rule configuration made for your client. If a website behaves unexpectedly, switch to global mode temporarily for comparison. If it works there, check the rules and DNS first. If an app isn’t covered, check system proxy support or consider TUN instead of repeatedly switching nodes.
Client Setup: Import and Verify Your Configuration
The client is the software that runs your configuration; its core parses protocols and forwards traffic. Similar interfaces don’t guarantee identical features, and the same app may work differently across operating systems. Check the client download section in your user panel for the current recommendation, then follow the setup guides.
- Check compatibility. Confirm your operating system, client version, and subscription format. Don’t assume a configuration file intended for a different core will work as a universal file.
- Import and update. In the client, open the subscription or configuration import option and paste your personal link. Confirm that the node list appears correctly. If the import fails, first check that you copied the entire link rather than changing parameters you don’t recognize.
- Choose a region and policy. Select an exit in a region supported by your target platform. Make sure the policy group points to a working node; selecting a node won’t help if the active policy group still routes traffic through a different exit.
- Enable traffic capture. Follow the guide to configure the system proxy or grant permission for the VPN configuration. On desktop systems, also check that your browser uses the same proxy settings.
- Test real-world access. Check the target site, exit region, and local services that normally work. Success in a browser doesn’t mean other apps are covered, and a working website doesn’t guarantee that API requests will work too.
Windows and macOS clients may offer both system proxy and TUN modes, but permissions and settings vary. Android clients often capture traffic through the system VPN interface and may also offer per-app settings. On iOS, system network extensions and app capabilities affect where settings are found and how apps behave in the background; the setup isn’t identical to desktop. Follow the documentation for your current client rather than copying steps from another platform.
DNS and Exits: A Working Website Doesn’t Guarantee a Consistent Route
DNS translates domain names into destination addresses. A DNS leak is a common term for a situation where proxy traffic goes through the selected exit, but related DNS queries still use an unintended local route. This could expose the domains being queried or return results that don’t match the actual exit. However, seeing the name of a local resolver alone doesn’t prove that all your requests are leaking.
Troubleshooting should take into account the client’s DNS mode, the browser’s Secure DNS setting, system resolver settings, and actual query behavior. Some configurations resolve domain names on the proxy server, others resolve them locally before forwarding the resulting address, and some use resolution handled by the client core. Don’t disable all DNS features just to clear a warning, and don’t assume an unfamiliar public resolver is a universal fix.
- ✅ Check the client logs for the rule matching the destination domain, along with the policy and node ultimately selected.
- ✅ Check whether the browser has its own proxy or Secure DNS settings, and confirm they match the client’s configuration.
- ✅ Test IPv4 and IPv6 separately to make sure both are handled as expected.
- ❌ Don’t treat “node connected” as proof that the target platform supports that region. A cached page loading doesn’t prove the configuration is working either.
If a website says your region isn’t supported, first check the platform’s official supported regions, your current exit, and account requirements. If the page keeps loading, check the rules, DNS, and connection logs. If the connection drops after working for a while, look for changes in the local network, device sleep, or background restrictions. Separating these symptoms helps avoid blaming every issue on the route.
Plans and Data: Choosing After You Understand the Terms
A data allowance is the amount of data included in a plan, not its bandwidth or the number of devices that can be connected at once. Video quality, viewing time, file transfers, and app updates all affect usage, so a plan’s data allowance alone can’t tell you exactly how long you can stream. A client’s momentary speed reading is no substitute for judging stability over actual use.
VPNQJ monthly plans: ¥9.9/month for 60GB, ¥18/month for 250GB, and ¥28/month for 500GB. Monthly data resets on the same day each month as the activation date. Data add-ons cost ¥158 for 300GB, ¥358 for 1000GB, and ¥658 for 3000GB, and never expire. Check the plans page for billing and usage rules; a monthly data reset doesn’t mean a data add-on expires.
VPNQJ has no device limit, requires no email address to create an account, and offers a 14-day no-questions-asked refund. An unlimited device count doesn’t mean every device automatically shares the same local configuration; you’ll still need to import and verify settings on each one. Beginners will find it easier to pinpoint issues by first getting rules, exits, and DNS working consistently on their main devices, then adding others.
Remember this configuration chain: The subscription provides configuration, the client applies it, the node is the connection endpoint, the route defines the network path, the protocol defines how devices communicate, and routing rules determine where requests go. When something goes wrong, check each link in turn. Verify the target platform’s regional policies and account restrictions separately.