This beginner’s VPN glossary puts subscriptions, nodes, routes, protocols, and split tunneling in context. A subscription provides configuration, a node is a connection endpoint, a route describes the network path, a protocol defines communication, and routing rules determine where requests go. When a connection fails, identify which layer is at fault before changing settings.
How subscriptions, nodes, and clients work together
A client is software running on your device that reads configuration, establishes connections, and handles traffic. A node is usually a set of connection details, potentially including a server address, port, credentials, protocol, and transport options. A region in a node’s name is only a label; check the actual exit region after connecting.
“Subscription” commonly means two different things. On a plan page, a monthly subscription is a billing option. In a client, a subscription is a source for configuration, usually provided as a subscription link. A node subscription lets the client manage multiple nodes and related settings. Importing a link doesn’t connect you; you still need to select a node, enable a mode, and test the service you want to use.
| Term | What it does | Common point of confusion |
|---|---|---|
| Client | Reads configuration and handles device traffic | Installing the app doesn’t mean configuration or connection is complete |
| Subscription link | Gets service-provided nodes or configuration updates | It’s neither an ordinary shared URL nor a billing period |
| Node | Specifies a connectable server and its authentication parameters | Nodes in the same region don’t necessarily use the same exit or route |
| Route | Describes the combination of entry point, transit path, and exit | A route name alone doesn’t tell you its actual speed |
| Protocol | Defines how the client and server communicate | A protocol name isn’t a service-quality ranking |
| Traffic routing | Determines whether a request connects directly, uses a proxy, or is blocked | An active connection doesn’t mean every app is routed through the proxy |
How to get, import, and update a subscription link
A subscription link usually contains access credentials associated with your account. When a client requests the link, it receives configuration in a format it can read. Different clients may use different subscription formats, so choose the appropriate option in the user panel rather than pasting any link into any app.
- Go to the user panel, check your plan status, then get the subscription link for your client.
- Open the subscription or configuration section in your client and use the appropriate option, such as “Import from URL.” Don’t paste the link into a field for an individual server address.
- Update the subscription and check whether the nodes appear. If you see a format error, first confirm that the subscription format is supported by your client.
- Select a node and connect, then visit the service you need and check that pages load, sign-in works, and the connection stays stable.
- Update the subscription after node changes. Whether automatic updates can run in the background depends on the client and operating system restrictions.
Updating a subscription refreshes the configuration provided by the service, but it won’t fix an expired plan, a disconnected network, or an incompatible client. Likewise, seeing nodes in the list doesn’t mean your account access is still valid. Troubleshoot import failures separately from connection failures; there’s no point adjusting routing rules before configuration is available.
IEPL routes, relays, and direct connections
Here, a “direct route” usually means your device connects to an overseas proxy entry point over the public internet. A “relay route” connects to an intermediary first, which then forwards traffic to another server. An extra hop isn’t necessarily slower: a relay can improve the experience if its entry point is more reachable or the onward route is more stable.
IEPL stands for International Ethernet Private Line. When a service uses one for part of a cross-border route, that segment differs from forwarding over the regular public internet. The path from your device to the service entry point, and from the exit to the destination website, may still use other networks. An IEPL label doesn’t mean the entire end-to-end path uses a private line or that a destination website will allow access.
To assess a route, check whether you can reach its entry point, whether it drops during peak hours, whether its exit region suits the destination service, and whether your apps work reliably. If the connection test succeeds but a website denies access, the issue may involve exit-region detection or the destination’s policies—not necessarily a failed route.
A protocol name isn’t a speed ranking
Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC may all appear in proxy client configurations, but they differ in authentication, encryption, and transport design. Whether a configuration imports and connects depends on the client’s core, version, and settings—not just the protocol name shown on a node.
- Shadowsocks: An encrypted proxy protocol that requires compatible encryption methods and authentication settings on the client and server.
- VMess: A proxy protocol with authentication and encryption mechanisms, often paired with different transport methods. An incorrect system clock can also affect connections.
- Trojan: Typically protects communications with TLS. The domain, certificate, and server name settings need to match.
- VLESS: A lightweight proxy protocol that doesn’t encrypt data on its own. Security depends on an outer layer such as TLS; the name itself doesn’t guarantee encryption.
- Hysteria2 and TUIC: QUIC-based proxy protocols that rely on UDP connectivity. If your network restricts UDP, check transport availability first.
These are general technical concepts, not a list of protocols supported by VPNQT. Protocol, transport layer, and route are separate dimensions. Changing protocols may address compatibility issues, but it won’t automatically resolve congestion. Beginners should use configurations provided in the panel and official instructions. Don’t disable certificate verification or remove security-related settings just to get connected.
Traffic routing, global mode, and rule mode
Traffic routing uses conditions to determine where requests go. Rules may use domains, destination addresses, processes, or other information to send traffic through a proxy, connect directly, or block it. Rules typically have a matching order, and earlier matches can determine the outcome. Adding a rule after one that already matches the request may have no effect.
Rule mode lets different services use different routes, but rule sets may be outdated or cover website domains without accounting for other app requests. If a page loads but its images or sign-in page don’t, check whether those requests use a different exit instead of assuming the node is completely down.
Global mode typically sends requests handled by the client through the selected proxy, making it useful for temporarily troubleshooting routing rules. The key limitation is “handled by the client”: global mode may not affect apps that don’t use the system proxy or aren’t routed through a virtual network interface. The system proxy is mainly for apps that respect that setting. TUN mode uses a virtual network interface to handle more traffic, but is still subject to system permissions, routes, and exclusions.
Use rule mode to route traffic based on your needs and global mode to check whether rules are causing a problem. If access works after switching to global mode, investigate the rules rather than assuming global mode is more advanced or always more reliable.
Understanding DNS resolution and leaks
DNS translates domain names into network addresses. A proxy connection may be active while DNS lookups still go through your local network. If that differs from the expected resolution path, it can result in what’s commonly called a DNS leak. This describes the route taken by DNS requests; it doesn’t prove that all your browsing activity has been read.
Browsers, operating systems, and clients may each have their own secure DNS or resolver settings. Using encrypted DNS in a browser doesn’t automatically route DNS requests through a proxy. Likewise, configuring remote DNS in a client doesn’t mean every app uses it. Check how DNS requests are routed, whether apps resolve names themselves, and whether the client handles their traffic.
For troubleshooting, compare your exit IP and DNS test results before and after connecting, but the resolver’s location doesn’t have to match the proxy exit exactly. Public resolvers may use distributed infrastructure, and geolocation databases used by test pages can be inaccurate. Check client logs to confirm the request path and review bypass rules instead of relying only on the country shown on a test page.
Client and permission differences across platforms
Windows clients commonly offer system proxy and traffic-handling options such as TUN. If the system proxy isn’t working, first check whether the app follows proxy settings. If TUN won’t start, check permissions, drivers, and conflicts with other network software. On macOS, distinguish proxy settings from network extension permissions; the menu bar icon alone doesn’t confirm that traffic is being routed.
iOS and Android generally use the system VPN interface to create a traffic-handling tunnel, but supported protocols, subscription formats, and background behavior vary by app. A VPN icon in the system UI means the tunnel is enabled; it doesn’t guarantee access to a particular service. Other VPN configurations, battery management, and background restrictions can also affect connection stability.
When using a graphical client or command-line tool on Linux, also check the service process, routing permissions, and desktop proxy settings. Don’t assume a terminal app inherits your browser’s proxy configuration. VPNQT provides access for Windows, macOS, iOS, Android, and Linux. For setup and configuration, refer to the panel download page and Quick Start.
Troubleshoot one layer at a time instead of switching nodes repeatedly
- ✅ No nodes listed: Check the subscription link, account status, format, and client compatibility.
- ✅ Nodes appear, but connection fails: Check your local network, authentication settings, system clock, and transport connectivity.
- ✅ Connected, but the destination won’t load: Check the exit region, routing results, DNS path, and any message from the destination service.
- ✅ Browser works, but other apps don’t: Check whether those apps use the system proxy or are covered by TUN.
- ✅ Intermittent disconnections: Note the time, node name, client version, and error message, then compare route performance.
When contacting support, submit redacted logs and steps to reproduce the issue through a support ticket in the user panel. Describing which app and action failed is more useful than simply saying “it doesn’t work.” Redact subscription links, authentication fields, and personal content from logs first.
When comparing plans, distinguish billing from configuration. VPNQT monthly subscriptions reset data each month on the activation date, while data add-ons never expire. There’s no limit on the number of devices connected at the same time, but each device can still use data. No email address is required; a username and password are all you need. The refund policy allows a no-questions-asked full refund within 60 days of the first payment. Check the plans page for current prices and data allowances.
A subscription gives configuration to the client, the client connects to a node using a protocol, the route carries traffic, and routing rules decide which requests take that path. Troubleshooting in that order helps separate format errors, network problems, and restrictions imposed by the destination service.