This practical VPN glossary explains how the pieces fit together: a subscription provides configuration to your client, a node determines which access point you connect to, a protocol defines how data is exchanged, and routing rules decide which path each request takes. Understanding these layers helps distinguish a successful import from a working connection—and avoids changing unrelated settings when something goes wrong.
How VPN Clients, Subscriptions & Nodes Work Together
A client is the software on your device that handles connections, node selection, and routing. A subscription is usually the service’s way of providing configuration; the client reads it to get available nodes and their settings. A node is a set of connection details, which may include a server address, port, credentials, protocol, and transport settings. It does not necessarily correspond to a separate physical server.
People often use “VPN” as a catch-all term for network acceleration tools, but an application-level proxy is not quite the same as a system-wide VPN tunnel. Some proxy clients use the system VPN interface to route traffic; that does not mean their remote communication protocol is a traditional VPN protocol. To understand what traffic is covered, check how the client actually routes it rather than relying on the app’s name.
| Term | What it does | What it doesn’t tell you |
|---|---|---|
| Client | Reads configuration and handles connections and rules | Installing it does not mean a working connection has been established |
| Subscription link | Retrieves and updates configuration | A successful update does not mean every node is reachable |
| Node | Provides specific connection parameters | A region label does not prove that both the entry and exit points are there |
| Protocol | Defines how the client and server communicate | The protocol name alone does not indicate connection quality |
| Routing rule | Chooses whether a request is proxied, sent directly, or blocked | Having rules does not mean every app’s traffic is being routed |
Subscription Links & Importing Them into a Client
A subscription link is not a regular information page. It often contains credentials tied to your account permissions and returns a node list or client configuration. Being able to open the link in a browser does not mean your client supports the format it returns: some clients read a complete configuration, while others accept only node-sharing links. The two are not interchangeable.
“Update subscription” means fetching the configuration again. It does not renew a plan or reset data usage. After nodes change, an old configuration may still contain inactive addresses. If the update request itself fails, first check the network path used to fetch the configuration, the link’s status, and format compatibility—not whether every route is unavailable.
- Find the subscription link for your client in the service dashboard, then read the import instructions for your platform.
- Import it from the client’s subscription or configuration manager, and confirm that the configuration name and node list appear.
- Select the configuration and connect. Enable the system proxy or tunnel routing if needed.
- Visit the service you want to use, then check which rule matched and what exit address you’re using. Seeing “Import successful” is only one step.
Nodes, Entry Points & Exit Regions
The entry point is the service endpoint your device connects to first. The exit is the public address seen by the destination website. They may be in different regions. A region in a node’s name usually indicates the exit location, but names are only labels; check the service documentation and an exit-IP lookup to verify.
Nodes in the same exit region may use different entry points and network paths. Don’t choose a route based only on how close its region name sounds, and don’t assume a client’s latency test reflects the full experience on a website. A test may measure only part of the path to the node; loading a webpage also involves DNS resolution, remote response times, connection reuse, and the app’s own behavior.
The region assigned to an exit IP depends on the website’s IP geolocation database. It’s not unusual for a lookup page and a platform to show different regions. Streaming and AI services may also apply restrictions based on account region, billing details, and their own policies, so changing your exit location does not guarantee access. Use IP lookup to check basic exit information, but follow the target service’s own messages.
Dedicated Lines, Relays & Direct Connections
These terms describe network paths, not client protocols. A direct connection usually means your device connects to an overseas endpoint over the public internet. A relay routes traffic through one access point before forwarding it along another path. “Direct route” and “direct” in a routing rule mean different things: the former may still use a proxy service, while the latter usually means a request bypasses the selected proxy node.
IEPL usually refers to an international Ethernet private line, a dedicated carrier-provided link between locations. It may be used for only one segment of the overall route; it does not automatically cover the path from your device to the entry point or from the exit point to the destination website. Even if the dedicated segment performs well, your local network or the destination service can still cause slowdowns.
A dedicated line is not a privacy policy, a relay is not necessarily worse, and a direct connection is not necessarily faster. Ask where the entry point is, which parts of the route use a dedicated line, and whether it suits your current network; then test the services you actually use at your usual times. This article explains industry terms and does not imply that VPNVD offers every route type or protocol mentioned. Check the dashboard and server page for details about available configurations.
Common Protocols & Compatibility
A protocol defines how the two ends of a connection package, transmit, and verify data. Transport methods, encryption settings, TLS configuration, and authentication parameters often need to work together. Knowing a node’s protocol is not enough to build a working configuration by hand. If the client lacks the required core support, renaming the node won’t fix compatibility.
- Shadowsocks: An encrypted proxy protocol. Its security and compatibility depend on the version, encryption method, and implementation—not just the name.
- VMess: Common in the V2Ray ecosystem, with its own authentication and data protection mechanisms. If a connection fails, check that your device’s clock is accurate as well as reviewing the settings.
- Trojan: Typically uses TLS to protect data in transit. Certificate validation and server name settings matter; don’t disable certificate checks as a troubleshooting shortcut.
- VLESS: A lightweight proxy protocol that does not provide complete transport encryption on its own. Consider it alongside security layers such as TLS and REALITY in the configuration.
- Hysteria2: Based on QUIC and reliant on UDP. UDP restrictions, congestion control, and configuration compatibility can all affect connection performance.
- TUIC: Also uses QUIC transport. Support depends on the client implementation, and its settings are not interchangeable with Hysteria2’s.
TCP and UDP are transport-layer protocols, not synonyms for “secure” and “insecure.” UDP-based solutions can also provide encryption, and a network that allows UDP may still not suit every app. If you can’t connect, first check whether the current network allows the required transport, then verify the client version and complete configuration.
Split Tunneling, Rule-Based Mode & Global Mode
Split tunneling applies conditions to choose a route for each request. Common conditions include domains, destination addresses, app processes, and geolocation databases; common actions include proxy, direct, and reject. Rules are usually matched in the order defined by the client, but DNS resolution, rule-set expansion, and core implementation can affect the result. Rules from different clients are not necessarily equivalent.
Rule-based mode sends matching requests along different paths, making it useful for keeping local services and LAN traffic separate from international routes. Global mode usually sends requests captured by the client through the selected proxy group. It can help check for missing rules, but does not mean every bit of traffic on the device must go through a proxy.
Be sure to distinguish a “proxy group” from a “node.” A proxy group is a selection container: you can choose a node manually, or the configuration may select one automatically. In global mode, an automatically switching group can still change your exit location. For tasks that need a continuous session, check the group’s selection policy before deciding whether to pin a node.
If rule-based mode fails but global mode works with the same node, check which rule matched and how the domain was resolved. If both modes fail, continue by checking traffic capture, node connectivity, and restrictions from the target service. This comparison helps narrow down the cause; it does not diagnose the problem by itself.
System Proxy, TUN & Platform Differences
A system proxy tells apps that support the setting where to send proxy traffic; some apps may ignore it. TUN uses a virtual network interface to receive traffic and pass it through the client. TUN can cover more apps, but routing, exclusions, permissions, and the client implementation still matter. Turning it on does not automatically fix every problem.
Windows and macOS clients may offer separate system proxy and TUN switches. A browser proxy extension usually applies only to that browser; it does not mean desktop apps are covered too. Linux setups may also involve desktop proxy settings, app environment variables, and system routes. Check separately whether terminal programs use the proxy.
Android and iOS clients often use the system VPN interface to route traffic, but support for per-app routing, background connections, and specific protocols depends on system permissions and client capabilities. A successful import on desktop does not guarantee that a mobile client accepts the same format. Get the client from the dashboard’s download page, then follow the instructions for your platform.
DNS Leaks & Privacy Boundaries
DNS translates domain names into addresses. A DNS leak generally means that lookup requests expected to use a protected route are instead sent through another resolver. A changed exit IP alone does not prove DNS requests use the same route. Browser encrypted DNS, the system resolver, and the client’s DNS policy may all operate independently.
Encrypted DNS protects communication with the resolver, but does not automatically mean requests pass through the selected node. Some test pages show multiple DNS resolvers; their number alone does not prove a leak. Check whether the browser has independent DNS enabled, who operates the resolvers, and what route you expect requests to take.
HTTPS protects data in transit between an app and the destination site; a proxy or tunnel handles a separate layer of the connection path. They are not substitutes for each other. If you see a certificate error, stop before submitting sensitive information. Check your device’s clock, network sign-in page, and certificate chain rather than ignoring the warning to “fix” the connection.
Connection Troubleshooting Checklist
Troubleshoot one layer at a time, changing only one setting per test and noting what happens before and after. If you change protocols, nodes, and DNS all at once, even a successful connection won’t tell you what fixed the issue—and you’ll be back to guesswork next time.
- ✅ First, confirm your basic connection works with the proxy off. Rule out a local outage or an incomplete sign-in to a public network.
- ✅ Make sure the subscription updates, the configuration is selected, and your plan is active. Check configuration retrieval separately from node connectivity.
- ✅ Check whether the app is routed through the system proxy or TUN, and confirm the proxy group actually points to the expected node.
- ✅ Keep the node unchanged. Compare rule-based and global mode, then check which rule matched the destination request.
- ✅ Check the exit and DNS paths. When reporting an issue, include the error message and what you were doing, but hide credentials and the full subscription link.
- ❌ Don’t treat disabling certificate checks, importing unfamiliar configurations, or repeatedly switching lots of settings as routine fixes.
Keep this sequence in mind: the subscription provides configuration, the client runs it, the node connects to the service, the protocol carries communication, and the rules determine the route. Once you understand what each part does, the switches and messages in the client make it easier to pinpoint where things failed. For more setup help, see the beginner’s guide. If you need assistance, contact us and describe the checks you’ve already completed.