This VPN glossary for beginners explains subscriptions, nodes, protocols, routing, global mode, and rule-based routing in practical terms. When you first open a client, there’s no need to change every setting. First find out where the configuration comes from, how the connection is routed, and which apps use it. Then adjust the settings.
One terminology point is worth clearing up: a “VPN client” may refer to a system-wide tunnel app or a proxy client. They handle traffic differently. A connection indicator in your system settings doesn’t mean every app uses the same route.
Subscriptions and nodes: where configuration comes from and where you connect
A subscription is how a client gets its configuration. A service provider’s subscription link typically lets the client retrieve nodes and connection settings, and may also include routing rules or policy groups. Here, “subscription” refers to configuration, not a billing period; monthly subscriptions and data plans are pricing terms.
For example, when switching devices or updating routes, import the link into a supported client and refresh it to retrieve the provider’s current configuration. Refreshing a subscription does not renew your plan or update the client app. Check your plan status, configuration update time, and client version separately.
A node is a selectable connection profile. It typically includes a server address, port, authentication details, and protocol settings. The region shown in the client can help you choose, but it doesn’t prove connection quality. The node’s entry location may differ from the location of the final traffic exit.
For example, if you need to access content for a particular region, select an exit in that region and verify the result in the target app. Account region, content licensing, and fraud-prevention policies can also affect access, so don’t rely on a node’s name alone.
Direct, relayed, and IEPL routes: what’s the difference?
Route types describe the path, not the protocol. A direct route typically connects the client straight to an overseas service endpoint. A relayed route usually goes through a relay before reaching another server. IEPL refers to an international Ethernet private line, a dedicated-link service provided by a carrier.
| Term | In plain English | Use cases and what to check |
|---|---|---|
| Direct | Connects straight to the service endpoint without a separate relay operated by the provider. | Useful for an initial connection test; performance depends on your local network and the route between networks. |
| Relayed | Traffic is received and forwarded by an intermediate endpoint. | Worth comparing when the direct route is poor; check performance in the app, not just the response time to the relay. |
| IEPL private line | One section of the route uses a dedicated international Ethernet link. | Check which section uses the private line; local access and the final exit still affect performance. |
A relay is not necessarily a private line, and a private line does not mean the entire end-to-end route uses dedicated links. Your home network, load at the entry point, and the route from the exit to the destination website all contribute to the connection. Seeing “IEPL” in a client doesn’t guarantee lower latency, higher speeds, or access to every website.
Protocols: how clients and servers communicate
A protocol is a set of rules for communication between two sides. Even with the right address, a connection won’t work if the client doesn’t support the protocol. The same protocol can also use different transports, encryption methods, and certificate settings, so matching the protocol name alone isn’t enough when configuring it manually.
- Shadowsocks: An encrypted proxy protocol. A typical configuration includes a server, port, password, and encryption method. Use it to import a compatible proxy node; supported encryption methods depend on the client.
- VMess: A proxy protocol commonly used with clients that support the relevant core. When importing it, match the transport and security settings as well as the user ID.
- Trojan: Typically establishes an encrypted connection over TLS. Check the password, server name, and certificate verification settings. Don’t disable verification just to clear an error.
- VLESS: A lightweight proxy protocol that does not provide content encryption on its own. It is typically used with TLS or another security layer. Connections depend on the corresponding transport and security settings.
- Hysteria2 and TUIC: QUIC-based proxy protocols that require the underlying network to allow the relevant UDP traffic. If a connection fails, check the network and client support instead of repeatedly changing the password.
These are general industry terms, not a list of protocols supported by InnVPN. Refer to the configuration available in your account panel and the client’s documentation. When choosing a client, first check whether it can fully import your configuration rather than judging by a protocol’s name or age.
Routing, rule-based routing, and global mode
Routing determines where a connection goes based on conditions. Conditions may include a domain, destination address, app process, or rule set. The result is usually a direct connection, a proxy policy group, or a blocked connection. Rule-based routing handles requests according to these conditions.
A common setup sends local services directly and routes international websites through a proxy. Rules are matched in the order set by the client, and the first matching rule usually determines where traffic goes. A final fallback rule handles connections that don’t match. Syntax and priority vary by client, so don’t copy rules between apps without checking compatibility.
Global mode generally sends all connections handled by the client through the selected policy. The key phrase is “handled by the client.” If an app doesn’t use the system proxy and its traffic isn’t captured by a tunnel, switching to global mode may not affect it.
Global mode can help you temporarily check for routing-rule issues. Rule-based routing is usually better for everyday use when different destinations need different routes. When testing is done, switch back to the mode you need instead of leaving an unfamiliar setting on.
Check which traffic the client handles before checking the mode. If a browser works but a desktop app doesn’t, first check whether that app’s traffic passes through the client. If a website uses the wrong exit, check the rules and policy group. Global mode isn’t a universal fix for connection problems.
System proxy and TUN: how apps enter the proxy route
A system proxy provides proxy settings for apps to use. Apps that read these settings will connect through the proxy; apps that manage their own networking may ignore them. Command-line tools may also require proxy environment variables; check the tool’s documentation.
TUN is a virtual network interface. The client uses it to receive routed network traffic and decide how to forward it. It can cover some apps that don’t use the system proxy, but remains subject to routing, exclusions, permissions, and platform limitations. Enabling TUN doesn’t mean you can ignore routing rules.
Support for system proxies and TUN varies across clients on Windows, macOS, and Linux. Android clients often use the system VPN interface to handle traffic and may offer per-app settings. iOS typically establishes a tunnel through a system network extension; app behavior in the background and available settings depend on both the app and the operating system.
Use the download links in your service panel. InnVPN clients and subscriptions are available after you log in. On Android, Windows, macOS, and Linux, you can download the client after logging in; iOS availability depends on the active plan shown in the panel. Desktop toggle names aren’t universal across platforms. For platform-specific steps, see the guides.
DNS, exit IPs, and leaks: what each check tells you
An exit IP is the address the destination service sees as the source of a connection. A browser-based IP check can confirm the route used by that browser, but it doesn’t test other apps. In rule-based routing, different destinations using different exits may be expected.
DNS is the process of resolving domain names to network addresses. DNS queries and subsequent content connections may take different routes. When checking DNS, confirm that resolution requests are handled as configured; the region shown for a resolver alone doesn’t prove a leak.
A DNS leak generally means that a DNS request expected to be protected by a proxy or tunnel has unexpectedly taken a different network path. Encrypted DNS built into the browser, system resolver settings, DNS handling by the client, and caching can all affect the result. Avoid changing everything at once, or it will be difficult to identify the cause.
From importing a subscription to testing the connection
Once you understand the terminology, follow the steps below. Change one thing at a time and note what happens; this usually makes it easier to find the cause than repeatedly reinstalling the app.
- Find the right source. Sign in to your service panel, check your plan status, and get the client and subscription for your platform. Don’t copy configuration from an unfamiliar website.
- Import and refresh. Use the client’s subscription import feature and check whether it loads the nodes successfully. If you see a format error, first check whether the client supports that subscription format. Don’t submit the link to an untrusted online converter.
- Choose a connection. Select a node and policy group, keeping the basic settings recommended in the guide. Automatic selection and failover are client features; they don’t guarantee the best route for every app.
- Check traffic handling. Make sure the system proxy, tunnel, or per-app settings match your needs, then test in the target app. If needed, disconnect and restart the app so it doesn’t reuse an existing session.
- Verify the result. Check the exit IP, DNS, and the target feature separately. If the problem persists, note your platform, client version, mode, node name, and error message, then consult troubleshooting.
- ✅ Imported successfully but can’t connect? Check the node configuration, protocol support, certificates, and current network conditions.
- ✅ Browser works but an app doesn’t? Check the app’s proxy settings, TUN coverage, and routing results.
- ✅ Website loads but a feature is unavailable? Check your account region, the website’s policies, and the feature itself instead of blaming the route alone.
- ❌ Don’t share full subscription links, authentication details, or logs containing credentials. Redact sensitive information before contacting support.
Remember the basics: a subscription provides configuration, a node specifies the connection, a protocol defines how it communicates, a route describes the path, and routing rules determine where traffic goes. When something fails, check each part in turn. Whether a setting is right ultimately depends on how the target app works in practice.