VPN Terms for Beginners: Understand Configs, Routes, and Rules
The key to understanding VPN terminology is knowing where subscriptions, nodes, routes, protocols, and traffic routing each fit. A subscription provides configuration; a node is a connection entry you can select in your client; a route describes the path traffic takes; a protocol defines how data is exchanged; and routing rules determine which requests take which path. They work together, but they are not interchangeable.
In everyday conversation, “VPN” is sometimes used as an umbrella term for proxy clients and network acceleration services. Strictly speaking, a system-level VPN tunnel and an app proxy handle traffic in different ways. When a client says “Connected,” it only confirms that one part of the connection is working—not that every app uses the same exit.
| Term | What it does | Common point of confusion |
|---|---|---|
| Subscription link | A way to retrieve or update connection settings | Not a client installer or a bookmark to a webpage |
| Node | A connection entry with server, authentication, and protocol settings | The displayed region may not be where the connection enters the network |
| Route | The network path from your device to the entry point, exit, and destination service | Not a quality rating you can determine from the protocol name alone |
| Protocol | Defines how the client and server communicate | A newer protocol is not necessarily faster on every network |
| Routing rule | Determines whether a request connects directly, uses a proxy, or is blocked | Selecting a node does not mean every request will use it |
Subscription Links and Nodes: Importing Configs, Not Traffic
“Subscription” commonly refers to either billing or configuration. A monthly subscription is a billing plan; a subscription link is an address a client uses to retrieve configuration. A traffic package can also provide nodes through a subscription link. “Update subscription” usually means fetching the latest configuration from the service—not renewing your plan.
A node configuration typically includes a server address, port, authentication details, and protocol settings. The node name is just a label for identification; it cannot confirm the actual exit location, route type, or whether a destination service will work. The entry point receives the connection, while the exit connects to the destination website. They may be in different regions.
Subscription formats vary. Some provide only a list of nodes; others include a full configuration with policy groups, routing rules, and DNS settings. A client’s ability to import a link does not mean it supports every field in that link. After importing, check for unsupported items or parsing errors.
- Sign in to the service dashboard and get the subscription or configuration that matches your client.
- Paste the link into the client’s subscription manager or configuration import screen, then update it.
- Confirm that the node list appears, then check the active configuration, policy groups, and selected node.
- Enable an appropriate traffic-handling mode, then test the exit and the target app separately.
IEPL, Relay, and Direct Routes: Compare the Path, Not the Label
For proxy services, a direct route usually means the client connects to the proxy server over the public internet without an additional relay entry point set up by the provider. A “direct route” is not the same as “direct” in routing rules: the latter usually means a request bypasses the proxy and connects straight to its destination.
A relay route adds a forwarding step between the client and the exit. Providers can use the entry location and upstream connections to adjust the path, but an extra hop is not necessarily slower or more reliable. Performance depends on your local carrier, entry-point load, relay links, and the connection from the exit to the destination service.
IEPL stands for International Ethernet Private Line, a term generally used for a dedicated Ethernet connection provided by a carrier. An IEPL route advertised by a provider may use a private line for only part of the end-to-end path. Your home network to the entry point, and the exit to the destination website, may still use the public internet.
So “private line” does not automatically mean fixed latency, dedicated bandwidth, or access to every website. Test routes on your own network, at the times you normally use them, and with the apps you care about. Web browsing, file transfers, and real-time calls respond differently to packet loss, jitter, and throughput; a single latency reading is not enough to judge a route.
Bottom line: First check whether the route suits your local network, then see whether it works reliably with the services you need. IEPL, relay, and direct describe paths—not a quality ranking independent of your setup.
Proxy Protocols: Compatibility Comes First
A protocol defines how the two sides authenticate, encapsulate, and transmit data. It does not determine the exit region or replace route quality. These are common protocol concepts in the industry; this does not mean VPNHead supports every protocol listed. Check the dashboard and client documentation for the supported options.
- Shadowsocks: An encrypted proxy protocol. The client and server must use compatible encryption methods and authentication settings; compatibility can vary across implementations and versions.
- VMess: An authenticated proxy protocol. Its configuration can include a user ID and transport-layer settings, in addition to the server address.
- Trojan: Typically uses TLS to protect proxy connections. Certificate validation and server-name settings affect the handshake; don’t disable validation just to clear an error.
- VLESS: A lightweight proxy protocol that does not encrypt data on its own. Connection protection depends on an additional security layer, such as TLS. Seeing VLESS in a config is not enough to assess its overall security.
- Hysteria2 and TUIC: Both are based on QUIC and depend on UDP connectivity. If your network restricts UDP, the connection may fail even when the subscription settings are correct.
Keep protocols and transport methods separate when reviewing a configuration. Some protocols work with different transports, and the client must support the complete combination. If importing succeeds but the handshake fails, check the client version, protocol support, system time, and certificate errors before investigating network reachability. Don’t assume the plan has stopped working.
Rule Mode, Global Mode, and TUN: Choose What Uses the Proxy
Rule mode directs traffic based on domains, destination addresses, app processes, or rule sets. A common setup sends local services direct and routes requests that need an international route through a proxy policy group. Rule order often matters: an earlier matching rule may decide where traffic goes, while a final fallback rule handles requests that matched nothing else.
Global mode typically sends all requests intercepted by the client through the selected proxy policy. “Intercepted by the client” is the key limitation. An app that ignores system proxy settings or uses its own connection method may not use the client at all. Global mode does not mean every network activity on the device is covered.
A system proxy usually lets compatible apps send requests to a local proxy port. TUN uses a virtual network interface to capture traffic, typically covering more apps, but it also involves routing, DNS, permissions, and compatibility with other network software. TUN is a traffic-capture method—not a proxy protocol or a new exit node.
On Windows and macOS, distinguish between a system proxy and virtual-interface mode. Linux may also require routing and permission changes. Android and iOS clients often use the system VPN interface; support for options such as per-app routing or excluding the local network depends on the OS and client implementation.
If an app won’t open, you can temporarily switch to global mode for comparison. If global mode works but rule mode doesn’t, check rule matches and policy groups first. If both fail, investigate the node, exit, or app restrictions. Once you find the cause, restore an appropriate routing setup rather than sending every local service through the proxy indefinitely.
DNS Leaks and Exit Checks: What to Verify After Connecting
DNS translates domain names into network addresses. A DNS leak generally means lookup requests are handled outside the expected, controlled path—for example, by your local network or another resolver you did not intend to use. This is separate from whether your web traffic exits through a proxy: a website seeing the proxy exit does not prove DNS requests are handled as expected.
A client may handle system DNS, a browser may use its own encrypted DNS, and an app may have built-in lookup logic. To troubleshoot, find out which resolver handles each request and which route it takes; don’t rely only on an “encrypted DNS” toggle. Encryption protects requests on the way to the resolver, but does not automatically send them through a proxy.
When checking DNS, consider client logs, matched rules, and test results together. A resolver’s region being different from the exit region does not by itself prove a leak, since DNS services may use distributed networks. Conversely, a clean result on a test page does not prove that every app and connection follows the same path.
- ✅ Check your browser’s current exit on the IP lookup page, then test the feature you need in the target app.
- ✅ Review the client’s connection logs to confirm that the target domain matches the expected rule and policy group.
- ✅ Check DNS settings in your OS, client, and browser to avoid conflicting configurations.
- ✅ Change one setting at a time and keep any error messages so you can undo changes and pinpoint the cause.
- ❌ Don’t treat disabling certificate validation, replacing subscription settings at random, or clearing every rule as universal fixes.
If the exit is correct but a service still doesn’t work, possible causes include your account region, the service’s policies, the exit IP’s reputation, or app cache. Changing protocols may not help. To get support, use the support page to share your client name, OS, error message, and the circumstances of the issue. Hide your subscription link and authentication details before sharing screenshots.
Put the Terms into Practice: Define Your Needs, Then Test Your Setup
If you only need a browser to access international websites, first check whether it follows the system proxy. If you need to cover more desktop apps, then consider TUN and its compatibility. Connecting all your home devices involves router performance, policy-based routing, and local network access; desktop client settings won’t necessarily work as-is.
When choosing a service, evaluate data allowance, how often you use it, and route requirements separately. VPNHead offers monthly subscriptions and one-time traffic packages that never expire; monthly data resets each month on the activation date. “Unlimited devices” describes the device-use policy, not unlimited data or guaranteed bandwidth. Check current prices on the plans page.
VPNHead’s primary security claim is “anonymous, no logs.” This describes its privacy policy; it does not mean websites can’t identify an account that’s signed in or a device. Accounts use a username and password, with no email address required. Sign-in is required to get the client and subscription. Getting the iOS client also requires an active plan; for other platforms, you can download it after signing in.
Quick summary: A subscription provides configuration, a node is a selectable connection, a route describes the path, a protocol defines how communication works, and routing rules decide where traffic goes. After importing, check traffic handling, rule matches, the exit, and the target app’s functionality in order. This is more effective than repeatedly switching nodes at random. Continue with the setup guides for instructions.