This complete beginner’s guide to VPN subscriptions, nodes, and routing terms follows the full path from a browser request to client rule matching, route forwarding, and the destination website’s response. Once you understand that chain, you can identify which step to check when a subscription update fails, a selectable node cannot open a page, or you are unsure how global mode differs from rule-based mode.
Industry terminology often mixes accounts, subscriptions, nodes, routes, and protocols. Although they all relate to connectivity, each has a different role: the account determines whether you can obtain service configuration, the subscription distributes that configuration, a node identifies an available entry or exit, the protocol defines how the client and server exchange data, and routing rules decide which requests follow that path. One working component does not mean the others are working normally.
Understanding the full path of a website request
Without a proxy or VPN service, a browser typically sends the domain to the DNS resolver configured by the system, obtains the destination address, and then connects directly through the local network. Once a client is enabled, the request may first be handled by the system proxy, a virtual network interface, or an application proxy, then sent directly or forwarded according to routing rules. Traffic that needs forwarding is wrapped by the selected protocol and sent to a node or relay entry before reaching the destination service.
The response travels back to the client in the opposite direction. After decapsulation, the client passes it to the browser or application. Whether a page opens depends not only on the subscription configuration and node status, but also on the local network, DNS results, destination-site policies, device time, client permissions, and route quality. A node marked as selectable only means its configuration appears in the list; it does not confirm that the entire access path works.
| Term | Primary role | Do not confuse it with | Where to check |
|---|---|---|---|
| Account | Provides access to plans, subscriptions, and client entry points | A specific node or protocol | Account panel and plan status |
| Subscription | Distributes nodes and related configuration to the client | A continuously running network connection | Subscription update time and import result |
| Node | Provides a connection configuration the client can select | A performance guarantee covering the entire physical route | Region, protocol, and connection logs |
| Protocol | Defines data encapsulation, authentication, and transport | The country or region where a node is located | Client support and server configuration |
| Routing rules | Decide whether a request connects directly, is forwarded, or is rejected | The route’s speed tier | Rule-based mode, match logs, and DNS settings |
During troubleshooting, narrow the scope one layer at a time along the data path. If a subscription cannot update, start with the account and subscription URL. If the configuration imported but the node fails to connect, check protocol compatibility, device time, and the local network. If the node connects but only some websites fail, focus on DNS, routing matches, and the destination service instead of repeatedly importing the subscription.
A subscription link is not an ordinary download URL
A subscription is typically an address that a client can read. After requesting it, the client receives configuration such as node names, server addresses, ports, authentication details, protocol parameters, or rule providers, then converts that content into a selectable configuration list. Clients may accept different subscription formats, and the same address may not be recognized directly by every client.
A subscription link is closer to a credential for continuously obtaining configuration than to a webpage URL meant for public sharing. Pasting it into public searches, screenshots, or logs could expose connection settings associated with your account. If a subscription is leaked, look for a reset option in the service panel instead of merely deleting the local record from the client. Removing local configuration does not automatically invalidate a leaked address.
What to check before and after importing
- ✅ Get the subscription entry from the account panel and confirm that the current plan is active.
- ✅ Confirm that the client supports the subscription format; do not infer compatibility from the protocol name alone.
- ✅ After importing, check that node names, regions, and the update time appear as expected.
- ✅ If an update fails, record the client message and distinguish a network request failure from a format parsing failure.
- ✅ After connecting, verify website access, the DNS path, and routing results separately.
- ❌ Do not paste the subscription URL into public testing sites, forum posts, or shared screenshots.
- ❌ Do not treat a successful import as proof that the route is working.
Updating a subscription does not necessarily replace every local setting. Some clients retain manual rules, proxy-group selections, or application permissions, while others rebuild parts of the configuration from the remote source. If you made complex changes, check whether the client supports local overrides, configuration backups, or rule merging before updating. The exact behavior varies by client implementation and cannot be generalized across platforms.
Nodes, entries, exits, and route types
A “node” is usually a selectable configuration in the client list, but it does not necessarily correspond to one physical server. A name may represent an access entry, a service cluster after load distribution, or a logical route that reaches an exit through a relay. Region labels generally indicate the access or exit location, but the exact meaning depends on the provider’s route documentation.
The entry is where the client first establishes a connection; the exit is the network location from which the request appears to leave toward the destination website. A direct route usually means the client connects directly to the service entry, while the middle of the path may still use a carrier’s ordinary internet network. It does not mean there are no routing hops between the two ends. A relayed route first connects to a relay entry and is then sent through the relay network to the exit, helping adjust the cross-network path or connection stability.
How to distinguish IEPL, dedicated routes, relays, and direct connections
IEPL refers to a commercial communications product associated with international Ethernet private lines, commonly used for cross-border enterprise network connectivity. Subscription services sometimes use “IEPL” to describe route resources or one section of a transmission path, but the label alone cannot reveal the full topology, whether resources are dedicated, or how much congestion exists. It is not an encryption protocol and cannot replace authentication and encryption between the client and server.
A dedicated route should not be assumed to be faster at every hour. Experience still depends on local access, entry load, exit networks, the destination service, and route changes. Relays are not inherently better than direct connections either: when the local path to a direct entry is suitable, an extra relay may be unnecessary; when cross-network routing is unstable, a relay may offer a better path. Compare options on the same device, for the same destination, and at similar times.
| Type | Common meaning | What to observe | What it does not prove |
|---|---|---|---|
| Direct | The client connects directly to the service entry | Whether the handshake succeeds and the route remains stable | The physical path is shortest or latency is always low |
| Relay | Connects to a relay entry first, then forwards traffic to the exit | Cross-network routing and fluctuations during peak hours | It is better than a direct connection in every network environment |
| IEPL label | Usually indicates that the route uses related enterprise private-line resources | The provider’s explanation of the entry, exit, and intended use case | It is equivalent to a protocol or guarantees a certain speed |
What common protocols are designed to do
Protocols define how the client and server authenticate, encapsulate, and transmit data. Nodes in the same region may use different protocols, and the same protocol name does not guarantee identical parameters, transport layers, or client implementations. Before choosing a protocol, confirm that the server provides the corresponding configuration and that the client supports the same protocol and parameter combination.
Shadowsocks
Shadowsocks is an encrypted proxy protocol family commonly used to forward supported network traffic to a remote server. It is not the same as a traditional VPN that takes over all system traffic; coverage depends on whether the client uses the system proxy, a virtual network interface, or an application proxy, and whether UDP, DNS, and routing settings are aligned.
VMess and VLESS
VMess is common in the V2Ray ecosystem and includes authentication and transport settings between the client and server. VLESS uses a more streamlined protocol design and is often combined with TLS, Reality, or other transport methods. The protocol, transport, and security layers are separate concepts, so when importing a configuration, do not focus only on “VLESS” and overlook the service name, certificate verification, transport method, and other parameters.
Trojan
Trojan typically carries proxy traffic over a TLS connection, with server name, certificate verification, and password authentication commonly appearing in its configuration. Whether TLS establishes correctly depends on the domain, certificate, device time, and client implementation. Disabling certificate verification can hide configuration errors and should not be treated as a routine troubleshooting method.
Hysteria2 and TUIC
Hysteria2 and TUIC both commonly use QUIC-based transport capabilities and are designed for situations with high latency, packet loss, or network fluctuations. They usually depend on UDP reachability; if the local network restricts UDP, handshakes may fail or performance may degrade. Design choices intended for unstable networks cannot eliminate physical distance, bandwidth limits, or destination-service restrictions.
Protocol selection should not be based only on whether a protocol is “new” or “old.” More reliable factors include whether the local network permits the transport, the client’s maintenance status, system permissions, connection logs, and the destination. If the service panel provides a recommended configuration, start with its defaults for basic verification before changing the protocol or transport parameters. This reduces misdiagnosis caused by changing several variables at once.
Routing rules, global mode, and rule-based mode
Routing takes place before a request is sent. After reading the domain, destination address, application source, or rule set, the client chooses an action such as proxying, connecting directly, or rejecting the request. Rule-based mode is not intended to make a route automatically faster; it sends different destinations through appropriate paths while keeping local services, LAN devices, and resources that do not need forwarding from taking an unnecessary remote route.
Global mode usually means that the client sends as much of the traffic it controls as possible through the proxy path, but the scope of that control varies by platform and client. Some implementations affect only applications that follow the system proxy; others handle more traffic through a virtual network interface, while some still preserve exceptions for LAN access, system services, or specific protocols. Global mode therefore should not be understood to mean that every piece of data necessarily passes through the same node.
Rule-based mode matches rules in order. Domain rules classify destinations by site name, address rules handle resolved destination addresses, and application rules choose a path based on the software making the request. If an earlier rule is too broad, later detailed rules may never match. If DNS resolution and routing decisions use different paths, a domain rule may appear correct while the actual connection uses the wrong exit.
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-SUFFIX,intranet.example,DIRECT
MATCH,PROXYThe examples above only illustrate matching order; they are not universal configurations that can be imported into every client. Clients may use different action names, rule syntax, and priorities. Read the client documentation before making changes and keep a restorable copy of the original configuration.
- ✅ First confirm whether the client is actually in global mode or rule-based mode.
- ✅ Use connection logs to see whether the destination domain matched a proxy, direct, or reject rule.
- ✅ Check whether LAN resources and local services need to remain on a direct connection.
- ✅ After updating rules, start a new connection instead of treating an old connection result as evidence of the new rules.
- ❌ Do not switch nodes and routing rules at the same time, or it will be difficult to tell which change took effect.
- ❌ Do not overwrite the existing configuration by copying a large rule set from an unknown source.
DNS leaks and “connected but unable to open pages”
A DNS leak generally means that domain queries are sent outside the expected resolution path, allowing the local network resolver or another unintended resolver to see them. This is related to, but distinct from, whether data traffic passes through a node: a webpage connection may use a proxy while domain queries still go through the local network, or DNS may use a remote resolver while routing rules send the final connection directly.
Enabling encrypted DNS alone does not mean that queries will use the same exit as the proxy. Encrypted DNS mainly protects the query in transit; which resolver handles it and which network exit sends the request still depends on the system, browser, and client settings. Some browsers have an independent secure DNS feature that may bypass the system resolution path, while some clients take over DNS and choose local or remote resolution according to routing rules.
DNS results can also affect routing decisions. Some destination services return different addresses based on the resolver, and stale cached results may continue to be used. During troubleshooting, first confirm whether the client controls DNS, then check whether the browser has its own resolution settings. Clear the necessary caches and establish a new connection. Do not rely on a single test page, because it can show only the queries it triggered and the exit used at that moment.
“An address works but its domain does not” usually points more toward DNS; “the domain resolves but the connection times out” may involve routing, the protocol, the port, or the destination service. If only a particular application behaves abnormally, check whether it follows the system proxy, uses its own DNS, and has the network permissions the client requires.
Windows, Android, iOS, macOS, and Linux: client differences
Platforms manage system proxies, virtual network interfaces, background operation, and certificate storage differently, so the same subscription may behave differently across clients. VPNKX supports Windows, Android, iOS, macOS, and Linux. The account panel determines the available client entry points and download access associated with an active plan.
| Platform | Common traffic-handling method | Check first |
|---|---|---|
| Windows | System proxy or virtual network interface | Leftover proxy settings, network interfaces, the system firewall, and whether applications follow the proxy |
| Android | System VPN interface or application proxy | VPN permission, background restrictions, per-app routing, and battery policies |
| iOS | System network extension and VPN configuration | Configuration authorization, on-demand connection, system network changes, and client status |
| macOS | System proxy, network extension, or virtual interface | Network-extension authorization, leftover system proxy settings, and DNS configuration |
| Linux | Environment proxy, desktop proxy, or virtual interface | Startup permissions, routing tables, DNS management services, and terminal environment variables |
On desktop platforms, browsers, terminals, and standalone applications may read different proxy settings. For example, a browser may work while a terminal command fails; this does not necessarily indicate a node problem, as the terminal may simply not inherit the proxy environment. On mobile platforms, common issues include system permissions, background restrictions, or a tunnel that does not recover correctly after a network change. Linux distributions and desktop environments vary widely, so after importing successfully, confirm that the routing table and DNS management components update as expected.
When moving between platforms, avoid manually copying every advanced parameter. A more reliable approach is to obtain the entry for the relevant platform from the account panel, import the subscription again in the new client, and restore only the routing settings you actually need. If an error is unclear, continue troubleshooting with the client logs and the troubleshooting handbook.
How beginners can complete their first verification
During first use, the goal is not to build the most complex rule set immediately, but to establish a basic path that can be tested repeatedly. Confirm that the local network works normally, then sign in to the account panel to obtain the client and subscription. After importing, keep the default configuration, choose a region that matches the destination, and check whether the client completes its handshake. Then verify websites, DNS, and the applications you need separately.
- ✅ Confirm that the local network can access commonly used services normally with the client disabled.
- ✅ Create or access a VPNKX account with a username and password; no email address is required.
- ✅ Get the client and subscription for the relevant platform from the panel; do not use configuration from an unknown source.
- ✅ After importing, keep the default protocol, DNS, and routing settings for the initial connection test.
- ✅ Choose a region based on the destination and confirm that the actual exit matches expectations.
- ✅ Test the browser or application you need and record which step produces the problem.
- ❌ Do not change the protocol, node, DNS, and rule set simultaneously before the basic connection has been verified.
Once the basic configuration works, adjust routing rules or compare routes based on your needs. If a change causes a problem, return to the last working configuration and change only one variable. This approach is more deliberate than switching every option repeatedly, but it makes the real cause easier to identify.
VPNKX offers regional choices covering 110+ countries and 160+ routes, and an account can be used on an unlimited number of devices. The number of regions expands your options; it does not mean every route produces the same result on every local network or destination service. Route information is a reference for selection, while actual access should still be tested on the current network.
Once you understand these terms, you can turn common issues into clearer checks: subscription issues concern configuration delivery, node issues concern entry and exit, protocol issues concern compatibility and parameters, routing issues concern rule matches, DNS issues concern the resolution path, and platform issues concern how the system handles traffic. To review account access, client installation, and the basic connection sequence, continue with Quick Start.