The key challenge for VPN beginners is not memorizing abbreviations, but understanding where each client option fits. A subscription delivers configuration, a node is a connection endpoint, a protocol defines data transport, a route type describes the network path, and split-tunneling rules decide which requests use the proxy. Once these layers are separated, choosing a route, importing a profile, and troubleshooting become much clearer.
Common Terms at a Glance
The table below starts with concise definitions. When a connection fails, check in this order: whether the subscription updated, whether the node is available, whether the protocol is compatible, whether a rule matched, and whether DNS is consistent. Avoid flipping every switch at once.
| Term | What it actually means | Common misconception | What to watch |
|---|---|---|---|
| Subscription link | A configuration URL the client uses to retrieve nodes, protocol settings, and some rules | Treating the subscription link as an already connected route | Import location, update status, and keeping the link private |
| Node | The remote server endpoint the client actually connects to | Assuming nodes in the same region must perform the same way | Route path, changing load, and the target service's region |
| Protocol | The rules used for transport, authentication, and encryption between the client and node | Equating a protocol name directly with a speed tier | Client compatibility, network conditions, and transport method |
| Direct route | A direct public-internet connection from the local network to the remote node | Interpreting “direct” as meaning no proxy is involved | Cross-network routing, evening fluctuations, and endpoint reachability |
| Relay route | Connecting to a nearby entry point first, then using a relay network to reach the exit | Assuming that extra relay hops always make a connection slower | Entry-point quality, relay path, and exit stability |
| IEPL | An international Ethernet private-line service type commonly used for cross-border enterprise communications | Assuming the route name itself replaces transport encryption | The provider's implementation, entry access, and protocol configuration |
| Split tunneling | Routing traffic by domain, address, application, or rule set | Assuming rule mode will automatically identify every application correctly | Rule priority, unmatched-traffic policy, and DNS handling |
| Global mode | Sending traffic managed by the client through the proxy by default | Assuming it always covers every network request on the device | System proxy, TUN coverage, and application exceptions |
How to Import and Update a Subscription Link
A subscription link is usually a configuration endpoint provided as a web address. After accessing it, the client reads node names, server addresses, ports, authentication details, protocol parameters, and other provider-supplied settings. Different clients may parse the same subscription differently, so being able to open a link in a browser does not mean it can be imported correctly by the client.
A subscription URL often contains credentials that can access your personal configuration, so protect it like a password. Do not place it in public documents, public code repositories, or screenshots. When changing devices, copy it again from the service dashboard rather than forwarding it from an unknown source. If the dashboard supports subscription reset, update the link promptly after accidental exposure.
- Copy the subscription link suited to your current client from the service dashboard, making sure it contains no extra spaces or line breaks.
- Open the client's subscription, profile, or remote-configuration page and choose import from URL rather than pasting it into a single-node editor.
- Run a subscription update, wait for the node list to finish loading, then check that node names and protocol types are displayed correctly.
- Choose a node that matches your use case, enable the system proxy or TUN, and run an access test.
- Use “Update subscription” when node details change. Do not repeatedly create the same subscription, or duplicate entries can accumulate.
What to Check When the Node List Is Empty
If an update reports success but the list is empty, the client may be unable to parse the returned format, or a filter may be hiding every node. If the update reports a network error, distinguish between an unreachable subscription URL, failed certificate validation, and local network interception. Do not disable certificate validation without understanding it; validation confirms that you are connecting to the expected server.
How Are Subscriptions Different from Single-Node Configurations?
A single-node configuration describes one connection endpoint and is useful for temporary imports or testing a specific route. A subscription makes it easier to update multiple nodes centrally and may include groups and rules. Manual changes to subscription-generated nodes may be overwritten during the next update. Long-term custom rules should go in the client's supported override, script, or local-rule area rather than editing remote content directly.
Nodes, Entry Points, and Exits Are Different Concepts
Node names in a client often include a region, route type, or usage hint, but a name is only a label. What really affects performance is the path from your network to the entry point, the transport method from the entry point to the exit, and the network quality between the exit and the target service. A node labeled for a region usually means the target service sees an exit address from that region; it does not mean the entire path is located there.
The entry point is where the client connects first, while the exit is the source location visible to the target website. For a direct node, the entry and exit may be on the same server or may be forwarded internally by the provider. A relay route usually connects to a nearby entry point first and then reaches an exit in another region. The client interface may not show all of this internal structure, so do not infer the full topology from a node name alone.
- ✅ For ordinary web browsing, start with an entry point close to your current network and a stable route.
- ✅ For services with regional requirements, confirm that the exit region matches the region normally associated with your account.
- ✅ If long-lived connections drop frequently, compare route types instead of only switching between nodes in the same region.
- ✅ Reconnect the application after changing nodes so an existing connection does not keep using the previous exit.
- ❌ Do not treat “high-speed” or “private line” in a node name as a measured result for your current network.
Does Lower Latency Always Mean More Speed?
Latency measures the time for a round trip, but webpage loading, file transfers, and streaming also depend on bandwidth, congestion, packet loss, server response time, and connection reuse. A client's latency test may check only the entry point, not how the exit reaches the target service. Test nodes with your actual use case: check first-paint response for webpages, audio continuity for meetings, and repeated reconnects for long-lived developer-tool connections.
Why Didn't the Region Change After Switching Nodes?
The app may have kept an old connection, the browser may be using separate proxy settings, or split-tunneling rules may have sent the lookup directly. Fully close the relevant app, then confirm the client's current node, proxy mode, and IP lookup result. If only one app is affected, check whether it bypasses the system proxy or has its own secure DNS and proxy extension enabled.
How to Understand Shadowsocks, VMess, Trojan, and Other Protocols
A protocol defines how the client negotiates identity with the server, encapsulates data, and transports it. A protocol name does not indicate route quality: the same network path can behave differently with different protocols, and the same protocol can vary significantly across paths. Check what the server provides first, then confirm that the client fully supports the relevant transport parameters.
Shadowsocks
Shadowsocks is an encrypted proxy protocol. Its configuration usually includes a server, port, password, and encryption method. Its structure is relatively straightforward and it is widely supported, but encryption suites vary between implementations. If the imported profile reports an unsupported method, update the client core or use the provider's recommended client rather than changing the method at random; the server parameters must match.
VMess and VLESS
VMess is common in the V2Ray ecosystem. Beyond the server and authentication details, its configuration may include transport-layer settings, a path, hostname, and TLS parameters. VLESS uses a lighter authentication design and does not encrypt content by itself; deployments commonly pair it with TLS or another secure transport. The two may look similar, but they are not interchangeable. Any mismatch in transport fields can cause the handshake to fail.
Trojan
Trojan typically runs over TLS, so the certificate domain, server name indication, and server configuration must match. When a certificate error appears, first check the device clock, domain, and subscription parameters rather than disabling verification. Reaching a server does not mean its TLS identity verification succeeded.
Hysteria2 and TUIC
Hysteria2 and TUIC both rely heavily on QUIC and UDP transport, and may behave differently from traditional TCP options on networks with packet loss or fluctuating bandwidth. Some office networks, public networks, and routers restrict UDP, which can result in failed handshakes, rapid disconnects, or a more severe performance drop than with TCP. In that situation, compare with an available TCP-based protocol instead of immediately blaming the node's region.
How IEPL, Relay, and Direct Routes Differ
A route type describes the network path from your local network to the remote exit. A direct route usually has the client access the remote server over the public internet; the path is simple, but cross-network and cross-region routing can vary by time of day. A relay connects to an entry point first, after which the provider handles the remaining path. This can provide an entry point better suited to local access and allow adjustments to the international segment.
IEPL is an international Ethernet private-line service type commonly used for cross-border connections between enterprise networks. When IEPL appears in a node name, it generally indicates that part of the transport path uses related private-line resources, though the actual coverage depends on the provider's implementation. IEPL describes the route; it does not replace protocol encryption, and its label alone cannot reveal the local access segment, exit segment, or target website status.
| Route type | Connection method | Useful scenarios to observe | Common limitations |
|---|---|---|---|
| Direct | Directly from the local public network to the remote node | Ordinary browsing, nearby routes, and good direct reachability on the local network | More noticeable fluctuations during cross-network detours or congestion |
| Relay | From the local network to an entry point first, then onward to the exit | Long-lived connections, cross-network access, and scenarios requiring a stable entry point | An issue at the entry point or relay segment affects the entire path |
| IEPL | Part of the path uses international Ethernet private-line resources | Enterprise collaboration, meetings, developer connections, and other continuity-focused use cases | Actual coverage depends on the service configuration |
Do not judge a route from a single speed test. A short download can hide connection jitter, while a sustained session reveals it more easily. Observe first page loads, repeated requests, file transfers, and real-time calls separately. If only a particular target service is affected, consider its own routing or regional restrictions before declaring the entire route unavailable.
Split Tunneling, Rule Mode, and Global Mode
Split tunneling determines which traffic goes through the proxy. Rules can match domains, address ranges, application processes, or other conditions. Requests matching proxy rules go to the node, those matching direct rules connect directly, and unmatched requests follow the final rule. Rule order matters: clients generally match from top to bottom, so a broad rule placed too early can hide a later, more precise rule.
Rule mode
Rule mode suits everyday use. Common local services can connect directly, while requests that need international routes use the proxy. This reduces unnecessary detours and makes it easier to maintain the exit required by each service. Its results depend on an up-to-date rule set and DNS lookups that align with rule evaluation. If a domain is resolved incorrectly, even a correctly written rule may fail to match the intended policy.
Global mode
Global mode generally means that traffic managed by the client uses the proxy by default, making it useful for isolating rule problems. If rule mode fails but global mode works, the node and protocol are probably usable; the issue is more likely in domain rules, address rules, or DNS. Remember that system proxy mode affects only apps that honor system proxy settings; programs that ignore them may still connect directly.
Direct mode
Direct mode bypasses the proxy and can help confirm whether the local network itself is working. If both direct and proxied connections fail, check the device network, DNS resolution, and target service status first. If direct access works but the proxy does not, check the node, protocol, and route. Keeping direct mode as a baseline is more useful than repeatedly reinstalling the client.
- ✅ For everyday use, start with rule mode and confirm that common services take the expected routes.
- ✅ When a website behaves oddly, use global mode as a comparison to determine whether the issue is rule-related.
- ✅ If an app is completely unaffected, check whether it supports the system proxy, then test TUN if needed.
- ✅ Reopen the app after changing modes so existing connections do not continue using the old route.
- ❌ Do not enable multiple clients to control the system proxy at the same time; their settings can overwrite one another.
Why DNS Leaks and Domain Resolution Affect Split Tunneling
DNS converts domain names into network addresses. A DNS leak usually means that a domain lookup that should be handled through the proxy environment is sent to the local network's resolver instead. This can expose the lookup intent or return a result that does not match the proxy exit, causing incorrect regional detection, rule mismatches, or failed access.
Routing webpage traffic through a node does not by itself mean DNS follows the same path. Browser secure DNS, the operating system resolver, the client's built-in DNS, and router settings may all be involved. Troubleshooting requires identifying who performs the lookup, which path carries it, and whether the result is used by the split-tunneling engine. Clients may call these settings remote DNS, proxy DNS, Fake IP, or enhanced mode; check the client's documentation for exact behavior.
Fake IP mode first assigns a virtual address for local mapping, then the client uses the original domain to apply rules and forward the connection. This preserves domain information, but some local-network services, games, and special applications may be incompatible and need exceptions. Real-address mode returns the resolved address directly and more closely resembles traditional networking, but the resolution path and cache consistency still matter.
Understanding Cross-Platform Client Differences
Different client names do not necessarily mean completely different underlying capabilities, and the same name does not guarantee identical features across platforms. Windows and macOS commonly offer system proxy and TUN capture, but virtual-network-adapter permissions, system extensions, and sleep-wake behavior differ. Android usually captures traffic through the system VPN interface and can route traffic by app. iOS likewise relies on system network extensions, with background behavior and available cores limited by the platform.
Desktop platforms are better suited to inspecting detailed logs, routing tables, and connection statistics, while mobile platforms place more emphasis on battery life and network switching. When a device switches from Wi-Fi to a mobile network, existing connections may fail and the client may need to complete a new handshake. If a mobile app shows “connected” but cannot access services, disconnect and reconnect first, then check per-app proxy settings and local network permissions.
Command-line tools also require separate attention to environment variables. Git, package managers, and developer tools in a terminal may not automatically use the desktop client's settings. Some tools use the system proxy, some read HTTP_PROXY or HTTPS_PROXY, and others require a SOCKS address. Environment variables apply only to the process that launches them and its child processes, so you usually need to reopen the terminal after changing them.
What to Check When Choosing a Client
- ✅ Support the protocols and transport parameters actually provided in the subscription.
- ✅ Update remote subscriptions and clearly distinguish remote configuration from local overrides.
- ✅ Provide rule-match, connection-error, or basic logs for troubleshooting.
- ✅ Use a capture method suited to the scenario; use TUN when independent apps need coverage.
- ✅ Let DNS settings work together with the split-tunneling engine.
- ❌ Do not download modified clients from unknown pages or import unfamiliar configurations.
Troubleshooting Steps from No Connection to Recovery
Effective troubleshooting means changing one variable at a time. If you switch the node, protocol, mode, and DNS together, even a recovery will not reveal the real cause. Confirm the local network first, then the subscription and node, followed by the protocol handshake, and finally split tunneling and app-specific behavior.
- Disable the proxy and visit an ordinary website to confirm that the current network itself can connect normally.
- Update the subscription and review the error message to confirm that the node is not an outdated or duplicate configuration.
- Choose a node the client explicitly supports, then test the browser with the system proxy first.
- If the browser works but other apps do not, check their proxy support before deciding whether to use TUN.
- If rule mode fails, temporarily switch to global mode for comparison. If global mode works, review the rules and DNS.
- If no mode can connect, inspect the logs for DNS, connection, TLS, or UDP errors and address the corresponding layer.
- After recovery, undo temporary test changes and keep only the necessary settings so the configuration remains maintainable.
A “timeout” in the logs means a step did not finish within the waiting period, but the cause could be failed DNS resolution, an unreachable server address, a restricted port, or a handshake with no response. “Connection refused” usually means the target address was reached but the service did not accept the connection. For a “certificate mismatch,” check the domain, device clock, and TLS parameters; do not treat it as ordinary network fluctuation.