VPN Glossary: Separate Configuration from Traffic Routing
The VPN terms beginners most often mix up are subscriptions, nodes, protocols, split tunneling and global mode. They operate at different layers: a subscription provides configuration, a node identifies a connection endpoint, a protocol defines how communication works, and routing rules decide where requests go.
People use “VPN” to mean either a system-wide tunneling service or a subscription to international routes used through a proxy client. A proxy client may also route traffic through a virtual network interface, but that does not make every product, protocol and traffic-handling method the same technology. Before troubleshooting, identify the client you’re using and which apps it actually handles.
| Term | What it means | What it doesn’t tell you |
|---|---|---|
| Subscription link | An address the client uses to retrieve nodes or a complete configuration | Importing successfully doesn’t mean proxying is active |
| Node | A connection entry containing a server address, authentication details and protocol settings | The location in its name may not be the entry point |
| Protocol | The method a client and server use to communicate | A protocol name doesn’t tell you its speed ranking |
| Proxy group | A group that chooses a connection endpoint manually or through an automatic policy | Selecting a proxy group doesn’t guarantee that traffic is proxied |
| Rule mode | Routes requests according to domains, addresses or other conditions | When no rule matches, the fallback policy still applies |
| Global mode | Applies a single policy to requests handled by the client | Doesn’t mean every app on the device is being handled |
| System proxy | Provides a proxy endpoint to apps that follow the system proxy settings | Some apps may ignore this setting |
| TUN mode | Receives and handles traffic through a virtual network interface | Full traffic coverage still depends on routing and exclusions |
Subscription Links and Nodes: Where Configuration Comes From
A data plan is a service entitlement; a subscription link is a way to load configuration. After you purchase or activate a plan, the client still needs to know where the servers are, which protocols to use and how to authenticate. That information usually comes from a subscription. Updating a subscription fetches configuration again; it doesn’t renew your plan or reset your data allowance.
A subscription may contain only a list of nodes, or a complete configuration with proxy groups, rules and DNS settings. Clients support different formats, so a link that works in one client won’t necessarily work in another. If import fails with a format error, check the client category and import instructions in your account panel first.
A node is a specific connection entry in the list. The client may connect to an entry server first, then relay traffic to an exit server. The destination website generally sees the exit address. A node labeled “Japan,” for example, may describe the exit location; the label alone doesn’t reveal the full route or guarantee that a website will accept that exit.
If your account panel shows a plan but the client has no nodes, first check whether the subscription link was copied in full, whether the configuration can be fetched and whether the client supports its format. If nodes appear but won’t connect, check the plan status, selected node and client error message. Treat these as separate problems.
Protocol Names: Compatibility Matters More
Shadowsocks, VMess, Trojan, VLESS, Hysteria2 and TUIC are different proxy protocols or protocol implementations, not interchangeable labels. Both ends of a connection must support the relevant implementation, and the authentication details, transport settings and server configuration must match. Changing the protocol name shown in a client won’t convert the connection.
Encryption, Transport and Proxy Protocols Aren’t the Same Thing
Shadowsocks provides encrypted proxying; VMess has its own authentication and encryption mechanisms. Trojan typically uses TLS for secure transport. VLESS does not encrypt payloads on its own and needs to be paired with an appropriate secure transport configuration. Hysteria2 and TUIC are based on QUIC and rely on UDP, so network restrictions on UDP can affect availability.
These differences help explain compatibility, but they don’t establish a speed ranking that applies to every network. Your experience also depends on the exit, route congestion, client implementation and local network. Smooth web browsing doesn’t prove that UDP gaming or sustained transfers will work just as well.
When choosing a client, check that its current version and core support the specific protocols and transport combinations in your subscription. Support for a protocol doesn’t guarantee support for every extension or configuration. If import reports an unsupported node, follow the official instructions to update the client or choose a compatible format. Don’t blindly remove fields such as authentication details or certificate checks.
IEPL, Relays and Direct Connections: Understanding the Route
Protocols describe how devices communicate; route types describe how traffic travels across the network. A direct connection usually means the client connects straight to the target proxy server. A relay typically accepts the connection at an entry point and forwards it to another server. A longer relayed route isn’t necessarily slower, and fewer steps on a direct route don’t guarantee better performance at peak times.
IEPL stands for International Ethernet Private Line, a dedicated Ethernet connectivity service provided by a carrier. In subscription services, an IEPL label often describes one segment of the route—not every leg between your device and the destination website.
Your local network connection to the entry point, the public network between the exit and the website, and the provider’s capacity planning can all affect performance. A route label is not an encryption protocol: even on a dedicated line, transport security depends on the protocol and client settings in use.
On the same device and local network, test against the same destination service. Observe page loading, dropped connections and app errors. Keep an alternative route available. Node names, route types and protocol names can help you organize options, but they can’t replace real-world testing.
Split tunneling and global mode: What decides where requests go?
Rule mode uses conditions in the configuration to select a policy—for example, sending local services direct, routing specified international websites through a proxy, or rejecting certain requests. Common conditions include domains, domain suffixes, destination address ranges and processes; the supported options vary by client. Most rule engines check rules in order, but consult the documentation for your client.
A proxy group sits between rules and the actual nodes. A rule may send a request to a group, which then uses a manually selected node or chooses one automatically according to its configuration. Checking only the “current node” may not be enough: find out which rule matched the request, which proxy group handled it and which exit it ultimately selected.
Global mode usually sends requests already handled by the client through a single policy, making it useful for checking whether a rule is routing traffic incorrectly. Some clients let that policy use a direct connection, however, so global mode doesn’t prove that proxying is active. More importantly, it usually won’t make apps that bypass the client start following the system proxy.
Use Rule Mode Day to Day; Switch Temporarily for Troubleshooting
If the same node opens a website in global mode but fails in rule mode, check the rule match log, proxy group and DNS behavior. If both modes fail, check the node connection, local network and destination service. Switching modes is a troubleshooting tool, not a reason to use global mode as a permanent fix for every issue.
If you need to access local network devices or services, check the bypass rules too. Replacing the entire rules file without checking can disrupt existing local routes. Save a recoverable copy before making changes and adjust only the conditions related to the problem where possible.
System Proxy, TUN and DNS: Why Some Apps May Still Bypass the Client
Windows and macOS clients commonly offer system proxy and virtual network interface options. Browsers usually follow the system proxy, but command-line tools, games and apps with their own networking stack may use different settings. On Linux, desktop proxy settings and terminal environment settings can also be separate. Check each app rather than relying on the desktop status icon.
On Android and iOS, some proxy clients use the system-provided VPN interface to handle traffic, and the system displays a connection indicator. That indicator confirms the interface is enabled; it doesn’t mean the underlying connection uses a traditional VPN protocol. App exclusions, routing settings and system restrictions can still change which traffic is covered.
DNS translates domain names into addresses. Even when a web connection goes through a proxy, DNS queries may still reach an unexpected resolver. When queries are meant to follow a specific route, this is commonly called a DNS leak. Assess the result against your intended policy; a local DNS query isn’t automatically a fault.
A browser’s encrypted DNS, the system resolver and the client’s DNS module may all be active at the same time. The resolver name on a test page alone doesn’t prove that the entire traffic route is correct. Check the client connection log, DNS configuration and app settings to see which component sent the query and which route it took. Don’t disable certificate checks or copy DNS settings from an unknown source just to make a test result look consistent.
From Import to Testing: A Beginner’s Checklist
Putting these terms into the actual setup process makes troubleshooting more straightforward. Check the result after each step. Avoid changing nodes, rules and DNS all at once, or you won’t know which change made a difference.
- Check your account panel. Confirm that your plan is active, then get the subscription link for your client. A VPNWorth account requires only a username and password—no email address. Use the client and subscription details shown in the panel after you sign in.
- Check the client source and compatibility. Get the client through the channel recommended in the account panel, then confirm its platform, version and protocol support. Don’t assume two similarly named apps accept the same format.
- Import and update the configuration. Paste the subscription link or use an import method supported by the client. Once the node list appears, check for parsing errors; a partial import isn’t a complete success.
- Select a policy and enable traffic handling. Choose a node or proxy group, then enable the system proxy or virtual network interface if needed. If the system asks for permission, read the prompt and confirm that it names the client you’re using.
- Test the app you need. Check the browser exit first, then open the app you actually need to use. If it fails, review the connection log to distinguish a subscription fetch failure, server connection failure, direct routing by a rule or a rejection by the destination service.
- Keep a recoverable configuration. Once the connection works, adjust rules or DNS one change at a time. Before sharing diagnostics, redact subscription tokens, authentication details and personal information. If needed, report the issue through the support ticket system in the account panel.
- ✅ Nodes appear in the list: the configuration was read, but the connection still needs to be tested.
- ✅ The browser exit matches expectations: this browser request used the expected route.
- ❌ Global mode is enabled: that doesn’t prove every app and DNS query is being handled.
- ❌ A node is labeled “dedicated line”: that doesn’t mean every destination website will be accessible.
Keep this chain in mind: the subscription provides configuration, the client applies it, the node handles the connection, the protocol governs communication, rules decide where requests go, and the traffic-handling method determines coverage. Follow the chain one step at a time to find problems more effectively than repeatedly switching settings. For more setup help, see the Guides and user handbook.