VPN basics for beginners: subscriptions, nodes, and protocols explained

This VPN glossary for beginners explains subscriptions, nodes, protocols, direct connections, relay routes, global proxying, and split-tunneling rules. These settings operate at different layers: a subscription delivers configuration, a node provides an available exit, a protocol defines communication, and modes and rules determine which connections use the node. Once these layers are clear, importing a subscription and switching routes becomes much easier to understand.

What are subscriptions and nodes?

A subscription is a configuration source, not a single node

A subscription usually appears as a link. When the client visits it, the service provides node names, server addresses, ports, protocol parameters, and sometimes group information. One subscription can contain multiple nodes, and its contents may be updated when routes change on the service side. So “subscription imported” only means the configuration list has entered the client—it does not mean a connection is already active.

A subscription link may contain access credentials, so treat it like an account credential. Do not paste it into public speed-test pages, forum screenshots, shared documents, or untrusted conversion tools. If you need to use it on another device you own, transfer it through a trusted channel. When a device is no longer in use, delete its subscription and cached configuration.

A node combines the entry point and exit used for one connection

Region labels such as “Japan” and “Singapore” in a client list usually describe a node’s exit or intended route, but the name is only a label. The connection also depends on the entry server, transport path, protocol, and exit address. After you select a node, the client attempts to establish a tunnel or proxy connection using that configuration. Only traffic covered by the current routing rules is handed to it after the connection succeeds.

A node should not be treated as exactly the same thing as a server. One server can host configurations for different protocols, and one service route may be delivered through multiple entry points. For practical purposes, the useful unit is a complete, connectable configuration: can it complete a handshake, does it suit the current network, is the exit region appropriate, and does it remain stable during sustained transfers?

• ✅ Update the subscription after importing it to confirm that the client has the current configuration.
• ✅ Start testing with a geographically nearby node, then adjust based on the region where the target service is hosted.
• ✅ Record subscription update failures separately from node connection failures; they point to different troubleshooting layers.
• ❌ Do not assume that a node is connected just because it appears in the list.
• ❌ Do not publish subscription links or QR codes containing complete connection parameters.

How to distinguish direct, relay, and IEPL routes

Route types describe how data travels from the local network to the exit server. Direct, relay, and IEPL routes are not fixed client button names, and providers may use different labels. Judge the actual topology rather than relying on words such as “optimized” or “dedicated” in a node name.

The advantage of a direct route is its clear structure: the local network contacts the target node directly, without an extra service-side relay. But when the international link takes a detour or becomes congested, the client has little control over the intermediate path. A relay route sends the connection to a nearby entry point first, then the service network forwards it to the exit, providing more room for route management. An issue at the entry point or relay segment can still cause the connection to fail.

IEPL is a common term for an international Ethernet private-line service, focusing on how traffic is carried between the entry and exit. It does not mean that the local network from the device to the entry point is also a private line, nor can an actual topology be inferred from a marketing label alone. Consider the provider’s route description, connection stability, and real-world access results instead of treating the route name as an unconditional guarantee.

What do common protocols determine?

A protocol defines how the client and server authenticate, encapsulate, and transmit data. A protocol name alone does not determine speed or stability: the final result also depends on network quality, server configuration, the transport layer, congestion control, and the client implementation. Beginners usually do not need to enter every parameter manually, but they should know what protocol incompatibility looks like.

Shadowsocks has a relatively straightforward configuration, but it is a proxy protocol rather than a complete system VPN. VMess, Trojan, and VLESS are often combined with different transport methods or TLS settings, so the same protocol name can involve different handshake paths. Hysteria2 and TUIC both build on QUIC and UDP, and may behave differently from traditional TCP-based solutions in networks with packet loss or jitter—but only when the current network allows UDP to pass normally.

When a client reports a “timeout,” possible causes include an unreachable server, a restricted port, failed domain resolution, or blocked UDP. An “authentication failed” message points you toward checking credentials and whether the subscription is still valid. A “TLS handshake failed” message calls for checking the time, domain, certificate, and server name. Do not replace every parameter at the first sign of failure; the error message usually indicates where to start.

How to choose between global, rule-based, and direct modes

After a connection is established, the client still needs to decide which requests enter the proxy. That decision is made by the operating mode and routing rules. The node determines “where traffic exits,” while routing determines “which traffic goes to the node”; neither replaces the other.

Global mode

Global mode generally sends every network request the client can intercept through the selected node. It is useful for identifying missed routing rules: if a site works in global mode but not in rule-based mode, the issue is more likely rule matching or DNS policy than a completely unavailable node. Global mode can also route local sites, LAN devices, or apps that do not need a proxy through the node, so it is not always suitable for long-term use.

Rule-based mode

Rule-based mode decides whether to proxy, connect directly, or reject traffic based on domains, IPs, apps, or rule sets. Domain rules can match full domains or suffixes; IP rules depend on resolution results; application routing depends on whether the operating system and client can identify processes. When rules have an order, the first matching rule usually takes effect, so a broad rule placed first can hide a more precise rule later in the list.

Direct mode

Direct mode bypasses the node and uses the current network directly. It is useful for pausing proxy effects, accessing LAN resources, or running comparison tests. Direct mode does not necessarily mean the client has been exited: some clients may retain local DNS, a virtual network adapter, or system proxy settings. After testing, check that the system network state has been restored.

Request created
→ The client reads the destination domain, IP, or application information
→ Match routing rules in order
→ Apply proxying, direct access, or rejection
→ Send the proxied request to the current node
→ The node forwards the request to the target service

