When you first use a network acceleration tool, terms such as VPN subscriptions, nodes, protocols, traffic routing, and global mode often appear together in the client. They describe different layers of the setup: a subscription delivers configuration, a node is a selectable connection endpoint, a protocol defines how the client communicates with the server, a route describes the network path, and the routing mode determines which requests are handled by the proxy. Once these layers are separated, most client settings become much easier to understand.
In everyday conversation, “VPN” is often used as a general term for network acceleration services, but the technology used by a client is not necessarily a traditional VPN protocol. Some tools use the system VPN interface to create a virtual network adapter, then pass traffic to protocols such as Shadowsocks, VMess, Trojan, VLESS, Hysteria2, or TUIC. So when the system status bar shows a VPN indicator, it only means that the client has enabled the system traffic-capture interface; it does not identify the underlying protocol.
What are subscriptions, subscription links, and configuration files?
A subscription is a configuration list maintained by the service. It typically contains node names, server addresses, ports, protocol parameters, authentication details, and other fields recognized by the client. After importing a subscription into a compatible client, the client parses the list and creates a node list, so there is no need to enter every field manually.
A subscription link is the address used to retrieve that list. It is not an ordinary promotional page, but a configuration endpoint containing account-identifying information. Anyone who obtains the link may be able to read the node configuration, so do not post it in public groups, screenshots, or public documents. If you suspect that the link has been exposed, reset the subscription in the service panel instead of merely deleting the nodes from the local client.
A configuration file is a static local copy of the subscription content. Common formats include plain-text and structured configuration files. Importing a file is useful for offline migration, but it will not receive later changes from the service automatically; a subscription link can be refreshed by the client. After nodes are added, endpoints change, or rules are updated, refreshing the subscription is usually more effective than reinstalling the client.
What the client actually does when importing a subscription
- The client requests the subscription address and downloads the configuration.
- It parses the protocol, server endpoint, authentication fields, and node name.
- It organizes multiple nodes into selectable proxy groups or lists.
- It uses local rules to decide the default node, update method, and traffic-handling mode.
- When connecting, it creates a local proxy port or virtual network adapter and sends matching requests through the selected node.
A successful import does not mean the connection is already active. It only proves that the client read the configuration. You still need to select an available node, enable the system proxy or virtual network adapter, and confirm the traffic path through real-world access tests and DNS checks. If the client reports a successful subscription update but pages still use the original network, check the mode, proxy-group selection, and system permissions rather than repeatedly importing the same link.
Nodes, servers, and routes are not the same thing
A node is a selectable connection configuration in the client. It may point directly to a server, or represent an endpoint, load-balancing address, or combination of routes. Countries and cities in node names usually describe the exit location or route purpose, and do not necessarily reveal the server’s exact deployment details.
A server is the computing resource that handles the connection, authentication, forwarding, or protocol termination. Most users do not need to know the server’s internal structure; focus instead on whether the node fits the target region, current network, and intended application.
A route emphasizes the network path from your device to the entry point and then to the exit. Two nodes with the same exit region can perform differently if their entry locations, carrier interconnections, or transit methods differ. Conversely, one route may be offered under multiple node names for different protocols or purposes.
| Route type | Connection path | Main characteristics | What to consider |
|---|---|---|---|
| Direct | The client connects directly to an international endpoint | A simple path whose performance depends heavily on the local network and international interconnections | Check whether the current access network can reach the endpoint reliably |
| Relay | Connects to a nearby endpoint first, then forwards traffic to the exit | Can reshape the cross-network path, but adds another forwarding layer | Consider endpoint quality, the forwarding path, and the exit purpose |
| IEPL dedicated line | Carries a designated segment over an international Ethernet private line | Its path-management approach differs from ordinary direct public-internet access | Confirm the actual access scope covered by the provider’s label |
Direct access is not inherently faster than a relay, and a relay is not automatically better than a direct route. The right path depends on the local carrier, access region, exit direction, and current network conditions. A relay reshapes part of the path; it does not magically remove every source of congestion. IEPL is the industry term for an international Ethernet private-line service, but an “IEPL” label in a client still needs to be read alongside the service description, since the private line may carry only a specific segment of the overall path.
When choosing a node, beginners should not focus only on the latency shown by the client. Latency usually comes from a single probe: it may indicate endpoint reachability, but cannot fully represent page loading, sustained transfers, or a specific app’s performance. A more reliable approach is to filter by the target region first, then compare connection setup, page response, and sustained transfers in the situations that matter to you.
Common protocols: Shadowsocks, VMess, Trojan, and VLESS
A protocol defines how the client and server encapsulate, authenticate, and transmit data. A protocol name does not indicate route quality: the same protocol can run over different routes, while the same route may offer multiple protocols. Consider client compatibility, the current network’s support for the transport method, and the configuration supplied by the service together.
Shadowsocks
Shadowsocks is an encrypted proxy protocol with a relatively straightforward structure and a mature client ecosystem. It uses a pre-shared key for encryption and authentication, making it suitable for situations that require broad client compatibility. Encryption methods cannot be mixed arbitrarily; the server and client must use matching parameters. After importing a subscription, do not change the encryption method manually, or the port may be reachable while authentication still fails.
VMess and VLESS
VMess uses an identity and protocol fields for client-server communication, often combined with WebSocket, TCP, or other transport methods. VLESS takes a lighter approach to authentication and does not itself provide complete transport encryption; it typically relies on TLS, REALITY, or another protected underlying channel. When you see a VLESS node, verify more than the protocol name: check the transport method, security layer, server name, and core compatibility.
VMess and VLESS have similar names, but their configuration fields are not interchangeable. Entering a VLESS node manually as VMess, or omitting TLS-related parameters, will cause the connection to fail. One benefit of importing a subscription is that it reduces mistakes when copying these related fields by hand.
Trojan
Trojan usually runs over TLS and uses a password for authentication. The client must correctly handle the server name, certificate validation, and transport parameters. When a certificate error occurs, do not treat “skip certificate verification” as a long-term fix. First check the system time, server name, subscription expiry, and whether the client core supports the configuration.
Hysteria2 and TUIC
Hysteria2 and TUIC both emphasize transport based on UDP and QUIC. In lossy or unstable environments, their congestion-control and multiplexing mechanisms can improve transmission behavior. However, they depend on the current network supporting UDP, and some public networks, corporate networks, or routing policies may restrict it. A node may appear correctly configured yet fail to complete the handshake for a long time; switching to a TCP-based compatible node is often a more useful diagnostic step.
How to choose global, rule-based, and direct modes
A client’s “mode” determines how traffic is allocated. It is independent of node selection: the node determines where proxied traffic goes, while the mode determines which traffic is sent there. Selecting an international node does not mean every request on the device will automatically pass through it.
| Mode | How it works | Best for | Common issues |
|---|---|---|---|
| Rule mode | Uses domain, address, or application rules to choose between proxying and direct access | Everyday use while keeping local services on their original path | Rules do not match, are outdated, or conflict in order |
| Global mode | Sends all requests the client can capture through the selected proxy | Temporarily checking whether rules are causing an access failure | Local services take a longer route or internal resources become unreachable |
| Direct mode | Requests do not pass through a proxy node | Pausing the proxy or comparing performance with the original network | Assuming a node is active when it is not actually being used |
Rule mode is generally better for everyday use. The client matches domains, IP addresses, geographic sets, or application processes, then sends requests according to proxy, direct, or block policies. Rules have an order: specific matches should usually come before broad fallback rules, otherwise a broad rule may capture the request too early.
Global mode is useful for diagnosis, not necessarily as a permanent setting. If a site fails in rule mode but works after switching to global mode, the issue is more likely related to rule matching, DNS resolution, or proxy-group selection than to the node itself. Global mode can also route local websites, LAN devices, and system services through a longer path, so restore rule mode when troubleshooting is complete if appropriate.
Direct mode makes traffic use the original network path. It can help compare performance before and after proxying, or temporarily disable forwarding without quitting the client. In some clients, “direct” affects only rule decisions while the virtual network adapter remains enabled. To determine whether traffic capture has fully stopped, also check the system proxy, virtual adapter, and client status.
What conditions do traffic-routing rules usually include?
- Domain suffixes: send a site and its subdomains through a specified policy.
- Fully qualified domains: match only a specific host for precise coverage.
- IP address ranges: choose proxying or direct access based on the destination address.
- Application processes: let only specified software use a particular proxy group.
- Geographic rule sets: classify traffic using maintained groups of domains or addresses.
- Fallback rules: handle requests that did not match any earlier condition.
Traffic routing does not depend only on the page URL. A page may request its main site, image domains, API domains, and content-delivery domains at the same time. If these requests use different exits, the page may open while images are missing, login loops occur, or CAPTCHA checks behave unexpectedly. During troubleshooting, inspect the client’s connection log to see which rule matched each related domain instead of adding an exception only for the main domain.
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN,local.example,DIRECT
GEOIP,LAN,DIRECT
MATCH,PROXYThis example rule means that specified domain suffixes go through the proxy, local domains and LAN addresses remain direct, and all other requests are handled by the fallback policy. Syntax, rule names, and supported features vary between clients, so do not copy one configuration unchanged into every application. Back up the original configuration before editing and use only fields supported by the client documentation.
How do system proxy, TUN mode, and virtual network adapters differ?
A system proxy registers an HTTP or SOCKS proxy address with the operating system. Browsers and apps that follow system proxy settings send requests to the client, but some software may ignore those settings, use its own network stack, or send UDP directly. As a result, some application traffic may remain outside the client’s control even when the system proxy is enabled.
TUN mode typically receives IP-layer traffic through a virtual network adapter and then forwards it according to the client’s rules. It covers more apps that do not support system proxies and is better suited to UDP, but it requires higher system privileges and may conflict with other network-filtering software, corporate security policies, or existing virtual adapters.
A virtual network adapter is simply the way traffic enters the client; it does not mean that every packet must pass through a remote node. The client can still apply direct, proxy, and blocking rules in TUN mode. When the system shows a VPN indicator, check the client’s connection log to confirm which rules matched instead of relying only on the status icon to identify the exit.
What is a DNS leak, and why can it affect traffic routing?
Before accessing a domain, a device usually uses DNS to resolve it to an address. If web traffic passes through a proxy while DNS queries still go to the resolver on the original network, a DNS leak may occur. This can expose the domains being queried and may return results unsuitable for the current exit, causing detours, unreachable addresses, or incorrect rule decisions.
Rule mode depends heavily on DNS design. Some clients resolve a domain first and then match IP rules; others preserve the domain name and match domain rules; some TUN implementations use virtual-address mapping. Do not check only whether “DNS is enabled.” Confirm who sends the DNS request, which interface it uses, and whether the result matches the proxy exit.
A practical order for checking the DNS path
- Confirm whether the client has enabled built-in DNS or remote resolution.
- Check whether other network tools have left their own DNS settings in the system.
- Test the same domain separately in rule mode and global mode.
- Clear the system and browser DNS caches, then reconnect.
- Check whether the browser has enabled encrypted DNS independently of the client’s policy.
- Review the connection log to confirm that DNS requests and destination connections matched the expected policies.
Encrypted DNS in a browser is not inherently bad, but if it bypasses the client’s traffic-routing DNS, it can produce two different sets of results. During troubleshooting, temporarily let the browser follow the system settings, confirm that the client path works, and then decide whether to restore the browser’s own resolver. The goal is a consistent, explainable exit policy for both domain resolution and the subsequent connection.
Why clients look different across platforms
Windows clients commonly offer both a system proxy and TUN mode. System proxy setup is simple, but cannot ensure that every app follows it. TUN provides broader coverage, but requires a virtual network adapter driver and administrator privileges. If the network stops working after enabling it, check the adapter, routing table, DNS settings, and other network-filtering programs for conflicts.
macOS clients often capture traffic through a system network extension or VPN configuration. The first time you enable it, macOS requires approval in System Settings. If the client opens after a system update but cannot establish a tunnel, check whether the network extension still has permission instead of reinstalling the subscription. Apple silicon and Intel devices may also require different builds, so follow the client’s release notes when downloading.
Android clients typically use the system VPN service to create a local tunnel and can determine which apps use the proxy. Battery-saving policies may limit the client’s background operation, causing the connection to drop after the screen locks. Check background activity permissions, data-saving settings, and the app-routing list during troubleshooting.
iOS and iPadOS clients are constrained by the system network-extension mechanism, and their configurations are usually stored within the individual app. After importing the same subscription, different clients may support different rule sets, scripts, and protocol cores. If a node works on desktop but cannot be imported on mobile, first verify protocol and transport support instead of assuming that the subscription has failed.
A Linux environment may use a desktop client or run a command-line core. A desktop app can capture traffic from ordinary software through the system proxy, while command-line programs may need separate environment variables or unified handling through TUN and routing rules. During troubleshooting, distinguish between “the core is running,” “the local port is listening,” and “the application is actually using the proxy.”
A complete check from import to connection
Beginners often mix several problems together: a subscription may fail to download, a node may fail its handshake, a rule may not match, or an app may not use the system proxy. They can all look like “the site won’t open.” Checking one layer at a time reduces wasted effort.
- Check the subscription: Confirm that the link came from the service panel, the client can update normally, and the node list changes as expected.
- Check compatibility: Confirm that the client core supports the node’s protocol, transport method, and security layer.
- Check the node: Start with a node whose purpose is clear, and watch the handshake or connection log instead of relying only on the latency test.
- Check traffic capture: Confirm that the system proxy or TUN is enabled and that the target app is actually managed by the client.
- Check the mode: Temporarily compare rule mode with global mode to determine whether traffic routing is causing the failure.
- Check DNS: Confirm that the resolution path matches the connection policy, clear old caches, and test again.
- Check conflicts: Pause other proxies, virtual adapters, or network-filtering tools to prevent repeated route changes.
- Keep the logs: Record the error type, protocol, connection mode, and stage at which it occurred before contacting support.
A “timeout” in an error log usually means that the connection did not complete within the allotted wait, but possible causes include an unreachable endpoint, restricted UDP, abnormal DNS resolution, or route congestion. “Authentication failed” points more toward a key, password, identity field, or subscription-status issue. A “certificate error” calls for checking the server name, system time, and TLS configuration. Different errors require different responses; repeatedly switching nodes cannot replace reading the log.
Change only one variable at a time during troubleshooting. First keep the client and mode fixed, then change the node. Next keep the node fixed and compare rule mode with global mode. If you change the protocol, node, DNS, and client simultaneously, even a successful recovery will not reveal the real cause.
What beginners can conclude after learning these terms
The subscription delivers configuration to the client, the node is a selectable connection combination, the protocol defines the communication method, the route describes the underlying path, and traffic routing determines which requests use the proxy. The system proxy and TUN determine how device traffic enters the client. DNS handles domain resolution; when its path does not match the routing policy, an apparently correct node can still produce access problems.
For everyday use, start with rule mode so local services remain direct while international access follows rules to a suitable node. When one site behaves unexpectedly, switch briefly to global mode to test whether the rules are responsible. Choose protocols based on client compatibility and the current network, and choose routes based on real-world path performance. A more complex name is not automatically a better fit; a combination that imports reliably, captures traffic correctly, routes it clearly, and is easy to troubleshoot is easier to maintain over time.