Here’s the short version: a subscription delivers configuration, a node is a connection endpoint you can choose, a route describes the network path, a protocol defines how data is exchanged, and split tunneling determines where requests go. Understanding these layers helps you pinpoint whether an import error, connection timeout or inaccessible site is a configuration, network or routing issue.

Terms at a glance: configuration vs. connection

Client interfaces often place “Update subscription,” “Select node” and “Change mode” side by side, but each control does something different. Updating a subscription won’t fix local permissions, and switching nodes doesn’t necessarily change routing rules. Check the table below before changing settings—it’s often easier than reinstalling the client.

Common client terms and what to check; names vary by client
Term What it means Common misconception What to check
Subscription link A URL for retrieving nodes or a full configuration; it may include access credentials. Treating it as a regular webpage or a single node. Source, validity, import format and client compatibility.
Node A set of server addresses, authentication details and transport parameters. Assuming the region name always indicates the server’s physical location. Actual exit location, protocol support and connection results.
Route The network path from your device to the entry point, exit point and destination service. Judging congestion and reliability by the node name alone. Connection path, congestion and how the destination site performs.
Protocol The rules that govern data exchange between the client and server. Treating protocol names as a speed ranking. Whether the client core, settings and current network are compatible.
Proxy group A set of nodes or connection strategies that rules can reference. Assuming that selecting a group name also selects a specific exit node. The current selection within the group and its automatic selection criteria.
Routing rule A rule that directs requests based on conditions such as domain, address or app. Assuming rules automatically handle traffic from every app. Rule order, fallback action and the scope of traffic interception.

Another term that’s easy to misinterpret is VPN. A VPN icon in your system usually means a network extension or virtual network interface is active; it doesn’t tell you which proxy protocol is being used. Some proxy clients also route traffic through the system VPN interface, so seeing the icon doesn’t prove that every request is using a remote exit.

Subscription links: they provide configuration, not a client

A subscription link might provide only a node list, or it may include proxy groups, routing rules and DNS settings. Once a client reads the configuration, it knows where the servers are, how to authenticate and how to send requests. You still need a compatible client—pasting the link into any network tool won’t make it work.

“Subscription updated successfully” usually means the configuration was downloaded and accepted. It doesn’t mean a node can connect, or that the destination site accepts the current exit. If the import fails with a format error, check which client type the dashboard recommends. If you see a connection timeout, check the node, network and permissions. These are different problems, not one generic failure.

Subscription can also refer to billing. A monthly subscription describes how the service is billed; a client subscription describes how configuration is retrieved. They’re related, but they aren’t the same technical thing. A link may change if its credentials are reset even while your plan is active. Manually refreshing the configuration won’t extend the plan.

Nodes and routes: a region name doesn’t describe the path

A node is more like a connection entry in your client; a route is the network path your data actually takes. The entry point receives your connection, while the exit point sends requests to the destination site—and they may be in different regions. Sites generally identify your location from the exit IP, so check the actual exit after choosing a region rather than relying on the list label.

Direct connections, relays and IEPL lines

A direct connection usually means your client connects to the remote server without an additional relay arranged by the service provider. It doesn’t mean the internet path has no carrier routing equipment. With a relay, you connect to an entry point first, which forwards traffic to another server. This may improve access or make routing easier to manage, but each relay can also add another potential point of congestion.

IEPL stands for International Ethernet Private Line. It describes a network transport method, not a client-side encryption protocol. A private line somewhere along the service route doesn’t mean every segment between your device and the destination site uses that line. Your local connection, both ends of the private line and the route from the exit to the site can all affect performance. A “dedicated line” label alone doesn’t guarantee speed or access to a particular site.

Latency shown in a list usually comes from a specific test method. It may measure the entry point’s response or include part of an application-level handshake. It isn’t the same as download throughput, video buffering or page load time. To evaluate a route, test the sites you actually use on your own network and at typical times. Look at repeated requests and whether switching networks restores access, rather than chasing the lowest test result.

Protocol names: compatibility matters more than abbreviations

Shadowsocks, VMess, Trojan, VLESS, Hysteria2 and TUIC may all appear in proxy clients. They aren’t route tiers or a performance ranking that applies to everyone. Whether they work depends on the server configuration, client core version, transport method and restrictions on your local network.

If you’re new to this, start with the client and import method recommended in the service documentation. Don’t change critical settings just to try a particular protocol. Never disable certificate validation to fix a handshake error. First check your device’s clock, server name and configuration source, then contact support for help verifying the settings.

