This VPN glossary starts with how the pieces fit together: a subscription provides configuration, nodes are available connection endpoints, routes describe the path traffic takes, protocols define how it is carried, and split tunneling determines which requests use the proxy. Global mode changes the scope of proxy handling. These are different layers, so no single label tells you everything about the connection.
What people call a VPN client may actually use proxy protocols and a virtual network interface rather than a traditional enterprise VPN. Seeing a VPN icon in the interface does not mean every app's traffic is being routed the same way. Understanding the distinctions below is more useful for troubleshooting than repeatedly toggling settings.
Common terms at a glance
| Term | What it means | Common confusion |
|---|---|---|
| Subscription link | An address used to retrieve nodes or a full configuration. The response format depends on the service and client. | It is not a website membership subscription, and not every client can read it directly. |
| Node | A set of connection details, such as a server address, port, protocol, and authentication credentials. | A name in the list does not verify the actual exit location. |
| Route | The connection path from your device to the entry point, through the transport network, and out to the destination. | The same exit region can be reached over different network paths. |
| Protocol | The conventions clients and servers use to communicate, authenticate, and carry proxy traffic. | A protocol name alone says nothing definitive about speed or privacy. |
| Split tunneling | Directs requests according to conditions such as domain, destination address, or process. | Requests that do not match a rule follow the default policy. |
| Global mode | Typically sends all requests handled by the client through the selected policy. | It does not automatically take over every network connection on the device. |
| Exit IP | The address a destination website sees as the source of your connection. | IP geolocation databases, account region, and actual exit location may not agree. |
Quick takeaway: If importing fails, check the subscription format. If you cannot connect, check the node and your local network. If some apps do not work after connecting, check traffic interception and split-tunneling settings. Do not blame every issue on a “bad protocol.”
Subscription links and nodes: from configuration to connection
Think of a subscription link as an address for retrieving configuration. A client may receive a list of nodes or a full configuration containing rules, policy groups, and DNS settings. Whether a link can be imported depends on whether its format is supported by the client and its core—not simply whether it opens in a browser.
A node is a connection entry in the configuration. It may include a server hostname, port, password or other authentication details, and settings such as TLS and transport method. Node names often indicate region or purpose, but they are labels; verify the actual exit using an IP lookup and the behavior of the destination service.
Updating a subscription retrieves the configuration again; it does not renew a plan or add data. An updated full configuration may also overwrite manually edited rules, so check how your client handles updates before making changes. Subscription URLs often contain access credentials and should be protected like passwords.
Do not post a full subscription link in a public forum or submit it to an unfamiliar website to “convert the format.” If the link is exposed, check whether the service panel lets you reset it, then update it in your client.
IEPL dedicated lines, relays, and direct connections
A direct connection usually means the client connects straight to an overseas proxy entry point, with the cross-border leg relying mainly on your local carrier and public internet routing. A relay adds a forwarding point along the way: the client connects to a relay server first, which then forwards traffic to the next server. An extra hop is not automatically slower; route quality, congestion, and forwarding capacity matter more.
IEPL is an international Ethernet private line service provided by telecom carriers. When a proxy service labels a route IEPL, it usually means that one segment of the path uses this type of transport; it does not mean the entire journey from your device to the destination website uses a dedicated line. Local access, entry-point load, and the connection from the exit to the website can still affect performance.
Dedicated lines, relays, and direct connections are not a simple ranking from best to worst. Compare their performance on the networks you use, at the times you connect, and with your target apps. A region name only describes the region assigned to the configuration; a “Japan node,” for example, does not guarantee access to all content available in Japan.
What protocol names tell you
Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC are all common in proxy clients, but they differ in authentication, encryption, and transport design. Use the notes below to understand the settings—not as a protocol performance ranking, or as an indication that LogoVPN supports every protocol listed.
- Shadowsocks: An encrypted proxy protocol that requires matching encryption methods and authentication settings on the client and server. It is not a specific type of route, and the same protocol name does not guarantee the same speed.
- VMess: A proxy protocol with authentication and encryption mechanisms that can be paired with different transport methods. Whether it works depends on matching settings and implementation compatibility.
- Trojan: Typically uses TLS to protect communications. Certificate validation, server name, and authentication details must be correct; disabling certificate verification is not a routine fix.
- VLESS: The protocol itself does not encrypt content. Consider it alongside the appropriate secure transport settings; when you see VLESS, also check related settings such as TLS or REALITY.
- Hysteria2 and TUIC: QUIC-based proxy solutions that rely on UDP. They may fail to connect if your current network restricts UDP or the client core does not support the protocol.
A client claiming to “support a protocol” does not necessarily support every extension or setting. First check the client version, core, and subscription format. Then consider changing protocols; do not assume one option is best for every network based on its name alone.
Choosing between rule-based routing and global mode
Rule mode matches requests in configuration order. For example, you might send certain domains through a proxy policy and local network traffic through a direct policy. Rules may also match destination IPs, and some clients support process-based matching. The order and final default policy matter: a request is generally handled by the first matching rule.
Global mode is often useful for checking whether a rule is missing. It typically sends requests already handled by the proxy workflow through the selected policy. However, a desktop app that ignores the system proxy may never send its traffic to the client. TUN mode uses a virtual network interface to capture more traffic, but routing, exclusions, and client implementation still matter.
For everyday use, prefer rules from a trusted source with a clear purpose. To check whether a website is affected by a routing rule, temporarily switch to global mode for comparison, then restore the original configuration. Avoid changing the node, DNS, and rules at the same time; otherwise, even if things work again, it will be hard to identify the cause.
- ✅ If a website will not load, check the matched rule and selected policy in the connection log first.
- ✅ If your browser works but another app does not, check whether that app follows the system proxy.
- ✅ If local network devices have connection issues, check that the relevant direct or exclusion rules are in place.
- ❌ Do not treat “global mode on” as proof that every app's traffic is being captured.
DNS leaks and exit checks
DNS translates domain names into addresses that can be reached. If you expect both a website request and its DNS lookup to follow a particular route, but the lookup goes over your local network to an unexpected resolver, a DNS leak may occur. A website showing your proxy exit only tells you where the related web request came from; it does not by itself confirm that DNS took the expected path.
When checking, consider the client's DNS settings, system settings, and the browser's secure DNS feature. Browsers may resolve names independently, and apps may have their own resolution logic. The resolver region shown by a DNS test is only a clue; a different region alone does not prove a leak.
Also consider IPv6: if the client captures only some traffic, an app may connect over another available route. Check client documentation for IPv6 support and routing behavior rather than disabling system features without cause. Start by using IP lookup to check the current web exit, then review connection logs to verify traffic from a specific app.
Client setup and troubleshooting steps
On Windows, macOS, and Linux, setup may depend on the system proxy, TUN permissions, and desktop environment. On Android, app-scope settings can affect which traffic is captured; on iOS, you typically need to allow a VPN configuration to be added. Menus and core support vary by platform, so follow the client instructions in the service panel. Check the panel for iOS permission instructions as well.
- Get a compatible client. Check the panel for available clients and instructions. Confirm that the client supports the subscription format and node protocol, not just that its name looks familiar.
- Copy and import the subscription. In the client, choose the subscription or configuration import option, paste the full URL, and wait for it to finish. Do not paste it into the server address field for an individual node.
- Select a configuration and node. Make sure the imported configuration is enabled, then choose a node or policy group. A successful subscription import does not mean a connection has started.
- Allow the required permissions. Follow system prompts to add a network configuration or authorize the relevant network feature. Do not disable certificate checks to work around an error.
- Verify each step. First confirm the connection is established, then check the exit, and finally open the app you want to use. If something goes wrong, save the error message and change one setting at a time.
If the subscription download fails, first check that the URL is complete, the network can reach it, and the service status in the panel. If it downloads but contains no nodes, check format and core compatibility. If a node connects but the target app still does not work, check rules, DNS, account region, and restrictions imposed by the service itself. For platform setup instructions, see Guides.
Setup summary: First make sure the subscription, client, and node settings are compatible. Then check whether the route suits your network, and finally troubleshoot split tunneling and DNS. A successful connection, a changed exit, and access to the target app are separate results—verify each one independently.