The hardest part of VPN setup for beginners is often not finding a button, but understanding how subscriptions, nodes, protocols and split tunneling fit together. A subscription delivers configuration to the client, a node represents a selectable connection endpoint, a protocol defines how data is exchanged, and split tunneling determines which connections use the proxy route. Once these layers are separated, problems such as failed imports, connected-but-unreachable websites and persistent lag after switching nodes become much easier to diagnose.
In everyday discussions, “VPN” is often used as a catch-all term for network acceleration, encrypted tunnels and proxy services. In practice, a client may use the system VPN interface, configure only the system proxy, or take over traffic through a virtual TUN adapter. Similar names do not mean they operate at the same point in the network stack. To judge whether a configuration is suitable, look at how traffic enters the client, how routes are selected and how domains are resolved—not just whether the app home screen says “Connected.”
| Term | What it does | Common misconception | What to check |
|---|---|---|---|
| Subscription | Provides node configurations to the client and syncs changes during updates | Treating a subscription link as an ordinary download URL or public share | Whether the link is complete and the client supports its format |
| Node | Represents a selectable server entry and its connection parameters | Assuming a node name is the same as the complete network path | Exit region, entry quality, route type and current load |
| Protocol | Defines how the client and server authenticate, encapsulate and transmit data | Assuming the protocol name alone determines speed | Client compatibility, transport layer and whether the network supports UDP |
| Split tunneling | Selects proxy or direct access by domain, IP, app or rule set | Assuming global mode is always more stable than rule-based mode | Rule matches, DNS resolution path and the default policy |
What a Subscription Link Actually Contains
A subscription link is usually the entry point a client uses to retrieve configuration. After accessing the URL, the client obtains one or more node names, server addresses, ports, protocols, authentication parameters and transport options, then converts them into selectable profiles. Some subscriptions use generic encoded text, some return structured formats recognized by specific clients, and others return different content depending on the requesting client.
A subscription is not a protocol. One subscription can include Shadowsocks, VMess, Trojan, VLESS, Hysteria2 or TUIC nodes, and the same protocol can be supplied by different subscriptions. A subscription is not the server currently in use either. Importing writes configuration into the client; when connecting, you still need to select a node and have the client enable the system proxy, virtual adapter or network extension provided by the operating system.
Treat a subscription link as an access credential. Anyone who obtains it can usually read the connection configuration, so do not place it in public screenshots, public documents or pages indexed by search engines. When copying, check whether a chat app truncated the final characters and whether the browser escaped special characters. If the client reports an invalid format, first verify that the URL is complete, then confirm that you are using the “Subscription” import entry rather than “Single Node.”
Why the Browser Shows Only a String of Text
Subscription URLs are mainly intended for clients, not for human-friendly web browsing. A browser showing encoded text or configuration fields—or starting a file download—does not by itself mean the link is invalid. Copy the complete URL and use a compatible client’s “Import from URL,” “Add Subscription” or similarly named option. If the service offers a QR code, make sure the scanner supports subscriptions rather than only a single-node profile.
- ✅ The subscription URL comes from the account panel or a trusted service page
- ✅ The copied content includes the complete protocol prefix and remaining characters
- ✅ The import entry is clearly labeled Subscription, Remote Configuration or URL
- ✅ Update the configuration after importing and check that a node list appears
- ❌ Do not show the complete subscription URL in public screenshots
- ❌ Do not import configuration into an online converter of unknown origin
Nodes, egress points, and routes are different concepts
A node is a connection entry in the client, usually made up of a region, server and protocol parameters. The exit is the location associated with the public IP address ultimately seen by the destination website. A route describes the network path from your local network to the entry point and then to the exit. When a node name includes a region, it usually indicates the exit location, but the name alone cannot reveal which carriers are involved, whether relay routing is used or how the path will change during evening congestion.
A direct route connects the client straight to an international server entry. It is shorter and simpler, but performance depends more heavily on the quality of the international interconnection between the local carrier and the destination network. A relay route first connects to a nearby or more stable entry, then forwards traffic to the exit through a relay network. This can avoid some poor public routes, but the extra hop makes server-side scheduling and entry quality more important.
An IEPL line generally refers to international Ethernet private-line resources arranged by the operator between an entry and an exit. It describes the transport path, not the client protocol, and it is not the same as the encryption method visible to a website. The client may still connect to the entry using Shadowsocks, Trojan or another protocol. Whether a private line suits a particular situation depends on the local path to the entry, the exit network, interconnection with the destination site and actual time of day.
| Route type | Path characteristics | Metrics worth checking first | Common limitations |
|---|---|---|---|
| Direct | The local network connects directly to an international node entry | Local carrier routing, cross-border congestion and exit interconnection | May be affected by public-route fluctuations during peak hours |
| Relay | Connects to a relay entry first, then forwards traffic to the target exit | Entry distance, forwarding path and exit region | An entry problem can affect multiple exits in the same group |
| IEPL private line | Uses organized private-line transport resources between the entry and exit | Local-to-entry quality, exit interconnection and routing strategy | The name “private line” alone cannot predict performance at every hour |
A node is a configuration entry, a route is the transport path, and an exit is the location seen by the destination website. Choose a region to decide “where to access from,” and choose a route to decide “how to get there.”
“Multiplier,” “traffic factor” and similar fields in a node list usually relate to traffic billing, not speed multiplication. If latency is also shown, it only represents the response time from the client to the test target; it cannot fully describe video throughput, a webpage’s time to first byte or sustained download performance. Compare nodes on the same local network and at similar times, and judge them by the actual experience in the target app.
What Common Protocol Names Mean
A protocol determines how the client and server exchange data, but speed is not a fixed property of a protocol name. The same protocol can perform very differently on different servers, transport layers and routes. Protocol selection is constrained first by client support, server configuration and the current network environment, followed by encapsulation overhead and congestion-control behavior.
Shadowsocks, VMess and VLESS
Shadowsocks is an encrypted proxy protocol with a relatively straightforward configuration and broad client support. It handles proxy forwarding, but does not decide split-tunneling rules automatically; whether it takes over app traffic depends on the client mode and system settings. The encryption method must match the server and cannot be changed on the client side alone.
VMess is a protocol in the V2Ray ecosystem, with identity authentication and time-related validation, and is often combined with TCP or WebSocket transports. VLESS uses a more streamlined authentication design and does not encrypt content by itself; deployments typically pair it with TLS, REALITY or another secure transport. When reviewing a VLESS profile, treat the protocol, transport, security layer and server name as one set of parameters. Omitting any one of them can prevent a connection.
Trojan, Hysteria2 and TUIC
Trojan typically runs over TLS and resembles ordinary encrypted website traffic. It depends on the correct server name, certificate and TLS configuration; an incorrect system clock, failed domain resolution or certificate mismatch can all cause the handshake to fail. “Trojan” is the protocol name and does not indicate the client’s origin or software behavior.
Hysteria2 is based on QUIC and UDP and uses congestion-control ideas suited to high-latency, unstable networks. TUIC is also based on QUIC and UDP, with an emphasis on multiplexing and connection management. They may perform well on networks that support UDP, but office networks, public networks and some routing devices may restrict it. A failed connection in that situation does not necessarily mean the subscription is invalid; the underlying network may simply block the required traffic.
| Protocol | Common transport foundations | Configuration focus | When connection problems occur |
|---|---|---|---|
| Shadowsocks | Usually based on TCP and UDP | Encryption method, password and server parameters | Check the encryption method and client support |
| VMess | Can combine multiple transport methods | Identity parameters, transport method and clock synchronization | Check the system clock and every transport field |
| VLESS | Often paired with TLS or REALITY | Security layer, server name and transport parameters | Do not copy only the server address and port |
| Trojan | Usually TLS over TCP | Password, domain, certificate and TLS | Check the resolution result and server name |
| Hysteria2 | QUIC and UDP | Authentication, TLS and UDP reachability | Switch networks to determine whether UDP is restricted |
| TUIC | QUIC and UDP | Authentication, certificates and multiplexing configuration | Confirm that the client version supports the configuration |
How to Choose Split-Tunneling Rules, Global Mode and TUN Mode
Split tunneling answers the question, “Where should this connection go?” Rule-based mode uses domains, IPs, apps, ports or rule sets to send requests through a proxy, directly or to a blocking policy. Global mode generally sends as much client-managed traffic as possible through the current proxy node. Direct mode bypasses the proxy. These are routing decisions, not protocol types, and they do not change the server configuration in the subscription.
For everyday use, start with rule-based mode. Local services, LAN devices and websites that do not need international access can connect directly, while destinations that require a specific exit region use the proxy. This reduces unnecessary detours and helps prevent local sites from triggering extra verification because the exit region changed. If missing rules make a destination unreachable, temporarily switch to global mode for comparison. If global mode works but rule-based mode does not, the issue is usually a rule match or DNS path rather than the node itself.
The system proxy generally handles apps that follow the operating system’s proxy settings. Some games, command-line tools, standalone updaters and software with its own network stack may ignore the system proxy. TUN mode takes over a broader range of IP traffic through a virtual adapter, making it useful for these apps, but it is also more likely to conflict with other network extensions, firewalls, virtual-machine networks or enterprise management policies.
Why DNS Leaks Are Connected to Split Tunneling
Before opening a domain, the system usually resolves it to an IP address. If web traffic goes through a proxy while DNS requests still use the local network, the resolver can see the queried domains and may return a regional result that does not match the proxy exit. This is commonly called a DNS leak. It does not always cause a loss of connectivity; more often, the site detects the wrong region, resolves to an unsuitable address or follows the wrong rule because it received a different IP.
Common client approaches include proxying DNS queries, using remote resolution, selecting a resolver by domain rule or pairing a virtual DNS address with TUN forwarding. Do not focus only on which DNS address to enter. Also confirm which path actually carries the request and which rule set consumes the result. A browser’s encrypted DNS feature may bypass the client configuration, so check the specific app as well.
Why Clients Behave Differently Across Platforms
After importing the same subscription on different platforms, the node count, protocol support and available modes may not be identical. The subscription content usually has not changed; the clients simply implement different capabilities. Some support only a subset of protocols, some recognize the subscription but ignore unfamiliar fields, and others require a separate system extension to use TUN or enhanced mode.
On iOS and iPadOS, the client needs a system network extension to establish a connection and will request permission to add a VPN configuration the first time it is enabled. The connection icon in the status bar only shows that the network extension has started; verify that the rules work by checking the exit address and the destination website. The system places clear limits on background operation and network extensions, so after closing the client, rely on system settings and in-app logs to confirm the actual connection state.
Windows clients often provide both a system proxy and TUN mode. If a browser works but another app does not, first determine whether that app follows the system proxy. If enabling TUN causes LAN, virtual-machine or enterprise network problems, check the routing table, DNS and firewall conflicts. macOS follows a similar troubleshooting approach, but network-extension permissions, the system proxy and app sandboxing can affect the details.
Android usually takes over traffic through the system VPN interface and may offer per-app routing. If the connection drops after the screen locks, check background activity permissions, battery-saving policies and the always-on VPN setting instead of repeatedly reimporting the subscription. Settings vary by manufacturer, so distinguish between the client process being paused and the server being unreachable.
The Setup Sequence from Import to Verification
During initial setup, do not change the protocol, DNS, rules and system proxy at the same time. Changing too many variables makes it difficult to identify the responsible layer. A safer approach is to establish a minimal working configuration first, then add split tunneling or TUN features step by step.
- Get the subscription: Copy the complete subscription URL from the account panel without using an online converter of unknown origin.
- Choose a client: Confirm that the client supports the protocols used in the subscription and fits the current operating system.
- Import and update: Import through the subscription or remote-configuration entry, then run an update and confirm that the node list appears.
- Choose a node: Start with the target exit region, then consider the path based on whether it uses a direct route, relay or IEPL private line.
- Start with the basic mode: Prefer the client’s recommended rule-based mode and confirm that the browser can reach the target page.
- Verify the exit and DNS: Check that the exit region matches expectations and confirm that domain resolution is not bypassing the intended path.
- Cover other apps: Consider TUN or per-app routing only when an app does not follow the system proxy.
During verification, distinguish between “connection successful” and “destination available.” A successful handshake in the client may mean that it has established a connection to the node, while the destination website may still be unreachable because of DNS, routing rules, the exit region or the site’s own status. Conversely, one webpage loading does not mean every app uses the same path. Check the browser, target app and system network settings separately.
Troubleshoot Connection Failures Layer by Layer
- ✅ Update the subscription first and confirm that the node configuration is not cached
- ✅ Switch to another node in the same region to distinguish a single-node issue from a local network issue
- ✅ Check that the system clock, server name, TLS and transport parameters are complete
- ✅ For protocols such as Hysteria2 and TUIC, switch networks to test whether UDP is reachable
- ✅ Temporarily compare global mode with rule-based mode to determine whether split-tunneling rules are missing
- ✅ Check the DNS resolution path, then decide whether remote-resolution settings need adjustment
- ❌ Do not change the protocol, DNS and operating mode at the same time without recording the original configuration
Logs contain more information than the home-screen status. Common clues include failed DNS resolution, connection timeouts, TLS handshake failures, rejected authentication, a rule matching direct access or a failed virtual-adapter startup. When reading logs, find the earliest error first; later messages are often cascading results of the original problem. If logs contain a subscription URL, server credentials or complete authentication parameters, remove sensitive content before sharing them.