VPN Glossary: Subscriptions, Nodes, Protocols, and Routing, Explained

This VPN glossary follows the order things happen in practice: a subscription provides configuration, a node is a connection endpoint you can choose, a protocol defines how communication works, and routing rules decide which requests use the proxy. These terms describe different things and are not interchangeable. If a site won’t open even though the configuration imported successfully, trace the connection path to find the cause instead of assuming the route is slow.

Key terms at a glance: what each one does

A client’s home screen often shows subscriptions, proxies, proxy groups, and modes side by side. Similar names don’t mean they work the same way. Start with the comparison below to see which part you’re changing when you configure the client.

People often use “VPN” as a broad term for network proxy services. Strictly speaking, a system-level VPN tunnel and an application proxy work differently. To understand what traffic is covered, check how the client captures traffic rather than relying on whether the product is called a VPN.

Subscriptions and Nodes: Where the configuration comes from

A subscription plan and a subscription link are not the same thing

“Subscription” can refer to a billing arrangement or to the mechanism for updating configuration. A monthly subscription describes the plan’s billing period; a subscription link in the client is the address used to fetch configuration. A data package may also be imported as nodes through a subscription link—there’s no contradiction. Check the plan details for data allowances, validity, and reset terms.

A subscription may contain more than a list of servers. Depending on the format, it can include proxy groups, routing rules, and DNS settings—or just node parameters. So a successful import only means the client accepted some configuration; it doesn’t confirm that routing, DNS resolution, and traffic capture are all working correctly.

A node typically consists of a server address, port, protocol, authentication details, and transport settings. The region shown in the client is just a label. The entry point, final traffic exit, and path in between may all be in different locations, so the label alone can’t tell you which region a website will see as your exit.

A subscription link may contain access credentials, so treat it as sensitive information. Don’t post it on public forums, include it in screenshots, or submit it to an unfamiliar subscription converter. If you suspect it has been exposed, use the reset option in your account panel and update the old link in your client.

What to check after importing

1. Sign in to the account panel, then check supported platforms and configuration formats in the client download section before following the guide to get your subscription.
2. Import the link from the subscription or configuration section of your client. If you see a format error, first check that the client and subscription type match; don’t keep changing node parameters at random.
3. Update the subscription and confirm that the node list loads. If the update fails, check that the link is complete, your network is working, and your account is active.
4. Select a node or proxy group, then enable the system proxy or a traffic capture feature supported by your client, as needed.
5. Open the website or app you want to use, then check the client’s connection logs to confirm which rule matched and which outbound route was selected.

If the node list is empty, start by checking whether the subscription could be fetched. If the list looks normal but connections fail, check the node and network instead. This separates “configuration wasn’t fetched” from “configuration was fetched but won’t connect.”

Protocols: Communication methods, not a speed ranking

Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC may all appear in proxy clients, but you can’t convert one into another just by changing its name. The client’s core must support the protocol and its specific parameters, and the server must provide a matching configuration.

• Shadowsocks: An encrypted proxy protocol. The client and server need compatible encryption methods, keys, and other parameters; support may vary between versions.
• VMess: An authenticated proxy protocol that can use different transport methods. The transport type and security settings in the configuration must match the server.
• Trojan: Commonly uses TLS for secure transport and requires the right authentication and TLS settings. Don’t casually disable or change settings such as the domain or certificate verification.
• VLESS: A lightweight proxy protocol that doesn’t encrypt content on its own. Understand it in conjunction with security mechanisms such as TLS or REALITY; the protocol name alone doesn’t mean it’s an encrypted tunnel.
• Hysteria2 and TUIC: QUIC-based proxy protocols that rely on UDP, so they may not connect on networks that restrict UDP traffic.

These are explanations of the concepts, not a list of every protocol currently offered by VPNFK. Check the account panel and client support for the options actually available. Being able to browse regular websites doesn’t mean the network allows the transport method your selected protocol needs.

Route types: Dedicated, relay, and direct

Route types describe the path network traffic takes; protocols describe how communication is structured. They’re separate dimensions: the same protocol can use different routes, and a single route can carry different protocols.

Direct usually means connecting straight to a proxy server outside your region, with the route depending heavily on your local carrier’s international gateway and routing. A “direct node” is not the same as DIRECT in a rule: the former can still be a proxy connection, while the latter usually means the request goes out without a proxy.