The most common mistake in rule-based mode is focusing only on a site’s main domain. Modern pages may load login services, images, scripts, APIs, and media from separate domains. If the main page uses the proxy but an API domain connects directly, the page may open while login fails, buttons do nothing, or images remain missing. Browser developer tools and client connection logs can help identify domains that were not routed as expected.

What is the difference between system proxy, virtual network adapter, and app proxy?

To take control of traffic, a client must use an entry point provided by the operating system. Common options include the system proxy, a virtual network adapter, or an app’s own proxy settings. A successful connection button only shows that the client may have connected to the node; whether a particular app actually uses the node also depends on whether it follows the selected interception method.

System proxy writes to the operating system’s proxy settings. Browsers and apps that follow system configuration can usually use it, but some games, command-line tools, or software with its own network stack may ignore it. Virtual network adapter mode is often labeled TUN by clients. It captures a broader range of traffic at the network layer and suits apps that cannot read system proxy settings, but it may require additional permissions and careful handling of LAN and routing conflicts. An app proxy is a local proxy address entered inside a particular application and affects only that app.

Client interfaces can differ widely across platforms, but the underlying questions are similar: has the subscription been updated, can the node complete a handshake, does the system allow a network interface to be created, is the target app being intercepted, and did the routing rules match? After switching platforms, do not search mechanically for buttons with the same names. First identify whether the client uses a system proxy, virtual network adapter, or system VPN service, then check the corresponding permissions and routes.

How to understand DNS leaks and resolution paths

DNS converts domain names into IP addresses. A DNS leak generally means that business traffic is intended to use a proxy while domain lookups are still sent to the resolver specified by the local network, leaving the resolution path inconsistent with the proxy policy. This is both a privacy-boundary issue and a potential cause of unsuitable addresses for the current exit region, leading to slow connections, incorrect regional detection, or missing page resources.

Clients do not handle DNS uniformly. Some send queries to the remote node, some use local encrypted DNS, some resolve according to routing rules, and others take over system queries in virtual network adapter mode. When you see options such as “remote DNS,” “local DNS,” “Fake IP,” or “rule-based resolution,” do not simply enable every feature. First understand whether the current mode requires the client to control DNS.

1. Before connecting, record the resolution results and exit status used by the current network.
2. After enabling the node, confirm that the target site’s traffic actually passes through the client.
3. Check whether the DNS test still shows only the resolver specified by the local network.
4. If the result is unexpected, check whether the client’s DNS mode, the browser’s secure DNS, and the routing rules are overriding one another.
5. Clear the system and browser DNS caches, then test again to avoid old results affecting the diagnosis.

The complete process from subscription import to connection verification

Once the terminology is clear, follow a fixed sequence for the initial setup. The key principle is to verify the configuration first, then node connectivity, and finally routing and DNS. Even when something fails, this narrows the problem to a specific step.

1. Get a client for your platform. Confirm that it supports the protocols used in the subscription; do not judge compatibility solely by whether it accepts a pasted link.
2. Import the subscription link. Paste the link into subscription management or the configuration entry point, save it, and run an update. If the client supports QR scanning, make sure the code comes from your own account page.
3. Check the node list. Confirm that the list is not empty and look for unrecognized protocols or configuration errors.
4. Choose a node. For the first test, select a geographically nearby route with a clear purpose. Do not enable automatic switching and complex load-balancing strategies at the same time.
5. Choose an interception mode. For browser testing, start with the system proxy. To cover more apps, enable a virtual network adapter or system VPN service according to the platform’s capabilities.
6. Establish the connection. Pay attention to resolution, handshake, authentication, and timeout messages in the client log instead of watching only the button color.
7. Verify the exit and access. Check that the exit region matches the selected node, then test a local site, the target site, and the app you need separately.
8. Switch back to rule-based mode. If global mode works, enable the rules and test again. When results differ, adjust the rules for domains or apps that were not matched.
9. Check DNS. Confirm that the resolution path matches the current interception method, so business traffic and DNS queries do not follow conflicting policies.

If the subscription will not update, first check that the link is complete, the system clock is accurate, and the current network can reach the subscription address. If the subscription updates but every node fails, focus on protocol compatibility, network permissions, and restrictions on UDP or specific ports. If only one node fails, the issue is more likely with that node, its entry point, or the route status.

If the browser works but other apps do not, check the difference between the system proxy and virtual network adapter. If global mode works but rule-based mode does not, inspect rule matching and DNS. If a page opens but login or media fails, check whether related subdomains use a different routing policy.

• ✅ The subscription updated successfully, and the client recognized its protocols.
• ✅ The selected node completed its handshake without authentication or certificate errors.
• ✅ The target app is within the interception scope of the current proxy or virtual network adapter.
• ✅ The routing rules use a consistent policy for the main domain, API domains, and resource domains.
• ✅ The DNS resolution path matches the proxy mode.
• ❌ Do not import multiple configurations from different sources before locating the fault.

Principles for choosing after you understand the client switches

Client settings can be grouped into layers: the subscription delivers configuration, the node provides a connection target, the protocol defines communication, the route determines the intermediate path, the interception method decides which apps enter the client, routing rules decide whether each request uses the proxy or connects directly, and DNS settings control the domain-resolution path. When you encounter an unfamiliar switch, first identify its layer; you can usually infer what changing it will affect.

Beginners do not need to enable every feature in pursuit of a complex configuration. A reliable approach is to keep one basic configuration that connects successfully, then gradually add rules, a virtual network adapter, automatic selection, or custom DNS. Run the same access checks after each change and keep a configuration version you can restore. This makes each switch easier to understand and provides a known working state when the network environment changes.