VPN basics: subscriptions, servers, protocols, and routing

Start with the basics: a subscription provides configuration to your client, a node determines the connection endpoint, a protocol defines how data is exchanged, and routing rules decide which path requests take. These terms refer to different layers, so a name alone can’t tell you how fast or private a connection will be.

In everyday conversation, “VPN” is often used as a catch-all for proxy clients and services that provide international routes. Technically, a system-level tunnel and an application proxy work differently. A VPN permission prompt means the client needs access to the system’s network interface; it doesn’t identify a specific protocol or mean every app’s traffic will use the proxy.

VPN glossary: distinguish configuration, connection, and routing

When you come across an unfamiliar setting, first ask whether it controls where configuration comes from, how you connect to a server, or where requests go. The table below puts common terms in context.

Subscription links and clients: how configuration gets loaded

The client is software running on your device; the subscription link is where it gets its configuration. When a provider changes node addresses, you’ll usually need to update the subscription in the client to get the latest settings. Updating a subscription doesn’t change your account and won’t necessarily switch the selected node.

A subscription may contain only node details or include policy groups, DNS settings, and routing rules as well. After importing it, check the configuration the client actually generated rather than assuming everything is ready. An incompatible format, a parsing error, or an expired subscription can all leave the node list empty.

1. Get the subscription link for your client from the service dashboard, and make sure you download the client from a trusted source.
2. Import the link in the client’s configuration or subscription manager. If you need to choose a format, follow the dashboard’s instructions.
3. Update the subscription, then check for nodes, policy groups, and any parsing errors.
4. Choose a node and operating mode, then enable the system proxy or the traffic-routing option required by the client.
5. Test access in a real website or app. A “Connected” status alone doesn’t confirm that requests are using the expected exit point.

Servers and routes: the exit region isn’t the whole path

Node names often include a location or purpose, but they don’t show the actual network path. The entry point and exit point may be in different locations; websites generally see the exit address. The exit location also doesn’t necessarily determine your account or payment region, or the content available to you on a platform.

Direct usually means your device connects straight to a server outside mainland China. Relayed usually means traffic first reaches an entry point, then gets forwarded to an exit point. An IEPL dedicated line describes an Ethernet private-line transport method; a service may use it for only part of the route. The remaining access and exit segments still affect performance.

Providers may use these terms differently. A dedicated line isn’t an encryption protocol, and its label alone doesn’t guarantee low latency, dedicated bandwidth, or access to a particular platform. Check the route details and test webpage loading, app connections, and sustained transfers on your own network.

Protocol names: compatibility matters more than chasing the latest option

Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC may all appear in proxy clients, but they aren’t interchangeable options. The server and client need to match on the protocol, authentication, transport, and security settings.

Shadowsocks uses an agreed encryption method for proxy traffic; VMess has its own authentication and communication mechanisms; Trojan typically relies on TLS to protect transport. VLESS doesn’t encrypt content on its own, so deployment needs an appropriate secure transport. A protocol name alone doesn’t mean the connection is encrypted.

Hysteria2 and TUIC are both based on QUIC and generally require the network to allow the relevant UDP traffic. If your network blocks UDP, the connection may fail; that doesn’t mean your subscription credentials are wrong or that other protocols won’t work.

Beginners are better off using a compatible configuration provided in the dashboard. Avoid changing TLS verification, server names, or transport settings without a reason. If you see a certificate error, check your device’s clock and where the configuration came from instead of disabling verification. This article explains industry terminology; it doesn’t mean VPN76 offers every protocol listed here.

Routing, rule mode, and global mode

Split tunneling is a routing decision; rule-based mode is one way to apply those decisions. A common setup sends local services direct and routes requests that need an international connection through a proxy policy group. The policy group then chooses a node, so rule-based routing and node selection are connected steps.

Rules are usually matched in the order defined by the client, with a fallback rule handling requests that don’t match. Whether rules can match domains, addresses, or processes depends on the client and platform. If a new rule has no effect, first check its order, target policy group, and whether the configuration is active.

Global mode typically sends all requests handled by the client through a chosen proxy or policy group, which can help briefly when troubleshooting routing rules. It doesn’t mean every bit of network traffic on your device is captured: apps that ignore system proxy settings, local network exceptions, and traffic outside the tunnel may still take other routes.

DNS leaks: check the DNS resolution path too

Before opening a domain, your device usually needs to resolve it to an address. If you expect DNS queries to travel through the proxy but they’re sent to your local network’s resolver instead, DNS information may leak. This exposes details about DNS lookups; it doesn’t mean the contents of webpages have been read.

DNS queries may be handled by the operating system, a browser’s encrypted DNS feature, or the client. Encrypted DNS protects queries in transit, but the resolver may still see them; encryption doesn’t automatically route queries through your selected node. When troubleshooting, check both the resolver and the route DNS queries take.

• ✅ Check the DNS mode and resolver configured in the client against its documentation.
• ✅ Check whether the browser has its own DNS settings that could interact unexpectedly with client rules.
• ✅ Use a trusted DNS test page as a reference, and compare the results with the client’s connection logs.
• ✅ After changing the configuration, reconnect and test again. Account for caching and apps that resolve names on their own.
• ❌ Don’t treat the location or number of resolvers shown by a test page as proof that privacy protection is fully working.

HTTPS protects data in transit between your browser and a website; what a proxy tunnel protects depends on its implementation. A “no-logs” privacy policy doesn’t prevent websites from linking your activity through account logins, browser identifiers, or payment details.

Platform differences: the same subscription doesn’t mean the same steps

Windows and macOS clients may offer different ways to route traffic, such as a system proxy or TUN. A system proxy generally depends on apps honoring the proxy settings; TUN may require extra permissions or a network component. After changing how traffic is routed, test the apps you use instead of relying on the client icon.

Android clients often use the system VPN interface to route traffic, and background battery restrictions may interrupt a persistent connection. iOS clients are managed through the system’s network extension framework, so features such as per-app routing don’t necessarily work the same way as on desktop. Linux may require additional service, routing, and DNS configuration; importing a profile alone may not route system traffic.

When moving between platforms, check the client’s supported protocols, subscription formats, and rule syntax one by one. Settings with the same name may still work differently. For setup help, see the beginner’s guide on this site rather than copying configuration snippets from another platform.

Connection problems: troubleshoot configuration, routing, and apps in order

If the node list is empty, check the subscription update and format parsing first. If the list is populated but connections fail, check permissions, network reachability, and protocol compatibility. If only some apps have problems, check the system proxy, TUN coverage, and routing rules. Working through these layers in order helps avoid confusing unrelated issues.

Change one setting at a time and note what happens before and after. When contacting support, include your operating system, client name, mode, and a redacted error message. Hide your subscription link, password, and access token.