VPN Terminology Explained: Nodes, Routes, Protocols, and Global vs. Rule-Based Modes

Why choose a node and routing mode after importing a subscription? Here’s the short version: a subscription provides configuration, a node specifies a connection endpoint, a route describes the network path, a protocol defines how data is exchanged, and routing rules determine where requests go. Each handles a different part of the connection, so they aren’t interchangeable.

People often use “VPN” to refer to both proxy subscriptions and system-level VPNs, but they don’t work in exactly the same way. A proxy client may only handle apps that follow the system proxy settings, or it may route more traffic through a virtual network interface. So “connected” in the app doesn’t necessarily mean every request from your device follows the same path.

What are subscriptions, nodes, and clients?

A client is software on your device that reads configuration, establishes connections, and applies traffic rules. A node is usually a selectable connection profile in the client, with a server address, port, authentication details, and protocol settings. Its name is a label for identification and may not describe the actual network path.

A subscription link is used to retrieve a node list or full configuration. The client reads the link to obtain that data; the link itself is neither proof of a successful connection nor a fixed route. If the provider changes the configuration, you’ll usually need to refresh the subscription in your client to get updated addresses or rules.

First, distinguish the configuration source, connection target, and software that runs it
Term	What it does	What it doesn’t tell you
Subscription link	Provides nodes or configuration to the client	Doesn’t confirm that a plan is active or that you’re connected
Node	Specifies a connection target, authentication, and protocol settings	Its name doesn’t prove its physical location or actual speed
Client	Runs the connection, proxy entry point, and routing configuration	Installing it doesn’t mean system traffic is being routed through it
Proxy group	Organizes nodes and selects one manually or automatically, based on configuration	Automatic selection doesn’t guarantee the best experience for a particular site

“Subscription” can also mean a paid plan, so the context matters. “Update subscription” usually means refreshing the configuration, not renewing a plan; “subscription expired” may mean the account entitlement has ended. If you see either message, check the client’s update status and your account plan separately.

Subscription links often contain access tokens, so treat them like credentials. Don’t post them publicly, include them in screenshots, or paste them into unfamiliar online converters. If you suspect a link has been exposed, use the account’s reset feature to replace it and update it on your devices. Check the service documentation to see what the reset invalidates.

How do IEPL, relays, and direct connections differ?

Direct connection usually means your device connects to an overseas service entry point through your local carrier, without an additional forwarding point in mainland China. Congestion and international peering quality still depend on your local network and carrier routing. Direct doesn’t mean unencrypted: encryption depends on the connection protocol and its configuration.

A relay adds a forwarding server to the connection path. Your device connects to an entry point first, which then forwards traffic to another server. This changes how the route is arranged. A nearby entry point may improve some parts of the connection, but relay load, bandwidth, and the onward route matter too—not just the entry point’s distance.

IEPL generally refers to an international Ethernet private line, a type of transport link. Providers may use a dedicated link for part of a cross-border route, but an “IEPL” label in a client is only a description; check the route details rather than relying on the label. The path from your device to the entry point, or from the exit point to the destination site, may not use a dedicated line.

It’s also useful to distinguish the access region from the exit region. The access region is where your device connects to the entry point; the exit region is generally the network location a destination site sees. A region label may not describe both. Access can also depend on your account region, content licensing, and how the exit address is classified.

Key takeaway: Route types describe the path; protocols describe how data is transmitted. A dedicated-line label alone doesn’t prove a connection is faster or more private, or that it will work with a particular site. When choosing a route, consider your use case and check the full path and actual performance.

What do protocols like Shadowsocks do?

A protocol defines how the client and server authenticate, encapsulate, and transmit data. The client must support the protocol and its specific settings to connect. A protocol name isn’t a speed rating or a complete privacy assessment; implementation, server configuration, and network conditions all affect the result.

Shadowsocks: An encrypted proxy protocol. The client and server need matching addresses, ports, passwords, and encryption methods. Support for additional features can vary between implementations.
VMess: A proxy protocol with authentication and encryption mechanisms that can use different transport methods. Leaving out transport settings when copying a node can prevent it from connecting.
Trojan: A proxy connection that typically uses TLS. Configure certificate validation, server name, and authentication correctly; disabling certificate validation shouldn’t be a routine fix.
VLESS: A lightweight proxy protocol that doesn’t encrypt its payload on its own. It’s typically paired with TLS or another secure transport. The protocol name alone doesn’t tell you how the complete connection is protected.
Hysteria2 and TUIC: Both use QUIC-based transport designs and depend on UDP network access. If UDP is restricted on your network, you may need to use another available connection method.

These are general descriptions of commonly used protocols, not a claim that VPNCG offers them all. Available configurations depend on what’s provided in your account and what your client supports. If importing a configuration produces an “unsupported type” message, first check the client core and subscription format rather than assuming the node is unavailable.

