Best VPN for Beginners: A Complete Guide to Subscriptions, Nodes, Protocols, and Split Tunneling

What are subscription links, configuration files, and clients?

A subscription link is a configuration entry point, not a regular webpage

A subscription link usually points to a configuration set generated by the service. After accessing the address, the client reads node names, server addresses, ports, protocol types, authentication details, and selected transport parameters, then turns them into a list of selectable nodes. Pasting the link into a browser may show plain text, a download, or an unformatted response. That does not necessarily mean the link is broken, because it is not necessarily meant for browser display.

A subscription address often contains credentials used to identify an account or configuration permissions, so treat it as sensitive information. Do not paste the full address into public posts, screenshots, or untrusted online conversion tools. When asking for help, you can keep the domain and error message visible, but mask identifying fields in the path.

A configuration file is a static snapshot of fetched content

After fetching content through a subscription link, a client usually saves a local copy of the configuration. Even if the subscription server is temporarily unreachable, imported nodes may still remain visible and usable. Conversely, if the service updates its nodes but the client does not refresh, the local list will not reflect those changes automatically.

“Subscription” and “node” are therefore not the same thing. One subscription can contain multiple nodes, along with groups, policies, and rules; an individual node is simply one connection entry in that collection. When you delete a subscription, some clients also delete its nodes, while others retain the expanded local configuration. The exact behavior depends on the client implementation.

The client parses configurations, connects, and takes over traffic

A client is software installed on your device. It parses subscription formats, connects to nodes, and handles traffic through a system proxy, virtual network interface, or application-level proxy. The service provides the subscription and network-side capability; the client implements them on a particular operating system. When they come from different developers, interface labels, feature coverage, and supported formats may vary.

Copy the complete subscription link from a trusted source.
In the client, find “Add subscription,” “Import from URL,” or an equivalent option.
After importing, refresh the subscription and confirm that the node names appear.
Choose a node and operating mode, then enable the system proxy or virtual network mode.
Open a page that shows your egress address and check that it matches the selected region.

What is the difference between nodes, routes, entry points, and egress?

A “node” is usually a selectable configuration in the client. It contains a service entry and the associated protocol parameters. Its name may identify a country, city, route type, or purpose, but the name is only a label for recognition and cannot by itself prove the underlying path.

The “entry” is the service address the client connects to first. The “egress” is the public address used when a request leaves the proxy network to reach its destination. In a simple setup, the entry and egress may be on the same server; in a relay setup, the entry receives traffic and forwards it to another egress. Websites generally determine the source from the final egress address, not from the client’s location or the entry name.

A “route” refers more specifically to the network path. It describes how data travels from the local network to the entry, from the entry to a relay, and then to the egress. Two nodes using the same protocol can perform very differently if their entry providers, international paths, congestion, or egress points differ. The protocol answers “how is communication handled?”; the route answers “where does it travel?” They are not interchangeable.

Term	What it controls	Common misconception	How to check
Subscription	Configuration set and update entry point	If the subscription updates, all nodes must be available	Check the update result and node connection result separately
Node	A connection configuration in the client	The node name represents the complete network path	Review the configuration, egress address, and actual connection behavior
Entry	The server the client connects to first	The entry region must match the egress region	Distinguish the service address from the final egress address
Egress	The public address presented when accessing the destination service	Changing the node name must change the egress	Query the egress address again after connecting
Route	The network path used to transmit data	The same protocol means the route quality is the same	Compare routing, latency variation, and real-world application tests

Direct, relay, and IEPL dedicated routes

Direct connections generally mean that the client connects straight to a service node in the target region or network, without an additional forwarding entry deployed by the service. The architecture is simple, but connection quality is directly affected by the local carrier, inter-network peering, and changes along the international path.

Relay connections mean that the client first connects to a nearby or more controllable entry, which then forwards traffic to the egress. A relay can avoid some unfavorable public-network paths, but it is not automatically faster. Entry load, the path from entry to egress, and forwarding-layer configuration all affect the result.

IEPL is an industry term associated with international Ethernet private lines. Its defining feature is dedicated carriage for cross-region transmission. A product may use a private line only on certain segments; the connection from your local network to the access point, and the path from egress to the destination site, may still use other networks. When you see an “IEPL” label, understand it as a description of route architecture, not a fixed promise of speed at every location or time.

How to read protocol names: Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC

A protocol defines how the client and server encapsulate, authenticate, and transmit data. It affects compatibility, handshakes, transport-layer choices, and resilience to network fluctuations, but the protocol name itself does not indicate node load, egress quality, or the speed of the entire route. When comparing protocols, first confirm client support, then check whether the current network restricts UDP, whether packet loss is significant, and whether the server parameters match completely.

Shadowsocks