Relay usually means connecting to an entry point first, which then forwards traffic to an exit point. An extra hop doesn’t necessarily make a connection slower; performance may be more stable if the entry point and onward route suit your network better. But a relay label doesn’t guarantee good performance during peak hours.

IEPL dedicated line usually refers to a carrier-provided international Ethernet private line between specific locations. There are still other network segments between you and the entry point, and between the exit point and the destination website. A dedicated-line label describes one segment of the route, not an end-to-end quality guarantee for every website.

When comparing routes, test the tasks you actually care about on the same device and in similar conditions: do pages load fully, do calls drop, does video keep buffering? The response time shown by a client probe reflects a particular test condition; it doesn’t replace checks for throughput, packet loss, or performance in real apps. See the nodes page for the route details.

Routing and global mode: where requests go

Rule-based mode selects an outbound route based on matching conditions such as domain, destination address, or process. Rules are generally checked in configuration order, so a broad rule near the top can prevent more specific rules below it from taking effect. A final catch-all rule handles requests that didn’t match anything earlier.

Global mode usually sends traffic already within the client’s handling scope through the selected proxy or proxy group. It doesn’t automatically capture traffic from every app on the device. An app that ignores the system proxy may still not work when you switch to global mode.

System proxy and TUN: what’s the difference?

A system proxy provides a proxy endpoint to apps that support it. Browsers often follow the system proxy setting, but games, command-line tools, and office software may behave differently. TUN captures IP traffic through a virtual network interface, usually covering more traffic, but it still depends on routing, exclusions, system permissions, and the client’s implementation.

Windows and macOS clients may need extra permissions or a service installation to enable certain traffic capture features. Mobile clients often use the system VPN interface to forward traffic. On Linux, check the desktop proxy, environment variables, and app-specific settings too. A client showing “Connected” doesn’t necessarily mean every process is using the same route.

• ✅ For everyday work across local and international websites: start with a ruleset from a clear source, then check that the apps you need match the intended outbound route.
• ✅ If only one website has a problem: temporarily switch modes to compare, then check which rule matched its domain. Don’t start by reinstalling the client.
• ✅ If your browser works but other apps don’t: first check traffic capture and the apps’ own proxy settings, then consider switching nodes.
• ❌ Don’t treat global mode as a universal fix for regional restrictions: platforms may still check your account region, exit address, and other signals.

When using AI tools or streaming services, a working proxy connection and permission to use a platform are two different things. A successful connection doesn’t change the platform’s account eligibility, content licensing, or regional rules.

DNS Leaks and common troubleshooting

DNS translates domain names into network addresses. DNS requests can come from the operating system, the client, or an app’s own encrypted DNS feature. If you expect DNS lookups to use a particular route but they still go to a resolver on your local network, this may be what’s known as a DNS leak.

Encrypted DNS mainly protects queries in transit between you and the resolver; it doesn’t automatically send website traffic through a proxy. Likewise, an active proxy doesn’t mean every DNS query is being captured. Check the client’s DNS settings, your browser’s secure DNS settings, and the actual routing together.

A detection page showing a local resolver can be a useful clue, but interpret it alongside your routing setup: using a local resolver for local services may be intentional, and third-party test pages can’t cover every app. Don’t overwrite your entire DNS configuration just to make the test results look consistent.

Troubleshoot what you observe, not what you assume from a term

1. Subscription won’t update: Check that the link is complete, your account is active, the subscription format matches, and your current network can reach the subscription service.
2. Most nodes fail to connect: Check the system time, network restrictions, and client-core compatibility, then look for handshake or authentication errors in the logs.
3. Only some apps fail: Check whether the apps are within the client’s traffic handling scope, and whether the matched rules and DNS results are as expected.
4. A specific platform reports a regional restriction: Check the actual exit location and the platform’s rules; don’t assume the protocol has failed.
5. Connected, but performance fluctuates: Pause high-traffic background tasks and compare routes under similar conditions. Avoid changing the protocol, DNS, and rules all at once, or you’ll lose a useful basis for comparison.

When contacting support, include your operating system, client, network environment, selected route, and steps to reproduce the issue. Before sharing logs, redact subscription links, authentication credentials, and account details. Don’t send an unchecked full configuration file.

For help setting up your client, see the client guide. If you run into an error you can’t explain, describe what happened without sensitive details on the support page. First identify which layer the problem is in, then decide whether to change the configuration or switch routes.