How do Global, Rule-Based, and Direct modes differ?

Rule-based mode routes requests to a proxy, a direct connection, or another action based on conditions such as domain, destination address, or app. Supported conditions vary by client, and rules are often applied in order—so a broad rule near the top can override more specific rules below it.

Global mode typically sends requests the client already handles through the selected proxy policy. The important distinction is “already handles”: apps that ignore the system proxy, excluded apps, and traffic that doesn’t enter the virtual network interface may not be controlled by this mode. Global mode doesn’t necessarily proxy all traffic from the device.

Direct mode typically lets requests the client handles reach their destination without a remote proxy. It’s not the same as a “direct route”: the former is a routing action, while the latter describes the path from your device to the service entry point. Interpret “Direct” in the context of where it appears in the client.

For everyday use, start with a rule configuration that suits your needs. If a site has problems, switch to Global mode temporarily for comparison. If it works globally but not in Rule-Based mode, check which rules match and how the domain resolves. If both modes fail, investigate the node, network, and destination service. This comparison can narrow down the cause, but it can’t prove it on its own.

How are DNS leaks and exit IP addresses related?

DNS translates domain names into addresses. Routing web requests through a proxy doesn’t guarantee that DNS queries follow the same route. Queries can come from the operating system, browser, client, or app, and each may use a different resolver and transport path.

A DNS leak generally means a DNS query that was expected to use a tunnel or proxy path instead reached a resolver through another route. This may expose queried domains or produce unexpected routing results. But a difference between the resolver’s region and the exit region shown by a test site doesn’t prove a leak by itself; check the configuration and query path too.

Encrypted DNS protects DNS queries in transit; it doesn’t automatically send them through the proxy. Encrypted DNS enabled in a browser may also bypass the resolution path expected by the client. When troubleshooting, check browser settings, the client’s DNS policy, and system settings together—not just the exit IP shown on a website.

A proxy connection and a website’s HTTPS protect different parts of a connection. When accessing sensitive accounts, check the domain and any certificate warnings. A changed exit IP doesn’t stop a site from recognizing an account you’re signed into, and it doesn’t mean all app traffic is going through the proxy.

Why can connection results vary across platforms?

Windows and macOS clients often provide a system proxy, and some also offer TUN mode. TUN routes network traffic through a virtual interface, usually requires additional permissions, and can affect routing and DNS. It can cover more traffic, but exclusions, protocol support, and routing behavior depend on the implementation.

Android clients often route traffic through the system VPN interface and may offer per-app routing. iOS and iPadOS clients typically run through system network extensions. Similar toggle names don’t guarantee identical routing features across platforms. Background restrictions, network changes, and other networking tools can also affect connections.

On Linux, you might use a graphical client or run a command-line core. Starting the core alone may not configure the desktop proxy or system routes. When troubleshooting across platforms, check how traffic reaches the client rather than comparing node names. See the setup guides for client downloads and configuration.

How do you import a subscription and troubleshoot a connection?

Check the configuration source. Sign in to your account and get the subscription for your client from the official delivery page. Check the plan status, subscription format, and client compatibility separately.
Import it and check the result. Confirm that the client read the configuration successfully and that selectable nodes appear. Don’t mistake “link saved” for “configuration downloaded successfully.”
Choose a node and mode. Start with a node and routing configuration suited to your needs, then enable the system proxy or the traffic-routing method for your platform. Avoid running multiple networking tools that change routes at the same time.
Test with the apps you actually use. Check both a web page and the target app. If needed, review the connection logs for matched rules, DNS failures, or handshake errors. Remove credentials and subscription links before sharing logs.
Narrow it down based on what you see. No nodes? Check the subscription. Nodes appear but the handshake fails? Check the network and protocol. Web pages work but an app doesn’t? Check how its traffic is routed. Only certain sites fail? Check the rules and destination service.

The “latency” shown by a client usually comes from a specific probe target and method; it can’t be converted directly into download speed or video-call quality. A successful probe only means that test passed. Sustained throughput, packet loss, jitter, and the destination service can all lead to a different experience.

✅ Updating a subscription syncs configuration; check your account entitlements to see whether your plan needs changing.
✅ After switching nodes, compare results in the same app under similar network conditions. Avoid changing several settings at once.
❌ Don’t assume a node suits every use just because its name includes a region, dedicated-line, or protocol label.
❌ Don’t share subscription credentials or make disabling certificate validation your default troubleshooting step.

A simple troubleshooting order: First check that the subscription imported correctly, then see whether a node can connect. Next, confirm that app traffic reaches the client, and finally check routing rules and DNS. Checking one part at a time makes issues easier to pinpoint than changing every setting repeatedly.

When choosing a service, check route details, billing terms, and support options separately. Terminology describes how something works; it isn’t proof. For further connection help, start with the Help Center, then submit sanitized error details and reproduction steps through account support.