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

For VPN beginners, the hardest part is often not installation but understanding how subscriptions, nodes, protocols and traffic routing fit together. They represent the configuration entry point, available exit, transport method and traffic decisions. Once the chain makes sense, importing a client config, changing regions and troubleshooting inaccessible websites become much easier.

Start with a simplified model: the provider supplies a subscription containing node configurations; the client reads them and establishes a connection using a protocol; routing rules then decide which requests use that connection. The country or region shown for a node indicates its exit location, while the route type describes how data generally travels from your network to that exit. These terms belong to different layers and are not interchangeable.

What are subscriptions, subscription links and config files?

A subscription is neither a client app nor a fixed route. It is closer to a configuration list maintained by the service, containing node names, server addresses, ports, protocol types, authentication details and other connection parameters. After the client reads it, it can generate a selectable node list.

A subscription link is the address used to retrieve that list. After you import it into a compatible client, the client typically downloads and parses the configuration. When the service updates its routes, those changes can be synced through the subscription instead of being entered manually one node at a time. Subscription links usually contain dedicated access credentials, so protect them like passwords and never paste them into public posts, screenshots or online parsing sites.

A config file is static content saved locally. It may be exported from a subscription or written manually. Static files do not automatically follow changes made by the service; when a route address changes, you must download the file again or edit it yourself. For beginners, importing a subscription is usually easier than copying individual node parameters, but it is still important to know where the configuration came from when troubleshooting.

Subscription service
  └─ Subscription link or config file
      └─ Multiple node configurations
          └─ Client selects a node
              └─ Protocol establishes the connection
                  └─ Routing rules process requests

Importing and updating are different

Importing adds a subscription to the client; updating requests the latest content from the subscription address. Even after the first import succeeds, the node list in the client is only a copy of what was retrieved at that time. If node names change, old routes stop working or a new region does not appear, update the subscription first instead of repeatedly reinstalling the client.

✅ Copy the complete subscription link from the user panel to avoid missing trailing parameters.
✅ In the client, choose “Import from link” or an equivalent option.
✅ Update the subscription after importing and confirm that the node list refreshes normally.
✅ Select a node, then enable the system proxy, tunnel or client connection.
❌ Do not submit your subscription link to an unknown online conversion tool.
❌ Do not mistake “Import successful” for proof that the target app is using the proxy.

Bottom line The subscription delivers configuration, while the client reads it. You can change clients while the subscription remains managed by the original service; deleting the client does not automatically alter the subscription stored on the service.

Nodes, servers, exits and routes: what’s the difference?

A node is a selectable connection profile in the client. It usually points to a server entry point, but a node name does not necessarily represent a dedicated server. The service may use load balancing, entry-point forwarding or multiple exit resources, so do not infer the underlying machine structure from the display name alone.

A server is the host or service instance that actually handles network connections. A node in the client may connect directly to an exit server, or it may connect to an entry point before being relayed to the exit. For most users, the exit region, route type, protocol compatibility and real-world stability matter more than guessing the server hardware.

An exit is the location where a request appears to leave the proxy network from the target website’s perspective. After selecting a Japan node, a properly working route will usually make the website identify the request as coming from a Japanese exit address. A regional name alone is not proof; after connecting, use TxtVPN’s IP lookup to confirm the exit region.

A route describes the path data takes. A node is more like a clickable entry in the client, while a route focuses on the journey from your local network through entry points and intermediate networks to the exit. The same exit region may be available through direct, relayed or dedicated routes, which can perform differently during evening congestion, across networks and during failover.

Term	Question it answers	Common beginner misconception	How to check it correctly
Subscription	Where does the configuration come from?	Treating the subscription as the client app	Check whether the subscription imports and updates successfully
Node	Which connection profile is selected now?	Assuming one name always means one dedicated machine	Check the connection and exit after switching
Protocol	How does the client communicate with the service?	Assuming the protocol name directly indicates route quality	Confirm compatibility on both ends and test the connection
Route	What path does the data generally take?	Looking only at the exit region and ignoring the intermediate path	Test across different times and local networks
Traffic routing	Which requests should use the proxy?	Assuming every app uses the selected node once it is selected	Check the mode, rule matches and system proxy

Direct, relayed and IEPL dedicated routes

A direct route means your network connects directly to the remote service entry point without an additional forwarding entry arranged by the provider. Its structure is simple, but the experience depends heavily on the route from your local carrier to the remote network. A shorter physical distance does not guarantee a better path; map distance says nothing about the autonomous systems or exchange points the traffic actually crosses.

A relayed route first connects to an easier-to-reach entry point, which then forwards traffic to the target exit. The goal is usually to avoid poor public-network paths and improve cross-network or peak-hour performance. It is not automatically faster: the quality of the entry point, relay path, exit load and local network all affect the result.