Shadowsocks is an encrypted proxy protocol. Its configuration usually includes a server address, port, encryption method, and password. Its structure is relatively straightforward and it is widely supported by clients. Different implementations may support different cipher suites and extensions, so “Shadowsocks” alone does not guarantee direct import into every client.

VMess and VLESS

VMess is a protocol in the V2Ray ecosystem with identity authentication and transport settings, and it is relatively sensitive to clock synchronization between client and server. VLESS uses a lighter authentication design and does not provide complete content encryption by itself; it is commonly combined with TLS, REALITY, or another secure transport. For a VLESS configuration, check not only the user identifier but also the transport, security layer, and server name.

Trojan

Trojan usually runs over TLS, authenticates with a password, and depends on the correct domain, certificate, and TLS parameters. If the server name is wrong, certificate verification fails, or the system clock is inaccurate, the client may fail while establishing the encrypted connection. Disabling certificate verification may hide the error temporarily, but it weakens identity verification and should not be a standard fix.

Hysteria2 and TUIC

Hysteria2 and TUIC both use QUIC and UDP transport, focusing on congestion control, recovery on unreliable networks, and multipath-style responsiveness. On some high-latency or lossy networks, they may be more flexible than traditional TCP paths, provided the local network, routing equipment, and server can all handle UDP correctly. If the network restricts UDP, these protocols may time out. Compare them with an available TCP-based transport instead of assuming the subscription has failed.

Protocol	Primary transport characteristics	Configuration points to check	Common failure area
Shadowsocks	Encrypted proxy with a straightforward structure	Encryption method, password, and implementation compatibility	The client does not support the selected encryption method
VMess	Authenticated protocol in the V2Ray ecosystem	User identifier, transport method, and system time	Inconsistent parameters or clock drift
VLESS	Lightweight authentication, commonly paired with a security layer	TLS or REALITY and transport parameters	The security layer does not match the server configuration
Trojan	TLS-based authentication and transport	Password, domain, and certificate verification	Incorrect server name or certificate
Hysteria2	Based on QUIC and UDP	UDP reachability, authentication, and TLS	The current network restricts UDP
TUIC	Based on QUIC and UDP	Client version, congestion control, and authentication	Incompatible implementation versions or parameters

How to choose between global mode, rule-based split tunneling, and direct mode

The operating mode determines whether traffic handled by the client is sent to a proxy node or through the local network. Clients may use names such as “Global,” “Rules,” “Bypass LAN,” or “Direct,” but the actual behavior depends on the active rule set and system interception method.

Global mode usually sends most traffic handled by the client through the selected node. It is useful for checking whether a website is taking the wrong path because of split-tunneling rules, and for briefly confirming that the node itself can reach the destination service. Global mode does not necessarily cover every application; if a program ignores the system proxy and the client has not enabled virtual network mode, it may still connect directly.

Rule mode chooses a destination according to domains, IP addresses, applications, or rule sets. A common setup sends local services directly, routes requests needing international access through a node, and keeps LAN devices reachable. Rule mode is better suited to everyday use, but outdated rules, incorrect matching order, or inconsistent DNS paths can cause unexpected direct or proxied connections.

Direct mode generally means that traffic does not pass through a proxy node. It can quickly show whether a problem is caused by the proxy path and restore the local network path when cross-region access is unnecessary. Direct mode is not the same as “client disconnected”: some clients may still keep a local proxy port or take over DNS while the final policy selects a direct connection.

✅ When a destination is unreachable, cross-test it in Global mode and Rule mode first.
✅ If Global works but Rule mode does not, check domain rules, rule priority, and DNS policy.
✅ If a browser works but a standalone app does not, check whether the app follows the system proxy.
✅ If a local device or LAN service is unreachable, confirm that the LAN address is set to direct.
❌ Do not assume that selecting a node means every program is using that node.
❌ Do not run multiple clients that take over the system proxy or virtual network interface at the same time.

System proxy and virtual network modes

A system proxy mainly provides an HTTP or SOCKS entry point for applications that follow the operating system’s proxy settings. Browsers usually support this well, but games, command-line programs, and some standalone clients may ignore it. Virtual network mode creates a virtual interface and handles IP traffic at a lower level, usually covering more applications while depending more heavily on routing tables, permissions, and DNS configuration.

If enabling virtual network mode prevents network access, first check for other network-filtering software, old virtual interfaces, or conflicting routes. If the system proxy is not restored when the client exits, you may find that the node is disconnected but the browser still cannot connect. In that case, disable the leftover system proxy settings.

DNS leaks, remote resolution, and domain rules

DNS converts domain names into IP addresses. Before visiting a website, a client usually resolves the domain and then establishes a connection from the result. A working proxy path does not automatically mean DNS queries use the same path; if queries remain with the local network while the connection goes through a remote node, resolution and access follow separate paths.

