VPNbasics: distinguish configuration, routes and rules
Here’s the short version: a subscription provides configuration, a node is a connection endpoint, a protocol defines how data is exchanged, and routing rules determine where requests go. These settings operate at different levels. Changing nodes doesn’t change the protocol or switch to global mode.
A “VPN client” may be a system-level tunneling app or a proxy client. Similar names don’t mean they handle traffic in the same way. A VPN icon on your device only indicates that a related network interface is active; it doesn’t prove that every app’s traffic is routed through a remote exit.
| Term | What it does | What it doesn’t tell you |
|---|---|---|
| Subscription link | Provides nodes or a complete configuration to the client | A successful import doesn’t mean you’re connected |
| Node | A connection entry with a server address, authentication and protocol settings | The region in its name doesn’t tell you every region the route passes through |
| Protocol | Defines how the client and server exchange proxy traffic | A protocol name doesn’t indicate route quality |
| Route type | Describes how the connection and data path are set up | A dedicated-line label doesn’t guarantee access to a particular platform |
| Routing rule | Sends matching requests to a direct, proxy or block policy | Selecting a node doesn’t mean every request uses it |
Subscription links: configuration sources, not connection switches
“Subscription” can mean two different things: in a client, it usually means a configuration feed; in a plan, it usually means a billing arrangement. One is a technical entry point, the other a service term. A configuration URL might return a list of nodes or a complete profile with proxy groups, rules and DNS settings, depending on its format and client support.
“Update subscription” means fetching the configuration again, not speeding up your current connection. An update may change node names, available entries or rules. Whether manual changes are preserved depends on the client. When you need to customize a profile, use the client’s override feature if available, rather than editing settings that an update may overwrite.
A link for sharing one node is different from a subscription URL. The former usually describes a single connection entry; the latter provides ongoing access to configuration. Don’t assume a link can be imported based only on its prefix. Check the panel for the intended client and format. If your client doesn’t support a format, pasting it repeatedly won’t fix compatibility.
Nodes and exit locations: names, entry points and regions
A node entry usually includes a server address, port, authentication details and protocol options. Its display name is just a label for convenience, not technical proof of anything. A node named for a particular region might connect through an intermediate entry point before reaching the destination website from that region.
The entry point is the server address your device connects to first; the exit is the source address seen by the destination website. They can be different. So a mismatch between the connection address region and the region identified by a website doesn’t automatically mean the configuration is wrong. To check your apparent location, look at the actual exit and consider how the target platform determines location.
A proxy group is a container for selecting nodes. A manual group lets you choose an entry; an automatic group may switch based on connectivity tests. A test only reflects connectivity to a specific destination at a particular time. A node marked available isn’t necessarily suitable for video streaming, file transfers or persistent connections.
First check whether the request is going through the proxy, then check which entry the proxy group selected. If a page behaves the same after you change nodes, the request may still be going direct—not necessarily because the new node failed to take effect.
Protocol terminology: don’t rank speed by name
Shadowsocks, VMess, Trojan, VLESS, Hysteria2 and TUIC may all appear in proxy clients, but they aren’t tiers on a single performance scale. Compatibility depends first on the client’s core version, server configuration and underlying network conditions. These are general explanations; they don’t mean VPNE8 currently offers every protocol.
- Shadowsocks: A family of encrypted proxy protocols. The client and server need to use matching encryption methods and keys; capabilities also depend on the implementation and version.
- VMess: A proxy protocol with authentication and related transport settings. Some configurations are sensitive to clock skew, so check that your device’s time is correct if you have connection issues.
- Trojan: Typically carries proxy traffic over a TLS connection. The certificate, server name and authentication details must match. Disabling certificate verification shouldn’t be treated as a routine fix.
- VLESS: A lightweight proxy protocol that doesn’t provide general-purpose content encryption on its own. It’s typically paired with secure transport settings such as TLS or REALITY. The VLESS label alone doesn’t tell you the complete security properties.
- Hysteria2 and TUIC: Use QUIC over UDP. They may work well on some networks, but if your local network restricts UDP, they may not connect.
Settings such as WebSocket, gRPC and TLS describe the transport or security layer; they aren’t another way of specifying a node’s region. When importing a profile, keep all the parameters provided by the service. Don’t copy an option you found online into an existing configuration. If the client reports an unsupported protocol, check compatibility before changing server fields at random.
IEPL dedicated lines, relay routes and direct connections
A protocol describes how devices communicate; a route type describes how data travels across the network. The same protocol can be deployed over different routes, and the same route type can carry different protocols. Keeping these concepts separate makes it easier to diagnose connection failures without blaming the protocol name for everything.
A direct route typically connects your device to a remote service endpoint over the public internet, so performance depends more on your local carrier and international peering. A relay route adds a forwarding point that passes traffic on to the remote exit. This may improve the connection, but it can also add another point of congestion; results depend on the actual deployment.
IEPL is a common abbreviation for an international Ethernet private line, a dedicated transmission service. In proxy services, the label usually means that one segment of the route uses dedicated-line resources. It doesn’t mean every segment from your home device to the destination website is a dedicated link. The access and exit segments, as well as the destination website, can still affect performance.
A route type alone can’t confirm a streaming platform’s regional decision, the reputation of an exit IP or whether an app will work. For VPNE8’s current route information, see the Nodes page. For platform-specific access requirements, check the access support guide rather than relying on a node name.
Split tunneling, global mode and rule-based mode: two layers of control
To understand routing modes, consider both which traffic enters the client and how it’s handled afterward. System proxy settings and TUN mode mainly affect the first; rule-based and global modes mainly affect the second. They aren’t interchangeable options in the same set of controls.
System proxy directs traffic through the operating system’s proxy settings, but apps don’t always follow them. TUN mode uses a virtual network interface to handle packets that match the routing conditions. It typically covers more traffic, but is still affected by routes, exclusions, permissions and the client’s implementation.
Rule-based mode routes requests according to conditions such as domain, address or process, assigning them to a specified policy. Common policies include DIRECT, REJECT or a proxy group. Rules are usually evaluated in configuration order, with a final fallback rule handling requests that don’t match. Exact syntax depends on the client.
Global mode usually sends requests already handled by the client to the selected policy. It doesn’t automatically capture apps that bypass the client in the first place. If a browser works but another app doesn’t, check how traffic is being captured before assuming global mode has failed. When troubleshooting is done, switch back to rules suited to everyday use to avoid routing unrelated traffic differently.
DNS leaks and exit checks: see where requests actually go
DNS translates domain names into addresses. A DNS leak usually means DNS requests aren’t following the intended route—for example, web traffic goes through a proxy, but domain lookups still go to a resolver on the local network. Seeing a resolver in a different region from your exit doesn’t by itself prove there’s a leak. Check the DNS request’s route and your configuration’s intent as well.
Your browser’s secure DNS, system resolver and client DNS settings may all take part in name resolution. Encrypted DNS only means the query is protected in transit; it doesn’t guarantee that it goes through the proxy. When troubleshooting, check which DNS settings are actually in use, including the browser’s own configuration.
- ✅ Compare your exit IP before and after connecting to check whether your browser requests are routed through the proxy as expected.
- ✅ Check the client’s connection log for matched rules and selected policies. Don’t share any authorization details it contains.
- ✅ Test in the app you actually plan to use; success in a browser doesn’t prove every app will work.
- ✅ Check IPv6 routing and traffic-capture support too, since some requests may take a different route.
- ❌ Don’t treat a “connected” status, VPN icon or successful node test as proof that all traffic is routed through the client.
A service’s “anonymous, no-logs” statement describes its privacy policy; it doesn’t guarantee complete anonymity in your browser. Account logins, site cookies and device characteristics can still link activity. Changing your exit IP won’t automatically clear them.
From import to connection: troubleshoot in order
- Check the client and format. Get a client and subscription link from the panel that match your platform, then follow the setup guide. Don’t use configuration files made for a different client.
- Import and update. Check that the list appears and that the update completes without errors. If import fails, first check the link, network access and format compatibility instead of changing node settings.
- Select a policy and enable traffic capture. Confirm which node the proxy group is using, then enable the system proxy or relevant tunnel feature for your app. Respond to any system permission prompts.
- Verify the app you need. Check the exit, matched rules and target app’s behavior. Change one setting at a time and keep the original configuration so you can identify the cause of any issue.
Windows and macOS clients may offer system proxy settings, virtual network adapters or network extensions, with different permissions and setup locations. On Linux, check whether desktop proxy settings are inherited by command-line programs; some may need proxy environment variables configured separately.
Android and iOS clients often use the system VPN interface to handle traffic, but per-app controls, background behavior and configuration options vary by implementation. Don’t rely on desktop screenshots to find identically named settings. For iOS, check the panel for current availability and setup instructions.
Subscriptions provide configuration, protocols determine connection compatibility, route types define the path, and routing rules decide where requests go. Following that order makes it easier to diagnose issues than repeatedly switching to global mode or changing nodes at random.