This quick guide to VPN terminology explains subscriptions, nodes, routes, protocols, and traffic routing in the order you’ll use them. Remember: a subscription provides configuration, a node is a connection entry point, a route is the path traffic takes, a protocol defines how devices communicate, and traffic routing determines where requests go. They’re related, but they aren’t the same setting.
What people call a “VPN client” may actually be a proxy client. A VPN indicator in your system settings may simply mean the app is using the system’s traffic-routing interface; it doesn’t necessarily mean the underlying connection uses a traditional VPN protocol. To understand what’s happening, check the configuration and where requests are routed—not just the connection icon.
Subscription links: configuration sources, not connection switches
A subscription service you pay for and a subscription link in your client are easy to confuse. The service is part of your account plan; the link is usually an address containing access credentials. The client reads that address to retrieve configuration details such as servers, ports, and protocol parameters. Some subscriptions also include policy groups and rules, depending on the format provided by the service.
So, “subscription updated successfully” only means the client retrieved content it could parse. It doesn’t mean a node is reachable or that every app is using the proxy. After importing a configuration, you may still need to enable it, choose a policy group, and turn on the traffic-routing method required by your client.
Importing vs. updating
Importing adds a configuration source to the client; updating fetches the latest content from that source. Node names, connection parameters, and rules may change with an update. Manual edits to a subscription-generated configuration may be overwritten next time it updates. To keep custom rules, add them in the client’s supported override or custom-rules section, and check how the client merges them first.
An incompatible format is a common reason imports fail. A client that can read one type of configuration may not support another client’s full rules file. Choose the option in your account dashboard that matches your app. Don’t rely on the file extension alone to judge compatibility, and don’t keep changing link parameters at random.
Nodes and routes: separate the entry point from the path
A node usually means a connection profile you can select in your client. It may point to a physical server or to a relay entry point. A country or region in the node name can suggest the exit location, but the name doesn’t verify it. The location a website sees also depends on the actual routing and IP geolocation databases.
A route describes the path a request takes to reach its exit point. The same region can have different entry points and transmission paths, so choosing the same country doesn’t guarantee the same experience. Some dashboards use “node” and “route” interchangeably. If a label is unclear, check the service documentation rather than guessing how the network is set up.
| Term | What it usually means | What you can’t infer from it |
|---|---|---|
| Direct | The client connects directly to an overseas server, usually without first going through the provider’s domestic relay. | A shorter path isn’t necessarily faster; public internet routing and congestion still matter. |
| Relayed | The client first connects to a relay, which forwards traffic to another server or exit point. | It doesn’t necessarily use a dedicated line or provide stronger application-layer encryption. |
| IEPL dedicated line | Usually refers to using a carrier-provided international Ethernet private line for some cross-border traffic. | It doesn’t mean the entire path from your device to the destination website uses a dedicated line, or guarantee access to a particular platform. |
| Exit IP | The source address a destination service sees when it receives a request. | It doesn’t determine your account region, payment eligibility, or content access on its own. |
Client-reported latency also depends on how it’s measured. A connection test, webpage probe, and actual file transfer measure different things; lower latency doesn’t mean higher throughput. For a practical comparison, keep the target app the same and check page load times, playback consistency, and how quickly connections recover. Don’t chase a single number in the list.
Protocols: check compatibility before network conditions
A protocol defines how a client and server exchange data. Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC are common names, but they aren’t interchangeable switches. The server’s protocol and transport parameters must be supported by your client. Simply changing the protocol name in a configuration won’t make a different service work.
Encryption, authentication, and transport are different layers
Shadowsocks uses its own encrypted proxy mechanism. VMess includes authentication and encryption mechanisms; its specific behavior depends on the implementation and configuration. Trojan typically uses TLS for transport. VLESS doesn’t encrypt content by itself and needs TLS or another suitable secure transport configuration. These protocols can’t be ranked in a fixed order from “most secure” to “fastest.”
Hysteria2 and TUIC are based on QUIC and usually require the underlying network to allow UDP traffic. If your network restricts UDP, the connection may fail even when your client supports the protocol. Conversely, a network that supports UDP doesn’t mean these protocols will outperform TCP-based options in every situation.
Beginners should start with a compatible configuration provided by their account dashboard. Don’t disable certificate verification just to clear an error. Certificate issues can be caused by an incorrect device clock, a domain that doesn’t match the certificate, or a changed configuration. Check the time and subscription first, then review the client version and official documentation instead of switching security settings blindly. These protocols are listed to explain the terminology; this doesn’t mean VPNBaby supports them all.
Traffic routing, Global, and Rule modes
Traffic routing sends different requests to different destinations. Common actions include direct, proxy, and reject. A policy group collects candidate nodes or connection methods for you to choose from, or lets the client choose according to a preset policy. Nodes are connection options, policy groups are selection points, and rules send requests to the appropriate destination.
Rule mode evaluates requests using domains, destination IPs, processes, or other supported conditions. Many clients match rules in order and apply the action for the first match, so rule order matters. Check the client documentation for exact behavior. A broad direct rule near the top can prevent later proxy rules from taking effect.
Global mode usually sends traffic handled by the client through a single policy. It doesn’t mean every app on your device will necessarily use the proxy. Only apps that follow the relevant settings use the system proxy. TUN or a system VPN interface can handle more traffic, but coverage still depends on the platform, routing, and client settings.
- ✅ For everyday use, choose the Rule mode that suits your client, then check which rule matches the request you’re troubleshooting.
- ✅ To troubleshoot, temporarily switch to Global mode for comparison. If access starts working, focus on the rules and policy group.
- ❌ Don’t assume Global mode will fix DNS, account-region issues, or platform access restrictions.
- ❌ Don’t run multiple traffic-routing tools at once and then judge route quality; conflicts can skew the results.
Per-app proxy settings and domain-based routing are also different. The former decides whether to route traffic based on the app; the latter makes decisions based on the request destination. An app may connect to many domains, and a single webpage may load images, scripts, and sign-in endpoints from different domains. If the homepage works but sign-in fails, check the rules for the failed requests—not just the homepage domain.
DNS and clients: checks beyond the connection icon
DNS translates domain names into IP addresses. If the proxy connection is established but DNS requests still use an unexpected local resolver, this is often called a DNS leak. That doesn’t necessarily mean the webpage itself is going direct, nor does a single test prove your overall privacy status. Check the client’s DNS settings, your browser’s encrypted DNS settings, and the actual routing together.
A browser may use its own DNS resolver, while the client may also handle system DNS. When both are in play, the resolver location shown by a test site may not match the exit location. Start by confirming the intended behavior, then review DNS queries and connection logs. Don’t conclude that a node is unavailable just because a test site shows a different region.
Traffic handling varies by platform
Windows and macOS clients often offer system proxy or TUN mode, depending on the app. On Linux, desktop environments, command-line tools, and system services may handle proxy settings differently. If browsing works but terminal requests fail, the issue may be that the terminal app isn’t using the proxy—not a problem with the node.
Android clients often route traffic through the system VPN interface, and some let you exclude or include specific apps. Background restrictions may also interrupt persistent connections. iOS clients typically rely on system network extensions; importing a configuration, granting permission, and turning on the connection are separate steps. When switching platforms, check which subscription formats the client supports rather than assuming all settings will transfer unchanged.
From import to access: troubleshoot step by step
Putting these terms back into the workflow can save you from unhelpful trial and error. When something goes wrong, change one setting at a time and note what happens before and after. If you change the node, mode, and DNS together, it’s hard to tell which change made a difference.
- Check the configuration source. Get the subscription for your client from your account dashboard and review the import message. If the format is invalid, fix compatibility first instead of switching routes.
- Make sure the current configuration is enabled. Check that the running configuration is the one you just imported, then confirm which node the policy group has actually selected.
- Check how traffic is being handled. Enable the system proxy, TUN, or system VPN connection required by your client. If you haven’t completed the initial authorization, the configuration may be present but no traffic will be routed through it.
- Test with the app you want to use. Open the actual website or app, then check whether its requests appear in the client and which policy is applied.
- Check the connection and DNS separately. For a connection timeout, check the node, protocol compatibility, and current network. For a DNS resolution failure, check the DNS route. Don’t treat every error as a route problem.
- Check for app-specific restrictions. A different exit location doesn’t automatically change your account region, payment region, or content access. If the network connects but you still see a region error, check the destination platform’s guidance.
If you need more help, share the client name, operating system, exact error message, and steps you’ve tried. That’s usually more useful than simply saying “it won’t connect.” See the setup guide for general instructions. If you’ve imported the configuration but something still isn’t working, use the troubleshooting guide to narrow down the cause.
Quick summary: A subscription provides configuration, a node handles the connection, a route describes the path, a protocol defines how devices communicate, and traffic routing decides where requests go. A successful import, a successful connection, and access from your target app are separate things to verify. Check the configuration and traffic handling first, then rules and DNS, and finally any restrictions imposed by the destination platform. Don’t draw conclusions from a connection icon alone.