Routing modes: rules, global mode and traffic interception

Rule-based mode chooses a direct, proxied or blocked route based on conditions. These might include a domain, destination address or app, depending on the client. Rules are generally evaluated in configuration order, so a broad rule may match first and prevent later, more specific rules from taking effect. If nothing matches, the fallback rule determines the route.

Global mode usually sends traffic already captured by the client through the selected proxy strategy. It can’t automatically route traffic from apps that bypass the client. System proxy settings generally affect only apps that follow them. TUN mode or system VPN interception can cover more traffic, but routing, exclusion lists, system permissions and client implementation still matter.

Per-app proxy settings decide whether traffic is intercepted on an app-by-app basis, a feature found in some mobile clients. Be clear about the difference between “proxy selected apps only” and “bypass the proxy for selected apps”—they do the opposite. Existing app connections may not restart as soon as you change the list. Reopen the app and check its connection log.

If only some parts of a site fail, the page, images and sign-in service may use different domains and follow different routes. Try switching modes temporarily to compare results, then check the matching rule in the connection log. Once you find the cause, restore a suitable everyday configuration. Don’t use global proxy mode indefinitely as a workaround for broken rules.

DNS leaks: check the resolver path and exit

DNS translates domain names into network addresses, while a proxy connection carries requests; they can take different paths. If you expect DNS queries to go through the proxy but they’re sent to a resolver on your local network instead, this may be what’s commonly called a DNS leak. It concerns where domain lookups go; it doesn’t mean the contents of your webpages have been read.

Your browser’s encrypted DNS, system DNS, the client’s built-in resolver and an app’s own lookup logic may all be active at once. Encrypted DNS only tells you that queries are protected in transit in a particular way; it doesn’t prove they went through the intended proxy. A test page showing a resolver in a different region from your exit isn’t enough to confirm a leak either, since DNS services may be distributed.

Before troubleshooting, note what you expect: which domains should use the proxy, and which DNS route should handle them. Then compare client logs with test results. Redact subscription credentials and visited domains before sharing diagnostic information. A VPN or proxy doesn’t replace HTTPS: check the connection indicator when visiting a site, and don’t ignore certificate warnings.

From import to verification: follow the dependency order

If you’re connected but sites won’t load, don’t change the protocol, DNS and rules all at once. Check configuration, traffic interception, connection and destination service in that order. Change one thing at a time so you can tell what actually helped.

  1. Check the client. Confirm the supported platform, client and configuration format in the service dashboard. Don’t assume compatibility based on the software name alone.
  2. Import and update. Add the subscription using the appropriate import option. Confirm there are no format errors, then check that nodes and proxy groups appear.
  3. Grant permissions. Make sure the system allows a VPN or network extension, and check whether another network tool is already intercepting traffic.
  4. Select a strategy. Check which proxy group the rules reference and which node is actually selected within that group. Don’t rely only on the region shown on the home screen.
  5. Test a request. Visit a familiar site and check the exit and connection log. If something looks wrong, switch modes temporarily for comparison.
  6. Restore your usual settings. Undo changes made only for troubleshooting. Keep relevant error details and tell support what happened and how to reproduce it.

What else to check on each platform

On Windows and macOS, system proxy settings and TUN mode capture different traffic, and some programs don’t use the system proxy. On Android, check background restrictions, battery settings and per-app lists. iOS network extensions are managed by the system, so don’t assume they offer the same per-process routing as desktop clients. Linux clients vary widely; check command-line environment variables, desktop proxy settings and system routes separately.

Choosing a service: check technical details and billing separately

Once you understand the terminology, separate what the service explicitly promises from what you need to test for yourself. Coverage doesn’t mean every site will be accessible, and support for a platform doesn’t mean every client offers the same features. For setup instructions, see the Guides. To compare usage preferences and billing, see the service selection guide.

VPN96 covers 90+ countries with 250+ routes and allows unlimited simultaneous devices, with bank-grade encryption. No email address is required to get started; use a username and password. Monthly plans reset data each month on the activation date, and mid-cycle upgrades are prorated for the remaining days. Data add-ons don’t expire and remain available until used. A 60-day refund policy is available. Check each price and data allowance on the plans page; don’t infer billing terms from node or protocol names.

Bottom line: Subscriptions provide configuration; nodes and routes determine where connections go; protocols define how data is exchanged; and routing rules and DNS settings determine where requests and lookups travel. Start with a compatible client, then test the route using the apps you actually use. When something goes wrong, troubleshooting one layer at a time works better than repeatedly switching nodes or piling on settings.