This VPN glossary explains how the pieces fit together: a subscription provides configuration, a node specifies the connection endpoint, an IEPL line describes part of a network route, and global or rule mode determines how traffic is routed. These are different layers, not interchangeable terms. Understanding the differences helps you choose a route and troubleshoot issues more effectively than relying on node names alone.
VPNs, proxies, and clients: what’s the difference?
VPN stands for virtual private network. It typically connects a device to another network through a tunnel. In everyday conversation, people also use “VPN” to describe proxy services for accessing international websites, even though the underlying technology may differ. A traditional VPN can handle network-layer traffic, while a proxy may handle only the connections routed through it by configured apps.
A client is software on your device that reads configuration, establishes connections, and applies rules. The server provides a remote endpoint; the client decides which requests to send there. An app showing “Connected” doesn’t automatically mean every app uses the same exit, or that DNS queries follow the intended route.
Some proxy clients use a virtual TUN interface to capture more system traffic, making them work much like a system VPN. TUN is a traffic-capture method, not a node protocol or encryption algorithm. To see what’s covered, check the client’s system proxy, virtual interface, and app-routing settings—not just the software’s name.
The difference between subscription links, nodes, and routes
“Subscription” commonly has two meanings. A billing subscription is a service plan; a subscription link is the address a client uses to fetch configuration. It may return a node list or a complete configuration with nodes, policy groups, rules, and DNS settings. Updating a subscription fetches configuration again; it doesn’t mean paying again or necessarily resetting your data allowance.
A node is a set of connection parameters, typically including a server address, port, authentication details, protocol, and transport settings. The node name is a label for identification. Its region usually indicates an exit location or route label, but the name alone doesn’t prove a physical location or network quality.
A route describes the path traffic takes: from your local network to the service entry point, possibly through a relay, and then from the exit to the destination website. Nodes with the same exit region may use different entry points and paths, so their performance can vary.
| Term | What it does | What it doesn’t tell you |
|---|---|---|
| Subscription link | Fetches or updates nodes and other configuration | That a plan has renewed or data has reset |
| Node | Specifies remote connection parameters | That the region in its name is best for your current network |
| Route | Describes the entry, relay, and exit path | That the entire path is always uncongested |
| Policy group | Selects a node or another policy for a category of requests | That every app uses the currently selected node |
| Exit IP | The address destination websites typically see as the connection source | That your account identity or browser state has also changed |
How to distinguish IEPL lines, relays, and direct connections
IEPL usually stands for International Ethernet Private Line, used to connect network endpoints in different regions. In proxy services, an “IEPL node” generally means that one segment of the route uses this type of link—not that every segment from your device to the destination website is private line. Your local connection, entry point, and the route from the exit to the website still affect performance.
A relay route sends traffic to an intermediate server before forwarding it to the exit. This can change the route and avoid some direct-connection issues, but the extra hop also makes the relay server’s load and peering quality relevant. Relaying describes a network topology and isn’t mutually exclusive with a private line; the cross-region segment after a relay may also use one.
A direct route usually means the client connects to the remote node without a service-arranged relay server. Traffic still passes through carrier routers; there isn’t a network-free path between your device and the exit. A more direct path doesn’t guarantee lower latency: results depend on your local carrier, cross-region routing, and the destination service.
Route types describe how a path is arranged, not how fast it is. Choose an exit region for your destination, then compare page loads, sustained downloads, and long-lived connections at the times you actually use the service. See VPNOQ’s route categories and region details on the routes page. Check your current connection to assess access to a specific destination.
What common protocol names mean
A protocol defines how a client and server communicate. Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC are common proxy protocol or solution names—not six different plans, and their names alone don’t tell you how fast they are. Your client must support the protocol and the transport and security settings used by the service.
Authentication, encryption, and transport are different things
Shadowsocks uses encryption methods defined by its protocol to carry proxy traffic; VMess includes authentication and encryption mechanisms. Trojan typically runs over a TLS connection. VLESS does not encrypt content on its own; security depends on the outer configuration, such as TLS or REALITY. Using VLESS alone doesn’t mean the connection is encrypted.
Hysteria2 and TUIC use QUIC, which is based on UDP. If your current network restricts UDP, the connection may fail or become unstable. They aren’t better than TCP-based options on every network. Conversely, a protocol’s ability to carry UDP traffic doesn’t mean its outer transport necessarily uses UDP.
Fields such as TLS, WebSocket, and gRPC in a node configuration describe a security layer or transport method; they aren’t standalone routes to different regions. Don’t change server names, certificate verification, or transport parameters at random to “optimize” a connection. Mismatched settings can prevent a connection, while disabling certificate verification weakens authentication. These are general explanations and don’t imply that VPNOQ supports every protocol listed.
What do global mode and rule mode mean?
Global mode usually sends all requests captured by the client through the selected proxy policy. The key phrase is “captured by the client”: with system proxy enabled alone, apps that ignore the system proxy may still connect directly. Global mode doesn’t automatically route every network activity on your device through the tunnel.
Rule mode matches requests to policies based on domains, destination IPs, app processes, or other available criteria. Common actions include direct, proxy, and reject. Rules are generally evaluated in configuration order, with the matching action applied; a final rule handles requests that didn’t match earlier ones. The client’s core determines the exact syntax and behavior.
A policy group can let you choose a node manually or select and switch nodes automatically using methods supported by the client. Rules send requests to a policy group, which then chooses a node. So if you’ve selected one node on the main screen but some websites use a different exit, a rule may be referring to another policy group—the selection may have been saved correctly.
- ✅ Everyday use: Start with the rule configuration provided by the service for your client, then check which policy your work websites actually match.
- ✅ Troubleshooting access: Temporarily switch to global mode and reconnect, compare the results, then restore your usual routing settings.
- ❌ If global mode works but rule mode doesn’t, don’t just keep switching nodes. Check the domain rules, policy groups, and DNS resolution too.
- ❌ Avoid running multiple traffic-capture tools at once. System proxy, virtual interface, and routing settings may conflict.
After switching modes, existing long-lived connections may continue using the old route. Close and reopen the target app, or reconnect using the client’s available controls, then check whether the exit has changed. Comparing results is meaningful only after that.
DNS leaks and checking your exit
DNS translates domain names into IP addresses. Routing a website connection through a proxy doesn’t mean its DNS lookup takes the same route. If you expect lookups to go through the tunnel but they’re still sent to a resolver on your local network, this is commonly called a DNS leak.
Some routing configurations intentionally use local DNS for domains set to connect directly, so seeing a local DNS resolver isn’t enough to draw conclusions without knowing the configuration’s intent. Encrypted DNS in your browser, the system resolver, client DNS settings, and an app’s own resolution behavior can all affect the route.
Fake-IP in a client maps domain names to temporary addresses to help identify and route traffic later. These aren’t the destination website’s real addresses. If an app doesn’t work with this mode, adjust the setting according to the client’s instructions; not every DNS issue is caused by the node.
When testing, check the exit address seen by the destination website separately from DNS test results, and review which rules matched in the client’s connection log. A changed public IP only shows that the tested request used a different exit; it doesn’t prove every app was captured or replace an assessment of the privacy policy. A no-logs policy describes the service’s data-handling practices; it doesn’t mean a website can’t identify visitors through account sign-in or browser state.
From configuration setup to connection checks
Interfaces differ across platforms, but the basic steps are similar. First, make sure the client supports the configuration format provided by the service, then import it and test the connection. If the format isn’t compatible, get a configuration for the right client version instead of sending a private link to an untrusted conversion site.
- Get the client and subscription. Download the software from the service control panel or the client’s official source. VPNOQ’s client download is available in the user dashboard. See the getting started guide for setup and connection instructions.
- Import the remote configuration. In the client, choose the subscription or remote configuration option and paste the link from the control panel. Some clients can open an import link directly; either way, confirm that the configuration has been saved.
- Update and choose a route. Check that the node list loaded, then select the desired exit and policy group. If the update fails, first check that the link is valid, your network can fetch the configuration, and the format is supported.
- Enable traffic capture. Allow network configuration changes as required by your platform, then enable the system proxy or tunnel feature you need. Granting permission doesn’t confirm that a remote connection has been established.
- Test the apps and websites you need. Check the exit, matched rules, and DNS behavior. If something fails, determine whether the issue is with fetching the configuration, the node handshake, DNS resolution, or restrictions imposed by the destination website.
Windows and macOS clients may offer both system proxy and TUN options. Which apps use the system proxy depends on whether they follow that setting. Linux command-line programs may also need proxy environment variables; HTTP and SOCKS proxy address formats aren’t interchangeable.
iOS clients usually establish tunnels through a system network extension. Check app availability and regional support separately. Android clients commonly capture traffic through the system VPN interface and may offer per-app routing. A proxy configuration subscription and a system profile are different file types; don’t try to install an arbitrary subscription link as a system profile.
Keep billing terms separate from connection settings
A monthly subscription defines billing and data cycles; a data package defines the available data balance. Neither determines whether the client must use global or rule mode. VPNOQ monthly subscription data resets each month on the activation date; data packages remain valid until used and never expire. See the plans page for prices and data options.
Unlimited simultaneous devices is a device-use policy, not unlimited data or a bandwidth guarantee. The 14-day money-back guarantee is a service policy; check the site terms for details. It’s separate from the remaining data shown in your client and from the subscription update status.
First confirm that the configuration imports, then that the node connects. Next, check traffic capture, routing rules, and DNS, and finally compare how the routes perform in practice. Keeping billing cycles, configuration links, communication protocols, and network routes distinct helps avoid unnecessary route changes and repeated setup.