This guide to common VPN terms covers subscriptions, nodes, IEPL, global mode and rule mode. They refer to configuration sources, connection targets, network paths and traffic routing respectively, and are not interchangeable. Understanding how they fit together is more useful than memorizing every client setting.
People often use “VPN” as a catch-all term for proxy subscription services. Technically, a network-layer tunnel and an application-layer proxy are different implementations. When a client says “Connected,” it may only mean the proxy is running; it does not mean every app is routing traffic through it.
Subscription Links, Plans and Client Configuration
A plan determines billing and data usage; a subscription link provides access to configuration. A paid plan sets the available data and how it resets. In a client, “subscription” usually means a set of connection configurations that can be updated. The same word is used for two different things. A data package can also be imported through a subscription link without being billed monthly.
When a client accesses a subscription link, it reads server addresses, ports, protocol parameters and, sometimes, policy groups and rules. Some links provide only a node list, while others deliver a complete configuration, depending on the format generated by the service. Updating a subscription refreshes the configuration; it does not reset your plan’s data allowance.
The subscription format must be compatible with the client’s core. The same link may require a different format in another client. An import failure does not necessarily mean there is a problem with your account; the configuration syntax or protocol support may not match. Check the user panel or Guides for import instructions, and avoid sharing your link with unfamiliar conversion sites.
Subscription links often contain account-specific credentials and should be treated like passwords. Before sharing a screenshot, hide the full link, QR code and token. If you suspect a leak, use the reset option in the panel or ask support through a ticket how to proceed.
Nodes, Entry Points and Exit IPs
A node is a connection configuration you can select in a client; it does not necessarily correspond to a dedicated server. Multiple nodes may share an entry point or ultimately use the same exit. A region in a node name usually indicates the exit location, but the name itself does not verify the network route or physical location.
The entry point is the server address your device connects to first; the exit is the public IP address seen by the destination website. With relaying, the entry and exit may be in different regions. So a difference between the connection server’s location and the region identified by a website does not necessarily mean the configuration is wrong.
Geolocation data for an exit IP can vary between databases. A platform may also use account details, payment region, login history and device information to determine access. Switching to a node in another region changes some network conditions, but cannot guarantee account eligibility or content availability on a third-party service.
A policy group determines how a node is selected. Manual selection lets you choose the exit; automatic selection usually picks from available options based on test results; failover tries another option when the current one is unavailable. Frequent automatic switching can change your session’s exit, so check how a policy group works if you need a stable login environment.
IEPL Leased Lines, Relays and Direct Connections
These terms describe network paths, not encryption protocols. A direct connection usually means the device connects straight to an overseas server. Relaying adds a forwarding step along the route. IEPL is an international Ethernet private line, a type of network transport resource. In a proxy service, a private line is generally only one segment of the route; the local connection from your device to the entry point still exists.
| Term | What it usually describes | What to check in practice |
|---|---|---|
| Direct connection | The device connects directly to an overseas server | Local carrier routing, congestion on the international segment and reachability of the destination |
| Relaying | Traffic is forwarded from an entry server to another server | Whether the forwarding route improves performance, and the load on the entry and exit servers |
| IEPL circuit | An international Ethernet private line carries traffic along part of the route | Which route segments the private line covers, and the conditions on the access and exit segments |
Relaying is not the same as a private line, and it is not necessarily slower: it adds a forwarding step but may avoid a poor public-internet route. A private line does not mean the entire path from your device to the destination website is dedicated, and the label alone cannot predict performance during peak hours. Check the route details and test it on the networks and for the tasks you actually use.
Protocols, Transport and Encryption: What Each Does
A protocol defines how a client and server exchange data and authenticate. The transport layer determines how data travels across the network, while encryption protects data on the relevant link. A client’s ability to read a subscription format does not mean its core supports every protocol in it. Versions and specific parameters also affect compatibility.
- Shadowsocks: An encrypted proxy protocol that requires compatible encryption methods and parameters on the client and server. It is not a complete network-layer VPN.
- VMess: A proxy protocol with authentication and encryption mechanisms that can use different transport methods. The imported configuration must still match the server settings.
- Trojan: Typically carries proxy traffic over a TLS connection. The server name must be configured correctly, and the certificate must be verified.
- VLESS: A lightweight proxy protocol that does not encrypt payloads on its own. It is usually paired with TLS or another secure transport configuration.
- Hysteria2: A QUIC-based proxy protocol that relies on UDP network conditions. The client and server must support the corresponding implementation.
- TUIC: Also based on QUIC and supports proxying traffic. It is a different protocol from Hysteria2, so their configurations are not interchangeable.
These are general explanations and do not mean VPNLet offers every protocol listed. “UDP supported” also does not mean every app will automatically use a UDP proxy; that depends on the rules, traffic interception method and client capabilities. Do not disable certificate verification just to clear a connection error—it weakens verification of the server’s identity.
Global Mode, Rule-Based Routing and TUN
Global mode determines which exit is used for traffic already intercepted by the client; it does not ensure that every app’s traffic is intercepted. Common proxy clients route this intercepted traffic through the selected proxy policy. An app that ignores the system proxy settings may never reach the client, so global mode will not control it.
Rule mode matches requests against conditions such as domain names, destination IPs and app processes, then sends them to a proxy, direct-connection or reject policy. Rule order matters: the first matching condition may determine where the request goes. Thinking of rule mode as “proxy overseas, connect directly at home” can help you get started, but real configurations are often more specific.
A system proxy provides a proxy address to apps that support it. TUN mode uses a virtual network interface to intercept IP traffic and often covers more traffic. Support for process detection, UDP, IPv6 and DNS interception still depends on the platform, core, permissions and configuration. TUN and rule mode are compatible and can work together.
Some desktop apps on Windows and macOS ignore the system proxy and need proxy settings in the app or a suitable TUN configuration. Android and iOS often route traffic through the system VPN interface, but per-app support and background restrictions vary. On Linux, check environment variables, routes and the system resolver. If a browser works, that does not mean command-line tools are being routed too.
Bottom line: For everyday browsing, start with a clearly maintained rule configuration. To troubleshoot routing, temporarily switch to global mode for comparison. If an app still cannot connect, check whether its traffic enters the proxy chain instead of repeatedly switching nodes.
What Are DNS Lookups and DNS Leaks?
DNS translates domain names into IP addresses. A DNS leak usually means lookup requests are not following the intended route and are instead handled by another resolver. This may expose DNS activity to an unintended network or return an address that does not match the proxy exit, causing connection issues.
However, direct DNS resolution in rule mode is not necessarily a leak. If the configuration is designed to resolve certain domains locally, that is an intentional routing choice. Compare the result with the expected route rather than treating any local resolver as a failure. Encrypted DNS in the browser, the system resolver and the client’s DNS settings can also affect one another.
First check the client’s DNS interception settings, then see whether the browser is using another resolver and verify IPv6 routing. A DNS test page can help, but the resolver’s reported region does not reveal the actual traffic route. A single browser test also cannot prove that DNS requests from every app follow the expected path.
Latency, Bandwidth and Timeouts: What's the Difference?
Latency measures how long a request takes to make a round trip. Bandwidth describes how much data a link can carry, while actual throughput also depends on the entire route and the service you are using. Low latency does not necessarily mean faster downloads, and a page loading does not guarantee smooth, sustained transfers.
A client’s “latency test” may measure an ICMP response or send a request to a URL through the proxy. Results from different methods are not directly comparable and do not necessarily reflect how quickly a target app responds. A timeout only means an operation did not finish within the allotted time; the cause could be DNS resolution, connection setup, the handshake or remote processing.
When troubleshooting, check which stage the logs stop at. If domain resolution fails, check DNS. If the handshake fails, verify the protocol, certificate and system time. If the connection is established but no content loads, check the rules and destination service. Do not judge an entire route based on a single test result in the node list.
Troubleshooting from Import to Access
To apply these terms in practice, troubleshoot in this order: account and configuration → node connection → traffic interception → destination access. Change one type of setting at a time and keep the original configuration. That way, if you change the protocol, node and DNS all at once, you will still be able to identify the cause.
- ✅ Check the plan status and remaining data in the user panel. Distinguish plan validity from the last time the client subscription was updated.
- ✅ Get the client from a trusted source, import the subscription in a supported format and confirm that the node list appears.
- ✅ Manually select a node in the target region, connect and check the logs for configuration or authentication errors.
- ✅ Use rule mode to access the target app. Check which policy handles its requests and which exit is actually used; don’t rely on the connection toggle alone.
- ✅ If an app fails, check the system proxy, the app’s proxy settings or TUN interception, then verify DNS and UDP requirements.
- ✅ If the issue persists, submit a ticket through the user panel with your system, client version and a redacted error message. Keep your full subscription link private.
With VPNLet, monthly subscriptions reset their data on the activation day each month. Data packages remain valid until used and never expire. Compare the plan prices before choosing, and see the network list for route coverage. Connection issues and third-party account restrictions are different problems. When submitting a user panel ticket, describe exactly what happens.
Here’s the key relationship: a subscription provides configuration, a node sets the connection target, a route describes how traffic travels, a protocol defines how the two sides communicate, and routing rules determine where requests go. Check DNS and traffic interception separately, and you can usually match each client setting to its purpose.