A DNS leak usually means that queries expected to use a controlled resolution path are accidentally sent to the local network or another unintended resolver. This may expose clues about the domains being accessed, and different regional responses may make split-tunneling decisions disagree with the actual connection.

Rule-based split tunneling depends heavily on DNS. With domain matching, a client can choose a policy before resolution; with IP matching, it must resolve the domain first and then apply rules to the returned address. Some clients also use virtual address mappings so domain information remains available for rule matching after virtual network takeover. Names vary by implementation, but the core goal is the same: keep domain resolution, rule matching, and connection egress consistent.

A browser’s built-in encrypted DNS may also bypass the client’s settings. If the same domain behaves differently in a browser and other applications, temporarily disable the browser’s independent resolution for comparison. Once troubleshooting is complete, choose a consistent resolution setup based on your privacy needs and client compatibility.

Windows, macOS, Android, iOS, and Linux client differences

The same subscription may behave differently across platforms. The usual reasons are differences in system network interfaces, application permissions, and client cores—not changes to the subscription itself. Before importing, confirm that the client supports the subscription’s protocols and transport types; afterward, check that its traffic-interception method suits the target application.

Windows and macOS

Desktop systems commonly offer system-proxy and virtual-network modes. For browsers and standard desktop applications, system-proxy configuration is simpler; for software that ignores the system proxy, virtual network mode is more suitable. macOS clearly prompts for network-extension permission. Complete the authorization the first time you enable it, or the client may appear active while system traffic never enters the virtual interface.

Android and iOS

Mobile operating systems usually take over traffic through the system-provided VPN interface. Android clients may offer per-app routing, allowing selected apps to use the proxy or connect directly. iOS is constrained by its sandbox and network-extension architecture, so protocol support, rule-update methods, and background operation may differ between clients. The system activates only one primary VPN configuration at a time; when switching clients, confirm that the old connection has been released.

Linux

Linux environments may use desktop proxies, command-line environment variables, transparent proxies, or virtual network interfaces. Whether a terminal program uses a proxy depends on its own configuration and environment variables, so a working browser does not prove that the entire system is covered. On servers, also check routing, DNS services, and permissions, and keep the original configuration so you can restore it.

Platform	Common traffic-interception methods	Priority checks
Windows	System proxy, virtual network interface	Proxy leftovers, route conflicts, and whether the app follows the proxy
macOS	System proxy, network extension	System authorization, network-extension status, and DNS configuration
Android	System VPN interface, per-app routing	App scope, background battery policy, and conflicts with other VPNs
iOS	Network extension and system VPN configuration	Configuration authorization, client protocol support, and old connection status
Linux	Environment variables, transparent proxy, virtual interface	Routing, permissions, DNS, and command-line program configuration

Beginner troubleshooting: locate the problem by connection stage

An effective troubleshooting sequence starts with fetching the configuration, then checks the node handshake, system interception, DNS, and destination service. Change one variable at a time so you can identify which setting made a difference. Repeatedly switching nodes, protocols, modes, and DNS may occasionally restore access by chance, but it will not reveal the real cause.

Check subscription retrieval: confirm that the link is complete and valid, the client can finish the update, and the expected nodes appear in the list.
Check client compatibility: confirm that the current version supports the node’s protocol, transport method, and security layer.
Check the basic handshake: after selecting a node, review the error log and distinguish timeouts, authentication failures, certificate errors, and parameter mismatches.
Check traffic interception: confirm that system proxy or virtual network mode is actually enabled and that the target app is within its scope.
Check the egress: query the actual egress after connecting and confirm that requests use the selected node instead of continuing directly.
Check DNS: compare the resolution path with the egress path and rule out local resolution, browser-specific resolution, and rule conflicts.
Check the destination service: if other websites work but one service does not, investigate regional policies, account status, or destination-side restrictions instead of reinstalling the client immediately.

Subscription update failed
└─ Check link integrity and subscription format

Subscription updates successfully, but the node cannot connect
└─ Check protocol support, authentication, TLS, UDP, and system time

The node shows as connected, but the app cannot access the network
└─ Check the system proxy, virtual network interface, and app coverage

The egress is correct, but domain access fails
└─ Check DNS, split-tunneling rules, and browser-specific resolution

Most destinations work, but one service fails
└─ Check the destination service’s regional, account, and content policies

Error logs provide more information than “unable to connect.” A timeout usually points to reachability, UDP restrictions, or an unresponsive server; an authentication failure is usually related to a password, user identifier, or subscription status; certificate errors often involve the server name, system time, or TLS configuration; if the handshake succeeds but no traffic passes, continue by checking routing, DNS, and system interception.