When getting started with a VPN, it helps to know what subscriptions, nodes, protocols, and split tunneling each do: a subscription provides configuration, a node is a connection endpoint, a protocol defines how data is exchanged, and split tunneling determines where traffic goes. They are different things and are not interchangeable.
In practice, the client reads your subscription, applies rules to send each request through a node, and then connects to the destination website through an exit server. When something goes wrong, checking each step in order is more useful than repeatedly switching apps. The sections below explain common terms in context without treating a protocol or route name as a guarantee of speed.
Subscriptions, Nodes, and Clients: How They Fit Together
| Term | What it means | Common misconception |
|---|---|---|
| Subscription link | An address a client uses to fetch nodes or configuration, usually containing account-specific credentials. | It is not an installer, and it does not mean you are connected. |
| Node | A connection profile a client can use, with details such as the server address, port, protocol, and authentication parameters. | A node name does not necessarily correspond to a dedicated server. |
| Route | The path data takes from the service to its destination, which may include an entry point, relay, and exit server. | The same exit region does not mean traffic follows the same route. |
| Client | Software that reads configuration, establishes connections, and routes traffic according to rules. | A running status in the app does not mean it is handling traffic from every application. |
| Exit IP | The source address a destination website sees for a request. | The exit server’s region may differ from the entry server’s region. |
| Rule | A condition based on a domain, address, or other criteria that determines whether a request goes direct, through a proxy, or is blocked. | Selecting a node does not mean every request will use it. |
“Subscription” can also refer to billing. A monthly subscription is a plan period; a subscription link is a technical way to retrieve configuration. Refreshing the link usually fetches configuration again—it does not renew a plan or reset data usage. Check your account dashboard for usage, expiration, and billing details.
A service may provide different formats for different clients. Some links return only nodes, while a full configuration may also include rules, DNS settings, and proxy groups. Before importing, use the entry provided for your client in the dashboard. Similar-looking links are not necessarily compatible.
Protocols and Encryption: The Name Doesn’t Determine Speed
A protocol defines how the client and server exchange data and authenticate a connection. Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC may all appear in proxy clients, but they are not interchangeable options. The client must support the protocol and parameters used by the server.
- Shadowsocks: An encrypted proxy protocol that requires a matching encryption method and key. It is not a traditional, device-wide VPN tunnel; device-wide routing typically relies on a virtual network interface provided by the client.
- VMess: Uses authentication and encryption and can work with different transport methods. The client must also correctly read the transport-layer settings, not just the protocol name.
- Trojan: Typically relies on TLS to protect communications. Certificate validation and server name settings must be correct; don’t disable verification just to get a connection.
- VLESS: Does not provide content encryption on its own. It should be understood alongside security layers such as TLS or REALITY and the relevant transport settings. Differences in protocol names are not a ranking of encryption strength.
- Hysteria2 and TUIC: Built on QUIC and rely on UDP transport. If your current network restricts UDP, the client may recognize the configuration but still fail to connect.
These are general concepts, not a statement that VPNQO supports every protocol listed. Check your account dashboard and client documentation for current support. Node performance also depends on your local network, congestion at the entry point, cross-border routing, exit server load, and the destination website—not just the protocol name.
The “core” is the part of a client that handles protocols and applies rules. Apps with similar names or interfaces may use different cores or versions. If you see errors such as “unknown protocol” or “unsupported configuration field,” check client compatibility first rather than deleting settings you don’t understand.
IEPL, Relay, and Direct Routes: What’s the Difference?
A route type describes the path data takes; a protocol describes how devices communicate. These are different layers: nodes using the same protocol can follow different routes, and an IEPL link does not mean every segment between your device and the destination uses a dedicated network.
Direct: Your device connects straight to an overseas entry server
A “direct route” usually means your device connects to an overseas server over your local carrier’s public network. The path is more direct, but performance can be affected by your carrier’s international gateways and public-network congestion. This is different from the “direct” action in routing rules, which usually means a request bypasses the proxy.
Relay: Traffic reaches an entry server before being forwarded to an exit
A relay route sends traffic to an entry server first, then forwards it to an overseas exit server. Relaying can change the route, but an extra forwarding step is not automatically faster or slower. The entry server, onward route, and peak-time load all matter; the “relay” label alone doesn’t tell you what performance to expect.
IEPL: An Ethernet private line is used along part of the route
IEPL stands for International Ethernet Private Line. An “IEPL route” typically means that this type of link carries some cross-border segment; check the service description for its exact scope. The connection from your device to the entry server, and from the exit server to the destination, may still use public networks. IEPL does not guarantee zero congestion, no packet loss, or permanent access to any platform.
For calls, look for a stable connection; for browsing, pay attention to response times; for large downloads, consider sustained throughput. Start with a route in the region you need and test it on your own network at the times you usually connect. Don’t assume a “dedicated line” is automatically best for every use, or rely on a single client test.
Traffic routing, global mode, and TUN: what's the difference?
Rule mode selects a route based on matching criteria, making it useful for mixed everyday traffic—for example, sending local services direct and routing domains that need an international exit through a proxy. Rules generally run in order: an earlier match may prevent later rules from applying. Requests that match no rule use the configuration’s final policy.
In a client, global mode usually means that traffic already reaching the client is sent through the selected proxy policy. It does not guarantee that the entire device is covered. If an app doesn’t use the system proxy, its requests may never reach the client, so global mode cannot route them.
TUN is a virtual network interface that can bring traffic from more apps into the client. It is neither a protocol nor the same thing as global mode. TUN can be used with rule mode: traffic first enters through the virtual interface, then rules determine where it goes. System permissions, routing, and exclusion settings affect which traffic is covered.
Android and iOS clients often use the system-provided VPN interface to route traffic, so the status bar may show a VPN icon. That does not prove the underlying connection uses a traditional VPN protocol. On Windows, macOS, and Linux, traffic may enter through different mechanisms, such as the system proxy or TUN; available features depend on the app.
DNS, exit IP, and leak testing
DNS translates domain names into addresses, which is a separate step from connecting to a website. DNS requests may come from the operating system, browser, or client. Routing a website through a proxy does not guarantee that its DNS request takes the same path.
A DNS leak usually means DNS requests did not follow the intended tunnel or proxy route and instead went to an unintended resolver. If your rules explicitly send local domains to a local resolver, seeing one is not necessarily a problem. Check what your configuration is designed to do before treating a resolver in a different region as evidence of a leak.
Encrypted DNS in the browser, system DNS settings, and DNS handling in the client can affect one another. When troubleshooting, start with the combination recommended in the client documentation and avoid changing multiple settings at once. Encrypted DNS protects DNS traffic in transit; it does not automatically change your web traffic’s exit route or act as a proxy connection.
To check your exit, open this site’s IP lookup page and review the exit information for that web request. This does not prove that other apps, DNS requests, or another address family follow the same route. If your network supports IPv6, also check how the client handles or blocks IPv6 rather than ending the test after checking IPv4 alone.
A website’s reported region can also be affected by IP database updates, account region, cached data, and location permissions. A changed exit IP does not change the region associated with your account, nor does it guarantee that a destination platform will allow access. Check the actual page and client logs together.
Import a Subscription and Verify the Connection
Once you understand the terminology, follow these steps to make your first connection. Menu names vary between clients, but the overall process is similar. Get the client download from the user dashboard, and see the Guides for platform-specific instructions.
- Check client compatibility. Confirm your operating system, the protocols your client supports, and the subscription format provided in your dashboard. Downloading the app does not automatically add a connection configuration.
- Import the right subscription. Use the import-from-link option or the import entry in your dashboard. Check that the node list appears. If you see a format error, first confirm that you chose the entry for your client.
- Choose a node and rule mode. Start with a region that suits your needs; there’s no need to switch randomly over and over. If a proxy group is set to automatic selection, check which node is actually in use.
- Enable traffic routing and confirm permissions. Allow network configuration when prompted by your operating system. On desktop, check whether the system proxy or TUN is enabled. On mobile, watch for background restrictions that could pause the connection when you switch apps.
- Verify an actual request. Open an IP lookup page, then visit the website you need. If the results differ, check which rule matches the destination domain instead of relying only on the client’s status toggle.
- ✅ The node list has been refreshed, and the selected node shows no obvious configuration parsing errors.
- ✅ You’ve confirmed how traffic is routed and know which apps or requests may be excluded.
- ✅ The IP lookup result matches the expected route, and the destination website works for your intended task.
- ✅ Subscription links, authentication details, and personal request data have been redacted before sharing logs.
Can’t Connect? Troubleshoot One Step at a Time
Subscription Update Failed
First check your local network, dashboard access, and whether the link is complete. Then check your account status and client format support. Extra spaces from copying, a reset link, or selecting the wrong client entry can all cause import failures. Never send your real subscription link to a stranger for conversion.
Node Test Succeeds, but Websites Won’t Load
A client test may check only whether a server is reachable or whether a single test address responds; it may not cover every domain or transport method. Check the system proxy, TUN, DNS, and matching rules. If only one site fails, consider whether the site is down or restricts access.
Websites Work, but One App Doesn’t
First check whether the app follows the system proxy, uses UDP, or is excluded by split-tunneling rules. You can switch modes temporarily to isolate the issue, but global proxy mode is not a universal long-term fix. Once the app works again, return to rule settings that suit everyday use.
Connected, but Unstable
Keep the same node while you first rule out local Wi-Fi fluctuations and background restrictions. Then compare another route in the same region. Change only one variable at a time and note the situation and error message. That will help support distinguish between route, client, and destination-service issues.
First confirm the subscription loaded, then check that traffic reaches the client, review where the rules send each request, and finally verify the exit and destination website. Protocol names, dedicated-line labels, and connection icons are only part of the picture; troubleshoot based on the path the actual request takes.