When you first start using a network proxy client, the hardest part is usually not installation but the many terms in its interface: subscriptions, nodes, routes, protocols, system proxy, TUN, split tunneling, global mode, and rule mode. Each describes a different layer—configuration source, connection endpoint, transport method, or traffic-handling strategy—and they are not interchangeable. Once these layers are clear, choosing a node, importing a subscription, and troubleshooting connections become much easier.
Key terms at a glance: what each one controls
Use the table below as a translator for the client interface. When you encounter an unfamiliar switch, first identify whether it belongs to the configuration, endpoint, transport, routing, or system-capture layer before changing it.
| Term | What it actually means | Common misconception | What beginners should check |
|---|---|---|---|
| Subscription | A set of nodes and parameters maintained by the service; the client retrieves and updates it through a subscription link | Treating a subscription as one fixed node | Whether the update succeeded and whether the source is trustworthy |
| Node | A connection endpoint the client can select, usually containing a server address, port, protocol, and authentication details | Assuming the node name is the complete network path | Location, protocol, route description, and current connection status |
| Route | The network path and delivery method between the local network and the exit point | Treating the route and protocol as the same concept | Whether direct, relay, or IEPL connectivity suits the current network |
| Protocol | The encapsulation, authentication, and transport rules used when the client and server exchange data | Judging speed from the protocol name alone | Client compatibility, transport layer, and local network restrictions |
| Split tunneling | Using domains, IPs, apps, or rule sets to decide whether a request uses the proxy or connects directly | Assuming split tunneling automatically recognizes every use case | Whether the rule matched and whether DNS follows the same policy |
| Global mode | Traffic within the client’s capture scope is sent to the selected node by default | Assuming global mode captures every connection on the device | The capture scope still differs between system proxy and TUN |
| Rule mode | Choosing the exit for each request according to defined rules | Assuming more rules always mean greater accuracy | Rule order, match results, and the final fallback policy |
| Direct connection | The request bypasses the selected proxy node and reaches its destination through the current local network | Interpreting direct connection as a direct server route | Distinguishing client behavior from server-side route labels |
“Direct connection” in the table can be especially ambiguous. In client rules, it means that a request bypasses the proxy. In node details, a direct route usually means the local network connects straight to an overseas server without an access relay deployed by the service. To determine the meaning, check which interface and configuration layer contains the term.
Why subscriptions, nodes, and routes are different
A subscription is a configuration source, not a continuous data channel
A subscription link usually returns a set of configurations that the client can parse. It may contain multiple nodes, groups, rules, and update information. After reading the subscription, the client stores the parsed results locally; everyday traffic normally does not pass through the “subscription link” but connects directly to the selected node.
A failed subscription update and a failed node connection are therefore different problems. The former may involve an expired link, an inability to retrieve the configuration, or an unsupported format; the latter is more likely related to node status, protocol compatibility, system time, the local UDP environment, or the routing path. Do not delete a local configuration that still works just because the subscription temporarily cannot refresh.
A node is a configuration object; a route is an underlying path
A node usually records the server address, connection port, protocol type, authentication parameters, transport layer, and encryption-related settings. Once selected, the client establishes a connection using those parameters. Location, purpose, or route labels in a node name are only identifiers; the actual fields determine how the client connects.
A route describes a lower-level path. A direct route goes from the local carrier network straight to the remote endpoint, keeping the structure simple but making performance more dependent on public-network routing. A relay route first connects to a nearby access point, then uses the service’s network to reach the remote exit, which is often useful for avoiding unstable public-network segments. IEPL is a common term for an international Ethernet private line; it describes the delivery path and network-isolation model, not a proxy protocol.
Follow this order when importing a subscription
- Copy the complete subscription link from the service panel, and avoid manually removing or changing its authentication parameters.
- In the client, choose “Import from URL,” “Add subscription,” or a similarly named option instead of pasting the link into a single-node address field.
- Run the update and confirm that the node list appears. Then choose an exit location close to the region where the target service is hosted.
- Open the client log or connection details and confirm that the handshake completes. Then use a browser to check the exit address and DNS resolution results.
- When you need to sync node changes later, use “Update subscription” rather than repeatedly creating identical subscription entries.
- ✅ The subscription name, node list, and update time all display normally
- ✅ The node protocol is supported by the current client, with no unknown fields
- ✅ The exit address changes as expected after connecting, and the target site loads normally
- ❌ Publicly paste the subscription link into forums, screenshots, or online conversion pages
- ❌ Re-import the same link repeatedly after an update fails, leaving duplicate configurations
How to interpret protocol names
A protocol defines how the client and server authenticate, encapsulate, and transmit data, but the protocol name itself is not a speed ranking. The same protocol can perform very differently depending on the route, local carrier, and client implementation. Beginners should prioritize configurations provided by the service and fully supported by the client rather than replacing fields manually based only on the name.
Shadowsocks
Shadowsocks is a lightweight encrypted proxy protocol. Common implementations use a pre-shared key and a specified encryption method to protect data between the client and server. Its configuration is relatively straightforward, and it is supported by many clients. Keep in mind that Shadowsocks handles proxy transport; it is not the same as a traditional VPN that captures the entire system network. Whether all apps are covered still depends on whether the client uses a system proxy, VPN interface, or TUN mode.
VMess and VLESS
VMess is an earlier authentication and transport protocol in the V2Ray ecosystem and can work with different transport layers. VLESS uses a more streamlined design for authentication and data transport; it does not provide complete transport encryption on its own and is typically paired with TLS, REALITY, or another secure transport method. For a VLESS node, do not enter only the server address and identity information—keep the transport type, server name, public key, path, and other fields consistent with the server configuration.
Trojan
Trojan typically runs over TLS and authenticates with a password, making its connection resemble ordinary TLS traffic. The client must validate the certificate and server name correctly. If the device time is significantly wrong, DNS resolution is abnormal, or the server name does not match, the TLS handshake may fail. Disabling certificate verification should not be treated as a routine fix because it weakens connection validation.
Hysteria2 and TUIC
Hysteria2 and TUIC are both built on QUIC and UDP transport, with a focus on efficiency under high latency, packet loss, or changing bandwidth conditions. They may perform better on networks where UDP works normally, but corporate, campus, public, or some routed networks may restrict UDP. If connections time out or handshakes repeatedly fail, compare with an available node based on TCP and TLS to determine whether the problem comes from protocol configuration or local network policy.
| Protocol | Primary transport characteristics | Configuration points to check | Common troubleshooting directions |
|---|---|---|---|
| Shadowsocks | Lightweight encrypted proxy | Encryption method, password, and plugin parameters | Whether the client supports the specified encryption method |
| VMess | Authentication protocol that can be combined with multiple transport layers | Identity, transport type, path, and server name | Whether all parameters are present and the system time is correct |
| VLESS | Streamlined authentication, usually paired with a secure transport layer | TLS or REALITY-related fields | Server name, public key, and transport parameters |
| Trojan | TLS-based authentication and transport | Password, certificate domain, and server name | Certificate verification, DNS, and device time |
| Hysteria2 | Based on QUIC and UDP | Authentication, TLS, and bandwidth-related settings | Whether the local network restricts UDP |
| TUIC | Based on QUIC and UDP | Identity, password, TLS, and congestion control | UDP reachability and client-version compatibility |
How to choose between split tunneling, global mode, and rule mode
The client’s real question is not “whether to turn on the proxy” but “which traffic should use which exit.” Both global and rule modes assume that the client has already connected to a node successfully. They change traffic decisions; they do not fix a failed node handshake or subscription parsing error.
Global mode is useful for temporary diagnosis
Global mode generally sends requests within the client’s capture scope through the current node. Its straightforward logic makes it useful for checking whether a site works without complex rules and for diagnosing false rule matches. The downside is that local sites, downloads, updates, and apps that do not need an international exit may also use the remote route, adding detours and consuming traffic.
“Global” does not necessarily mean every piece of data on the device. If the client only sets an HTTP system proxy, apps that do not read system proxy settings may still connect directly. If TUN or a system VPN interface is enabled, the capture scope is usually broader, but it can still be affected by excluded routes, local-network traffic, and the app’s own networking implementation.
Rule mode is better for everyday use
Rule mode checks domains, IP addresses, app processes, or rule sets in sequence and sends requests to a proxy, direct connection, block action, or specific node group. Rules generally have an order: after a request matches an earlier rule, later rules may no longer process it. When adding a broad rule, check whether it now overrides more specific entries.
Domain rules and IP rules solve different problems. Domain rules need the domain information to remain visible during evaluation, while IP rules depend on the resolution result. If DNS is handled outside the client, or an app uses its own encrypted DNS, the client may see only the destination IP, so the expected domain rule may not match.
Direct mode helps restore a local-network baseline
Direct mode sends requests around the proxy node and is useful for confirming whether the client configuration is causing a problem. If local services remain unreachable in direct mode, focus on local DNS, the router, the system firewall, or the carrier network. If direct mode works but rule mode does not, checking rule matches, node connectivity, and DNS handling is more effective.
- ✅ Use a well-maintained rule mode for everyday browsing to reduce unnecessary detours through remote routes
- ✅ When a destination is unreachable, briefly switch to global mode for comparison
- ✅ When a local service behaves unexpectedly, switch back to direct mode to verify the basic network
- ❌ Treat global mode as a switch for increasing node bandwidth or fixing a failed handshake
- ❌ Repeatedly change multiple rules without checking the match logs
System proxy, TUN, and DNS leaks
A system proxy only covers apps that choose to read proxy settings
A system proxy writes HTTP, HTTPS, or SOCKS proxy addresses into the operating system. Browsers and many desktop apps read these settings, but some games, command-line programs, apps with their own network stack, and software that sends UDP requests directly may ignore the system proxy. When the client shows “Connected,” that does not mean traffic from those apps has entered the node.
TUN mode captures traffic through a virtual network interface
TUN mode creates a virtual network interface and uses system routes to send more IP traffic to the client. It covers more than a simple system proxy and suits apps that do not support proxy settings. In return, it requires system network permissions and may conflict with other VPN software, virtual-machine networks, container networks, or security software.
If enabling TUN makes local devices unreachable, breaks local-network services, or disconnects a specific app, first check whether LAN bypass, direct access for private addresses, and the correct default route are enabled. Do not run multiple clients that create virtual interfaces and modify the default route at the same time.
A DNS leak means resolution uses the wrong exit
A DNS leak usually means that business traffic is already passing through the proxy while domain resolution is still handled directly by the local network’s DNS server. This makes the resolution location inconsistent with the exit location and may expose queried domains to the local network. It does not always cause a complete loss of connectivity; more common signs include content for the wrong region, rules that fail to match, or some domains resolving to unsuitable addresses.
During troubleshooting, check whether the client captures DNS, which resolution strategy rule mode uses, whether the browser has independent Secure DNS enabled, and whether the system retains DNS settings on other network interfaces. After connecting, open this site’s Network Check page and compare the exit address with the DNS resolution location. If they differ significantly, return to the client and adjust DNS capture.
Why clients differ across platforms
The same subscription may display different options on different platforms. This usually reflects differences in operating-system network interfaces, background restrictions, and client-core capabilities rather than a change in the subscription itself. When moving to another device, review modes and permissions again instead of assuming every switch will remain identical after import.
Windows
Windows clients often provide both a system proxy and TUN. A system proxy suits browsers and standard desktop apps, while TUN is better for command-line tools, games, or software that does not read proxy settings. If the network becomes unavailable, check for leftover proxy settings, whether the virtual adapter loaded correctly, and whether the firewall allows the client to communicate.
macOS
macOS clients may work through a system proxy, network extension, or system VPN interface. The first time you enable one of these modes, macOS will request approval for network access. If the client is connected but an app is not using the node, check whether the network extension is enabled and whether another network filter is also present in System Settings. Restoring the system proxy before quitting the client also prevents later apps from pointing to a closed local port.
Android
Android usually uses the system VPN interface to capture traffic and can decide on an app-by-app basis whether traffic enters the tunnel. Battery-saving policies may limit the client’s ability to maintain a background connection, and switching networks may require a new session. If only one app behaves abnormally, check per-app routing first instead of replacing the entire subscription.
iOS and iPadOS
iOS and iPadOS clients rely on the VPN and network-extension capabilities provided by the system, with background behavior managed centrally by the operating system. After importing a subscription, the system will still ask to create a VPN configuration. If switching nodes does not take effect immediately, disconnect and reconnect first, then verify that the active configuration belongs to the client you are using.
| Platform | Common traffic-capture methods | Key checks |
|---|---|---|
| Windows | System proxy, TUN | Leftover proxy settings, virtual adapter, firewall |
| macOS | System proxy, network extension | Network permission, filter conflicts, system proxy status |
| Android | System VPN interface, per-app routing | Background restrictions, app bypass, network changes |
| iOS and iPadOS | System VPN, network extension | Configuration approval, active configuration, reconnection status |
Troubleshooting order: from connection failures to rule problems
A common beginner mistake is changing the node, protocol, DNS, TUN, and rules all at once, then being unable to tell which setting helped. A more reliable approach is to follow the data flow layer by layer, starting with the subscription input and ending at the target app’s exit.
- Confirm that the subscription updates successfully and that the node configuration is not missing protocol or authentication fields.
- Fix one node and check the client log to verify that the connection and handshake complete.
- Test basic access in a mode with few rules to eliminate the effects of complex split tunneling.
- Check whether the target app reads the system proxy. If it does not, test TUN or the system VPN interface.
- Compare the exit address with the DNS resolution location to determine whether resolution follows the expected path.
- Restore everyday rule mode and use the match logs to confirm that the target domain or IP uses the correct policy.
- Only then compare different nodes and routes, so local permission problems are not mistaken for route problems.
When a client shows “Connected,” it only means that one connection process has been established. It does not confirm that subscription updates, app capture, DNS resolution, rule matching, and access to the destination service are all working. Verify each stage separately during troubleshooting.
Once these terms are clear, the client interface becomes a straightforward chain: the subscription provides configuration, the node supplies the endpoint, the protocol handles communication, the route carries data, the system proxy or TUN captures app traffic, split-tunneling rules choose the exit, and DNS supplies addresses for domain resolution. Any fault can be traced to one of these layers instead of being chased by toggling every switch at random.