This VPN glossary for beginners starts with the client interface: a subscription provides configuration, a node is a connection endpoint, a protocol defines how data is exchanged, and routing determines where requests go. These are separate functions, not one setting. Understand each role before checking imports, connections, and access results, so you don’t blame every problem on a “bad node.”
Quick glossary: from account to web request
People use “VPN” to mean either a system-level virtual private network or, more broadly, a proxy service with international routes. Similar names don’t mean the services work the same way. To see which traffic software actually handles, check the system proxy, tunnel interface, and routing configuration—not just the app’s name or connection icon.
| Term | What it means | Common point of confusion |
|---|---|---|
| Service subscription | The service and data allowance associated with an account. | Different from the subscription link used to import a configuration. |
| Subscription link | An address a client uses to retrieve nodes or configuration; it may contain credentials. | Not a regular website URL or a public sharing link. |
| Node | A connection configuration containing details such as a server address, port, and authentication. | The displayed region doesn’t reveal the full traffic route. |
| Protocol | The communication rules followed by the client and server. | A protocol name is not a service tier or a speed guarantee. |
| Proxy group | A group of nodes or handling options that rules can use. | Changing one group doesn’t necessarily change the selection in other groups. |
| Routing rule | A condition that determines how a request is handled based on its domain, address, or other criteria. | Rule mode doesn’t mean every international website will automatically use the proxy. |
| System proxy | Provides a proxy endpoint for apps that follow the system proxy settings. | Doesn’t guarantee that every app on the device is routed through it. |
| TUN mode | Receives and processes traffic through a virtual network interface. | Its actual coverage still depends on permissions, routes, and exclusions. |
| DNS | The lookup process that resolves a domain name to a network address. | Routing web traffic through a proxy doesn’t mean DNS queries use it too. |
A typical web visit involves several steps: an app sends a request, the system or client handles DNS resolution, a rule selects a direct or proxied route, and a proxy request travels through a node to the destination website. This is a simplified model. Caching, remote DNS resolution, and differences between client cores can change the exact order.
Subscription links and importing into a client
“Subscription” can mean different things. On a plan page, it refers to billing; in a client, it usually means an updatable source of configuration. A link may return only nodes or include proxy groups, rules, and DNS settings. A successful import means the client could read the content—not that every route has been tested and works.
Client apps don’t all accept the same formats. The same link might return a list of nodes or a configuration file designed for a particular core. Don’t judge compatibility by the file extension, and never submit a link containing credentials to an unfamiliar website just to convert its format.
- Get the configuration for your client from the service’s account page, then confirm your platform and import method.
- Find the subscription, configuration, or import option in your client. Paste the link, refresh it, and check that nodes and configuration names appear.
- Review the imported mode, proxy groups, and DNS settings. If the configuration includes an automatic selection group, check which nodes it actually uses.
- Choose a node and enable the traffic handling method you need. Then test the target website instead of relying on the connection button alone.
- If an update fails, identify whether it’s a download, authentication, or format error. Then check your network, link validity, and core compatibility accordingly.
Treat your subscription link like an account credential. Hide the full address and any tokens in screenshots, public support tickets, and shared documents. If it’s exposed, use the service’s reset option or contact support through your account.
Also distinguish between refreshing a subscription and updating rules. Some configurations deliver rules with the subscription; others refer to separate rule resources. If nodes refresh but websites still take the same route, the rule resource may be out of date—or the app may still be reusing an existing connection.
Nodes, IEPL routes, relays, and direct connections
A node is a connection configuration you can select in a client; it doesn’t necessarily correspond to a separate physical server. Several names may share an entry point, and the entry region may differ from the exit region. Websites usually see the exit IP, so when checking regional access, consider the exit location and the website’s own policies—not just the node name.
Direct connections and relays describe traffic routes
In routing terminology, a direct connection usually means the client connects straight to an overseas service entry point. A relay connects to a forwarding point first, which then sends traffic to the exit. A relay may improve one part of the route, but it can also add detours or congestion. An extra forwarding step isn’t automatically slower or more reliable.
“Direct” in a rule is a different concept: it means a request goes to its destination without a proxy exit. When you see the term, first check whether it describes the service’s route or how the client handled a particular request.
IEPL doesn’t guarantee a dedicated route for the entire connection
IEPL usually refers to an international Ethernet private line. An IEPL route advertised by a provider may cover only part of the transmission between an entry and an exit point. The network from your device to the entry point, and from the exit point to the destination website, has its own conditions. IEPL is a different category from application-layer protocols, and the label alone doesn’t guarantee low latency, fixed bandwidth, or streaming access.
How to choose: First check whether the target website is reachable and whether the connection is stable when you use it. Then consider the route label. Region, traffic path, and protocol are separate factors; “private line” or “direct” alone can’t tell you what the full experience will be like.
Protocol names and client core compatibility
Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC may all appear in proxy client configurations, but they aren’t interchangeable options. The client must match the server’s authentication, encryption, transport, and security-layer settings. Changing a protocol name won’t convert an existing node to another protocol.
- Shadowsocks: Part of an encrypted proxy protocol family. The client must support the specific encryption method used by the server. Simply confirming “Shadowsocks support” doesn’t mean every configuration is compatible.
- VMess and VLESS: These are different protocols. VLESS doesn’t provide transport encryption on its own and is usually paired with an appropriate security layer. Don’t confuse identity verification with encryption of the connection.
- Trojan: Usually carries proxy traffic over a TLS connection. Certificate validation and server name settings can affect the connection; disabling certificate checks shouldn’t be treated as a routine fix.
- Hysteria2 and TUIC: Both use QUIC-based approaches and rely on UDP. If your local network restricts UDP, a connection may not be possible; that doesn’t mean your account is invalid.
The app interface is the shell; the core parses configuration and establishes connections. Different versions of the same app may also support different features. If you see errors such as “unsupported protocol” or “unknown field,” check the core and configuration format before assuming the route is at fault.
These are general technical concepts; they don’t mean VPNPast supports every protocol listed or configurations for every third-party client. Check the download options and configuration instructions in your account, along with your client’s compatibility.
Routing, rule mode, and global mode
Routing assigns requests based on conditions. Common outcomes include connecting directly, sending a request to a proxy group, or rejecting the connection. Rules may use domains, destination addresses, processes, or other information, depending on the client core and operating system permissions.
Many clients check rules in order: the first matching rule determines where a request goes, and unmatched requests go to a final handling option. Putting a broad rule before a more specific one can prevent the specific rule from taking effect. Check the syntax for your current core before making changes; don’t paste rules from a different client without adapting them.
Global mode doesn’t mean the entire device is routed through the client
Rule mode routes requests according to the configuration. Global mode usually sends requests that have already reached the client to its global proxy group. The key is “already reached the client”: if an app ignores the system proxy, its requests may never reach the proxy core, so switching to global mode may make no difference.
TUN mode can extend the range of traffic handled, but routing, permissions, and exclusions still apply. On mobile, a system VPN indicator usually means the app is using the system tunnel interface; it doesn’t by itself tell you which protocol is being used internally.
- ✅ A website works, but an app doesn’t: first check whether the app follows the system proxy or needs tunnel-based traffic handling.
- ✅ The exit stays the same after switching nodes: check which proxy group handles the request, rather than only changing the node displayed on the home screen.
- ✅ Global mode works, but rule mode doesn’t: check the matched rule, final handling option, and DNS results to narrow down the configuration issue.
- ❌ Changing nodes, DNS, rules, and the core all at once: too many variables change together, making the cause hard to identify even if things start working again.
DNS leaks and platform differences
A DNS leak occurs when a DNS query that should follow a privacy or routing policy is sent through an unexpected route or resolver. Seeing a proxy IP as the web exit doesn’t prove that DNS followed the intended route too. Conversely, a test page showing a resolver’s region isn’t enough on its own to prove a leak; you also need to check how that resolver was reached.
Encrypted DNS in the browser, the system resolver, the client’s built-in DNS, and cached results may all be involved. When troubleshooting, check which DNS requests the client handles and whether the browser bypasses the expected settings. Encrypted DNS protects queries in transit to the resolver, but doesn’t automatically make DNS and web requests use the same exit.
On Windows and macOS, distinguish between the system proxy and virtual interface permissions. iOS and Android generally use system-provided tunnel interfaces to handle traffic, while per-app routing and other features vary by OS and client. Linux may also involve desktop proxy settings, environment variables, system services, and routing configuration: command-line tools don’t necessarily inherit the browser’s desktop settings.
When switching devices, don’t assume the steps from another platform will apply. VPNPast supports Windows, macOS, iOS, Android, and Linux. See the setup guides for platform instructions, and get the client through the account downloads page.
Turn terminology into a troubleshooting sequence
When something goes wrong, describe what you see first, then identify the layer involved. If no nodes appear, start with the subscription download and format. If nodes appear but connections fail, check authentication, protocol, and network reachability. If the connection succeeds but websites won’t load, check routing, DNS, the exit, and the destination website’s restrictions. Connection tests and real-world usage may use different requests, so one can’t substitute for the other.
- Check the configuration source: Make sure you imported the right account’s configuration for your client. Don’t share credentials in support requests.
- Check where requests go: Review the destination, matched rule, and proxy group in the client’s connection log. Hide any personal information.
- Change one thing at a time: First try another node in the same proxy group, then test mode or DNS settings separately. Record the result each time.
- Test what you actually need: Open the website or app you use and check login, content loading, and connection stability—not just the test icon.
Bottom line: A subscription answers “Where does the configuration come from?” A node answers “Where does the connection go?” A protocol answers “How does it communicate?” Routing answers “Where does each request go?” Identify the layer first, then adjust the relevant setting. That’s more effective than repeatedly reinstalling the client.
Check your plan’s data and privacy policies separately from its technical settings. VPNPast follows a no-logs policy, lets you create an account with just a username and password—no email address required—and allows unlimited simultaneous connections. It also offers a 14-day money-back guarantee. These service terms don’t replace device permission controls or change a destination website’s own access rules.