An IEPL dedicated route generally uses an international Ethernet private-line resource from a carrier for key segments, combined with an entry point and exit. Its routing structure differs from an ordinary public-network direct connection and is often used where link stability matters. However, the “dedicated” label is not a substitute for testing; the client protocol, entry quality and your current network still affect the final experience.

How to choose Start with an exit region that fits your location and target service, then compare the real performance of direct, relayed and dedicated routes. Choosing solely by labels such as “high-speed” or “premium” in a node name offers limited insight.

What do protocol names mean?

A protocol defines how the client and service package, authenticate and transmit data. It answers “how do they connect?” rather than “which physical route does the traffic take?” The same network path can carry different protocols, and the same protocol can run on routes with very different quality. An advanced protocol does not guarantee a faster node, and a slow node cannot automatically be blamed on the protocol.

Shadowsocks

Shadowsocks is a widely used encrypted proxy protocol. Its configuration typically includes a server address, port, encryption method and password. It has a broad client ecosystem and a relatively straightforward structure. Keep in mind that supported encryption methods vary by implementation; if the client reports an “unsupported encryption method,” update the client or use the compatible client recommended by the service instead of changing configuration fields at random.

VMess and VLESS

VMess and VLESS are common in the Xray and V2Ray ecosystems. VMess includes authentication and protocol structure, while VLESS is more focused on lightweight authentication and is typically paired with TLS, Reality, WebSocket, gRPC or other transport and security layers. Seeing VLESS in a client does not mean every VLESS node uses interchangeable parameters; transport settings, server name, path, public key and other fields must match the service configuration.

Trojan

Trojan usually runs over TLS. Key settings include the server address, authentication details, server name and certificate-verification parameters. If certificate verification fails, do not treat “skip verification” as the default fix. A safer approach is to check the system time, server name, subscription expiry and whether the client has read the configuration correctly.

Hysteria2 and TUIC

Hysteria2 and TUIC both use a QUIC-based transport approach and are often used when better performance is needed on high-latency or somewhat lossy networks. They depend on UDP availability; if a company network, public network or router restricts UDP, you may see handshake failures, unstable connections or no connection at all. In that case, switching to another protocol that works on the current network is more effective than repeatedly changing unrelated parameters.

When choosing a protocol as a beginner, prioritize native client support, whether the current network permits the required transport, and whether the service provides a complete configuration. If the subscription already supplies working nodes, you usually do not need to change the protocol yourself. Manual edits are appropriate only when you clearly understand the service parameters and field meanings.

System proxy, virtual network adapter and tunnel mode

After the client connects to a node, app traffic still needs to enter the client. Common options include the system proxy and a tunnel mode based on a virtual network adapter. Neither is simply a higher- or lower-level option; they differ in how traffic is captured and how they are implemented.

The system proxy changes the proxy settings provided by the operating system. Browsers and apps that follow those settings send requests to the local proxy port, but some games, command-line tools, standalone updaters and apps with their own network stack may ignore them. If “the browser works but the terminal does not,” first check whether the target program reads the system proxy.

A virtual network adapter or tunnel mode creates a virtual network interface and uses routing rules to capture a broader range of traffic. It can usually cover apps that do not support the system proxy, but it is also more likely to conflict with an enterprise VPN, virtual machine network, container network, security software or another network filter. If local services become inaccessible after enabling it, check routes and bypass rules instead of only switching nodes.

Command-line tools may also read environment variables. Enabling the system proxy in a graphical client does not mean every terminal process will inherit it automatically. Supported variables and proxy types vary by tool, so consult the relevant documentation and remove temporary settings when finished.

Browser request
  ├─ Follows system proxy → local client → remote node
  └─ Ignores system proxy → direct through local network

Tunnel-mode request
  └─ Route enters virtual adapter → traffic routing rules → proxy or direct

How to choose global, rule-based or direct mode

Global mode generally means that as much captured traffic as possible is sent through the current proxy node. It is useful for temporary diagnosis: if a target service fails in rule-based mode but works globally, the likely issue is rule matching, DNS policy or an app that is not being captured—not that the node is entirely unavailable.

Rule-based mode decides whether traffic uses the proxy, connects directly or is rejected based on domains, IPs, processes, geographic databases or custom conditions. It is better suited to daily use because local websites, LAN traffic and requests that do not need international routes can remain direct. The challenge is ongoing rule maintenance; domain changes, shared infrastructure and embedded app requests can all lead to missed matches.

Direct mode means requests do not pass through a remote node. It can pause proxying, access LAN devices or test whether the proxy path is causing a problem. Direct mode does not necessarily exit the client; some clients may still run local DNS, a rule engine or a virtual network adapter. To fully restore normal networking, disable the relevant traffic-capture features according to the client’s instructions.

