Here’s the short version: a subscription provides configuration, a node is a connection endpoint, a route describes the path your data takes, a protocol defines how it travels, and split tunneling determines which requests take which route. These are separate concepts—a node’s name alone can’t tell you its speed, privacy or app compatibility.
Knowing these terms isn’t about memorizing settings. It’s about knowing what to check when something goes wrong. If importing a subscription fails, check the link and format first. If a node won’t connect, check your network and protocol support. If only one app has trouble, start with its routing rules and proxy settings.
How subscriptions, nodes and clients fit together
On a pricing page, “subscription” usually means a billing arrangement. In a VPN client, it usually means a link that lets you update connection settings. The two are related, but they aren’t the same thing. Users with a data plan may also use a subscription link to get nodes; that doesn’t necessarily mean they’re billed monthly.
A subscription link may return node addresses, ports and authentication details, as well as policy groups, routing rules and DNS settings. What it includes depends on the provider’s format and the client’s capabilities. After a successful import, the client turns the configuration into selectable nodes or policy groups.
A node is a set of connection parameters, not necessarily a separate physical server. Multiple nodes may share an entry point or exit, and nodes in the same region may use different routes. Region, dedicated-line and use-case labels are informational; verify the actual exit and availability after connecting.
A subscription link usually contains access credentials, so treat it like a password. Don’t post it in public forums or submit it to an untrusted online conversion site. If it’s exposed, look for a reset option in your account panel or contact support.
How to tell IEPL connections, relays and direct connections apart
A route describes the path, not the protocol. The connection from your client to the entry point, from the entry point to the exit, and from the exit to the destination website can all affect your experience. An exit in Japan doesn’t mean the entire route uses local Japanese networks, or that a dedicated line is involved.
| Type | What it usually means | What to consider |
|---|---|---|
| Direct connection | The client connects directly to an overseas proxy entry point; the cross-border segment usually uses the public internet. | Performance can be affected by your local ISP, cross-border routing and peak-time congestion. Fewer hops don’t necessarily mean a better experience. |
| Relay | The client connects to an intermediate entry point, which then forwards traffic to an overseas exit. | Both entry-point availability and the onward route matter. A relay isn’t automatically a dedicated line. |
| IEPL dedicated line | Usually refers to an international Ethernet private line on the cross-border segment. | It doesn’t mean your home connection or the destination website also uses a dedicated line, nor does it guarantee the same experience at all times. |
A dedicated line mainly affects the transmission path and capacity planning; it doesn’t change a third-party platform’s regional rules. Streaming services and AI tools may also check your exit IP, account region and risk signals. Choose a route for the region your app requires, then check how reliably it works in practice. “Dedicated line” isn’t a promise of permanent availability.
In short: A node’s region tells you where traffic exits; the route type tells you how it gets there. For a fair comparison, keep your local network, target app and time of use consistent, then watch for recurring lag or connection drops.
What common protocols do
A protocol defines how the client and server authenticate, encapsulate and transmit data. Shadowsocks, VMess, Trojan, VLESS, Hysteria2 and TUIC are common in proxy-client ecosystems; they aren’t the same as traditional, device-wide network tunnels. Whether an app’s traffic uses a proxy also depends on how traffic is routed.
- Shadowsocks: An encrypted proxy protocol. Its security properties depend on the protocol version and encryption method. It isn’t HTTPS in your browser, and it won’t automatically route traffic from every app through the proxy.
- VMess: Includes authentication and encryption mechanisms and can be paired with different transport methods. A configuration that uses WebSocket doesn’t necessarily have TLS enabled; check the transport and security settings separately.
- Trojan: Typically relies on TLS to protect the connection, so certificate validation and matching the server name are important. Disabling certificate checks shouldn’t be a routine fix for connection errors.
- VLESS: The protocol itself doesn’t encrypt payloads; it’s typically combined with mechanisms such as TLS or REALITY. Seeing the name VLESS alone doesn’t tell you how the full connection is secured.
- Hysteria2 and TUIC: Both are based on QUIC and rely on UDP, but they’re different protocols. Network restrictions on UDP can affect the connection; neither is automatically faster than other protocols.
A protocol appearing in a client’s interface doesn’t mean that version supports every option a provider offers. Converting a subscription format can’t make an unsupported protocol work in a client’s core. Beginners should use the matching option provided in the account panel rather than switching apps just to try a particular protocol.
This article covers general technical concepts, not VPN72’s protocol support. Check the account panel for the protocols, clients and routes currently available.
Global mode, rule mode and TUN
In most rule-based proxy clients, “global mode” sends requests that have entered the client through the selected proxy policy. “Rule mode” chooses direct, proxy or blocked access based on conditions such as domain, destination address or app process. Rules are usually matched in order, with a fallback rule for requests that don’t match; exact behavior depends on the client.
The most common misunderstanding is the word “global”: it usually doesn’t mean every app on the device is routed through the client. If a game, command-line tool or office app doesn’t use the system proxy, its traffic may bypass the client even when global mode is on.
A system proxy tells apps that honor the setting where to find the proxy. TUN mode uses a virtual network interface to capture IP traffic that matches its routing rules. TUN isn’t another node protocol, and it doesn’t automatically handle every DNS, local network or IPv6 route. It usually requires additional permissions and may conflict with a corporate VPN or other networking tools.
For everyday browsing, start with the routing rules provided by the service: send requests that need international routes through the proxy and keep suitable services on their local path. If one website has a problem, temporarily switch to global mode as a comparison. If it works, review the rules and DNS settings rather than leaving global mode on as a fix for everything.
Understanding DNS leaks and exit IPs
DNS translates domain names into addresses. Routing web traffic through a proxy doesn’t guarantee that DNS queries take the same route. Apps, browsers, the operating system and the proxy client may all handle DNS. A browser’s built-in encrypted DNS setting may also differ from the client’s configuration.
A DNS leak is worth investigating when queries expected to use a particular route are instead sent to an unexpected resolver. Encrypted DNS means the query is protected in transit; it doesn’t automatically mean it went through the proxy. A test page showing a particular DNS provider doesn’t, by itself, prove there’s a leak.
- ✅ Set expectations first: which domains should use local DNS, and which should be resolved through the proxy?
- ✅ Check the client’s DNS handling settings and whether your browser overrides the system or client settings.
- ✅ Consider the exit IP, resolver details and client connection logs together; don’t rely on a single test-page result.
- ❌ A correct exit region doesn’t prove that every app and DNS query is being routed through the client.
Check IPv6 too. If your configuration handles only some address families, an app may use another available route. Check routing and DNS behavior in your client’s documentation rather than treating IPv6 as something to disable for every connection problem.
Steps from import to verification
Check your account plan and client compatibility before troubleshooting the connection and routing rules. VPN72 subscription details are available after signing in. On platforms other than iOS, you can download the client after signing in; the iOS client option depends on your current plan in the account panel. Check the panel for the available buttons and installation steps.
- Get the right configuration. Choose the correct platform and client option in the account panel. Don’t mistake a webpage address for a subscription link or edit its parameters without a reason.
- Import and update. Use the client’s subscription or configuration import feature. Make sure the node list appears, then check for any format, authentication or update errors.
- Choose an exit and policy. Select a node for the region required by your target app, enable a suitable rule mode, and make sure the relevant policy group isn’t set to direct connection.
- Grant required permissions. System proxy and TUN permissions are different. Follow the client’s and operating system’s instructions; install only from trusted sources and verify the publisher.
- Test the app you actually use. Check the exit region, then open the target service and look for its connection in the client. Finally, test your usual local websites and local network resources.
On Windows and macOS, the system proxy affects only apps that honor that setting; a tray icon can’t confirm that all traffic is routed. Android’s local VPN feature may let you select apps, while iOS commonly routes traffic through a system network extension. On Linux, check desktop proxy settings, environment variables or TUN routes separately. Settings names vary between clients.
Troubleshoot one layer at a time
Subscription update failed: Check your network and account status first, then make sure the link is complete and still valid and that the import format is supported. A failed update isn’t the same as a node connection failure; switching nodes repeatedly may not help.
Nodes appear, but none connect: Check the client version, protocol support and system clock, then compare with another entry point in the same region. If only UDP-based protocols fail, check whether your network restricts UDP before assuming the entire service is unavailable.
Connected, but an app still doesn’t work: Check whether the app is routed through the proxy, which policy the rules selected and whether DNS behavior matches your expectations. If the request reaches the target platform but is still denied, account region, terms of service and exit-IP risk checks may be factors. A connected status doesn’t guarantee that a platform will allow access.
Contacting support: Note your operating system, client name, error message, selected node and steps to reproduce the issue. Redact subscription links, tokens and account credentials from screenshots and logs. Don’t share your full configuration to troubleshoot.
Keep this order in mind: Was the configuration retrieved correctly? → Can the node connect? → Is the app’s traffic being routed? → Do the rules and DNS match expectations? → Does the target platform accept the current access conditions? Troubleshooting one layer at a time makes the cause easier to find than changing everything at once.