Connect to the node in rule-based mode and open the target service.
If it fails, temporarily switch to global mode and test again.
If global mode works but rule-based mode does not, check whether the domain matches the wrong rule.
If global mode also fails, check the subscription update, protocol compatibility and node status.
Switch back to direct mode to verify that the local network itself is working.

Daily recommendation Use rule-based mode for regular operation, global mode to quickly isolate routing issues, and direct mode as a baseline. During troubleshooting, comparing them in this order is more informative than switching nodes at random.

DNS, DNS leaks and exit checks

DNS resolves domain names into reachable addresses. A working proxy connection does not mean DNS follows the same path. The client may use system DNS, remote DNS, encrypted DNS or a built-in resolver; rule-based mode may also use the result to decide where traffic goes. DNS settings and routing rules affect each other, making them a common reason a node appears connected while websites remain inaccessible.

A DNS leak usually means that domain queries expected to be handled through the proxy are instead sent to the local network’s resolver. This may reveal the DNS provider used by the local network or produce inconsistent geographic resolution. For example, the webpage connection may use a remote exit while DNS still returns an address better suited to the local network, leading to mismatched content or a roundabout connection.

Do not check only the IP address. Also verify the exit region, where DNS queries are resolved, whether the browser has enabled its own secure DNS, and whether IPv6 is connecting directly. A browser’s built-in DNS setting may bypass the client’s intended policy; when the operating system and client use different resolution methods at the same time, results can also become unpredictable.

✅ After connecting, first check whether the public exit matches the selected region.
✅ Check whether DNS queries are handled by the expected resolver.
✅ Confirm that the browser and operating system do not have conflicting DNS settings.
✅ When rule-based mode behaves unexpectedly, use global mode as a comparison.
❌ Do not treat “the webpage opens” as proof that DNS and routing are fully correct.
❌ Do not enable multiple DNS-capture features at once without understanding their effects.

Why clients look different across platforms

Windows, macOS, Android, iOS and Linux clients are shaped by each system’s network interfaces, permission model and background policies, so their controls will not be identical. The same subscription may show different node ordering, speed-test buttons, rule names and log formats across clients, but the core flow remains: import the configuration, choose a node, connect, set routing and check the exit.

Desktop systems generally make it easier to inspect connection logs, routing tables and local listening ports, but they are also more likely to encounter conflicts from virtual machines, containers or enterprise networking software. Mobile systems enforce background operation and VPN permissions more strictly; after changing networks, entering power-saving mode or running in the background for a long time, the system may reschedule the connection. When disconnects occur, check system permissions and background policies as well.

A graphical interface is not required on Linux. Many clients can run through config files and service processes, but environment variables for the system proxy, desktop proxy settings, routes and DNS may belong to separate components. Starting only the core process without configuring a traffic entry point will not automatically send apps through the node. A command line showing that a process is running proves only that the core has started, not that the routing chain is complete.

The client name does not determine protocol compatibility either. Before importing, check which protocols, transport layers and subscription formats it supports. If a node is marked “unsupported,” prefer the client version supplied or recommended by the service, and do not delete security parameters from the configuration when you are unsure what the fields mean.

What order should beginners follow when troubleshooting?

Network problems often involve several layers. Switching nodes at random may restore access temporarily, but it does not reveal whether the cause is an outdated subscription, an incompatible protocol, a missed routing rule or a local network restriction. Following a fixed sequence gradually narrows the scope.

Confirm the local network: Disable proxy capture and check that ordinary websites and DNS work normally.
Update the subscription: Rule out changed node addresses, leftover old configuration or a failed subscription fetch.
Check the client logs: Distinguish resolution failures, connection timeouts, authentication failures and certificate errors.
Switch to a node in the same region: Determine whether the issue is limited to one node or a particular protocol.
Compare routing modes: If rule-based mode fails while global mode works, focus on the rules and DNS.
Check traffic capture: Confirm that the target app uses the system proxy or is covered by tunnel mode.
Verify the exit: Confirm that the public address matches the target region, then reopen the target service.

A “timeout” in the logs usually means that the expected response did not arrive within the waiting period; it does not by itself prove that the server is offline. DNS, routing, firewalls, UDP restrictions and mismatched protocol parameters can all produce similar symptoms.

If only one app fails while the browser and other tools work, first check whether that app ignores the system proxy, uses its own DNS, is locked to a particular network protocol, or has related domains not covered by the routing rules. If every app fails, return to the node connection, subscription and local network layers.

With these terms understood, a complete connection can be described as follows: the client gets node configuration from the subscription, connects to the entry point using the specified protocol, sends data to the exit over a direct, relayed or dedicated route, and lets routing rules decide whether each request uses the proxy or connects directly, while DNS policy resolves domain names. Troubleshooting should follow this chain layer by layer instead of focusing only on the color of the “Connect” button.