VPN Beginner Guide: Subscriptions, Nodes, Protocols and Split Tunneling

This complete VPN guide for beginners starts with the options most commonly found in clients: subscriptions, nodes, protocols, and split tunneling. No prior networking knowledge is required. The key is to identify where configuration comes from and where traffic travels before deciding which requests should use international routes. Once these concepts are clear, import failures, connected nodes with inaccessible websites, and slow local sites can usually be diagnosed step by step instead of by changing every setting at once.

What Are Subscription Links, Configuration Files, and Nodes?

A subscription link is an address that a client uses to retrieve configuration. After accessing it, the client receives the node names, server addresses, ports, protocol parameters, and group information published by the service. When the provider changes an entry point or parameter, users can usually update the subscription in the client instead of entering every field again.

A subscription link is not an ordinary webpage for everyday browsing. It may contain access credentials associated with an account configuration, so it should not be pasted publicly into forums, speed-test pages, or screenshots, and should not be given to unknown online conversion tools. When converting formats between clients, use a compatible format provided by the service whenever possible, or complete the conversion in a trusted environment.

A configuration file serves a similar purpose to a subscription link, but it updates differently. A static configuration file contains the content exported at a specific time; a subscription link lets the client fetch the service's current configuration again. If node names have been updated but the client still shows an old list, run “Update subscription” first and then check the local cache instead of assuming the route is unavailable.

A node usually represents one connection entry point available for selection in the client. Its name may include a region, city, route type, or purpose tag, but the name itself is not the complete path. Two nodes labeled with the same region may use direct access, relay routing, or a dedicated route; the same entry point can also perform differently depending on the local carrier, access network, and destination website.

General Steps for Importing a Subscription

1. Copy a subscription link compatible with the current client from the service panel. Do not manually remove or alter any characters.
2. In the client, find “Subscriptions,” “Configuration sources,” or “Remote configuration,” then add and save the link.
3. Run an update and confirm that nodes or policy groups appear in the list, rather than seeing only the subscription name.
4. Choose a node near the region where the target content is hosted, then enable the system proxy or tunnel mode.
5. Open the target website to verify the connection. If it fails, check the subscription update time, protocol compatibility, system proxy status, and DNS settings in that order.

Direct, Relay, and IEPL Dedicated Routes: What's the Difference?

A node is the entry point users see, while a route describes the path used from the local network to the entry point or from the entry point to the destination network. Route labels help with initial filtering, but actual performance still depends on the local network, exit congestion, interconnection with the destination, and the client protocol. Consider the node region and route type separately when choosing.

Direct access is not automatically faster. If the public-network path from the local network to an international entry point is stable, direct access can reduce forwarding layers. If interconnection quality is poor, relay routing may improve the path through a better entry point. IEPL is an industry term for an international Ethernet private line, but services differ in how they design dedicated entry points, exits, and subsequent paths. The name alone cannot prove that all traffic uses the same type of transport.

When choosing a route, beginners can first filter by the region where the target content is available, then compare route types. For content intended for Japan, for example, prioritize Japanese exit points instead of simply choosing the geographically nearest node. For everyday documents, code repositories, or web browsing, prioritize connection stability and reliable domain resolution.

Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC

A protocol defines how the client and server establish a connection, authenticate, encapsulate data, and select a transport method. A protocol name does not directly indicate a node's region and cannot guarantee speed on its own. The server must support the same protocol, and the client must correctly implement the relevant transport and security parameters for the connection to work.

Shadowsocks

Shadowsocks is an encrypted proxy protocol. Its configuration typically includes a server, port, encryption method, and password. It is closer to a proxy than a traditional system-level VPN; whether it can handle every application depends on whether the client provides system proxy, virtual network adapter, or transparent proxy support. If the browser works but other applications do not, check the client's traffic-handling mode rather than only the node.

VMess and VLESS

VMess is a common protocol in the V2Ray ecosystem, with authentication and protocol-layer processing. It is relatively sensitive to issues such as a significantly incorrect system clock. VLESS uses a more streamlined authentication and data structure; it does not provide complete transport encryption by itself and is usually combined with TLS, REALITY, or another supported secure transport. When importing it, preserve the transport type, hostname, path, security layer, authentication identifier, and other parameters—not just the server address.

Trojan

Trojan typically runs over a TLS connection, with configuration fields for the server name, certificate verification, and password. If the client time, server name, or certificate-verification parameters do not match, the connection may fail during the TLS handshake. Disabling certificate verification is not a universal fix; instead, check that the subscription is complete, the system time is correct, and the client supports the transport used by the configuration.

Hysteria2 and TUIC

Hysteria2 and TUIC both use QUIC-based approaches over UDP, focusing on better transport performance on networks with packet loss or instability, and supporting concurrent data streams. They are not faster on every network: some office networks, public networks, or routers restrict UDP, which can cause handshake failures, rapid disconnects, or very limited data transfer. In that situation, compare a compatible node based on TCP and TLS instead of repeatedly changing unrelated split-tunneling rules.

For beginners, the safest principle is not to chase protocol names, but to start with a configuration provided natively by the service and fully supported by the client. If several protocols are available, compare them based on whether the current network allows UDP, whether system-level traffic handling is needed, and how reliably the target application works.

System Proxy, TUN Mode, and VPN Mode Explained

The “system proxy” commonly offered by desktop clients changes the operating system's proxy settings, causing applications that follow those settings to send HTTP or SOCKS requests to the local client. Browsers usually support the system proxy, but some games, command-line programs, and applications with their own network stack may ignore it. If the browser works while other software connects directly, the issue is often the scope of traffic handling.

TUN mode creates a virtual network interface and uses system routing to send more types of IP traffic into the client, which then processes them according to its rules. It covers more traffic but is also more vulnerable to route conflicts, permissions, firewalls, and other network tools. If local printing, LAN devices, or corporate intranet resources become inaccessible after enabling it, check LAN bypass rules instead of forwarding every private address remotely.

Mobile platforms generally use the system-provided VPN interface to handle traffic. A VPN indicator in the status bar only means that the system tunnel interface is enabled; it does not mean every domain is passing through a remote node. The client may still send some traffic directly according to its rules, which is normal behavior in rule mode.

• Only the browser works: check the system proxy and the application's own proxy settings.
• No application can connect: check the node connection, tunnel permissions, default route, and DNS.
• LAN devices are inaccessible: check private-network bypass rules and route conflicts.
• The connection recovers on another network: check whether the original network restricts UDP, proxy ports, or specific transports.

Choosing Between Global, Rule, and Direct Modes

Global mode generally means that all traffic handled by the client is sent through the current proxy node. It is useful for a temporary test of whether split-tunneling rules are causing the issue: if rule mode fails while global mode works, focus on domain matching, rule priority, or DNS resolution rather than the protocol itself.

Global mode is not the right default for every situation. Local websites, LAN services, and apps sensitive to the apparent source region may also be sent remotely, creating longer paths, a changed sign-in environment, or inaccessible local resources. “Global” only applies to traffic successfully handled by the client; programs outside system-proxy or tunnel control may still connect directly.

Rule mode decides whether traffic uses the proxy, connects directly, or is blocked based on domains, IPs, application processes, or rule sets. A common approach is to send local services and LAN traffic directly while using the proxy for domains that require international access. Rules are usually matched in order, so a broad rule placed first can override more specific rules later.

Direct mode means that traffic does not pass through a remote proxy. It is commonly used to pause proxying, access LAN resources, or check whether the local network is working. If a locally accessible website also fails in direct mode, the cause may be the underlying network, browser cache, or local DNS rather than the node.

A Practical Selection Order

1. After the first import, use rule mode and choose a node matching the target content's region.
2. If access fails, briefly switch to global mode to determine whether a rule is missing.
3. If global mode also fails, check the node connection, protocol compatibility, system time, and DNS.
4. If local services behave abnormally, switch to direct mode for comparison and check LAN bypass rules.
5. Once the cause is confirmed, return to rule mode and correct only the necessary domain or application rules.

What Is a DNS Leak, and Why Can a Connection Work While Websites Do Not?

After a domain is entered, the system first uses DNS to look up its address. If web traffic enters the proxy while DNS queries are still sent to the resolver assigned by the local network, that resolver may still see the domains being queried; this is commonly called a DNS leak. It can also produce results that do not match the proxy's exit region, causing the website to return the wrong address, a regional page, or a failed connection.

A DNS leak should not be diagnosed from a single test page. The browser may use its own encrypted DNS, the operating system may retain cached results, and the client may use different resolvers for different domains. Troubleshoot by first identifying the current traffic-handling mode, then reviewing the client's DNS settings and routing logic.

DNS Troubleshooting Steps

1. Confirm whether the client has enabled remote DNS, proxy DNS, or DNS handling through the tunnel.
2. Check whether rule mode resolves domains before matching IPs; the processing order can differ between clients.
3. Clear the system and browser DNS caches, then reconnect to the node to avoid interference from old results.
4. Temporarily disable the browser's independent encrypted DNS for comparison and determine who is sending the DNS requests.
5. If nothing resolves after enabling TUN, check for conflicts among virtual-interface DNS, the system firewall, and other network tools.

Another common situation is that DNS returns an address normally but the connection still fails. Check whether the target traffic actually matches a proxy rule, whether the node supports the relevant network type, and whether IPv6 traffic is bypassing a configuration that handles only IPv4. If the client does not fully handle both address types, the same website may work intermittently.

How Split-Tunneling Rules Match Domains and Applications

Split-tunneling rules commonly include domains, domain suffixes, IP ranges, geographic rules, application processes, and a final fallback rule. A domain-suffix rule can cover a site and its subdomains, but large services often also rely on content delivery, sign-in, image, and API domains. Adding only the homepage domain may load the page shell while its content fails to appear.

Rule order matters as well. Clients generally look for the first matching item from top to bottom. If a broad rule such as “all domains direct” comes first, a specific proxy rule later will not take effect. The final rule handles requests that match none of the earlier conditions; choosing proxy or direct behavior for it can significantly affect the overall result.

IP rules have a prerequisite: the client must first obtain the destination address. If DNS is resolved locally, the domain may resolve to an address that does not match the proxy exit; if the client uses remote resolution, the result may differ. For websites that depend on regional routing, domain rules are usually easier to understand and maintain.

LAN and local services → Direct
Domains that clearly require international access → Proxy
Known applications that should retain a local exit → Direct
Unmatched traffic → Choose a fallback policy based on the current use case

The order above is a logic example, not an import-ready configuration. Different clients use YAML, JSON, graphical rules, or dedicated syntax, and field names vary. Before copying rules, check the client documentation, especially the difference between domain-suffix, full-domain, and keyword matching.

Client Differences Across Windows, macOS, Android, iOS, and Linux

The same subscription may not show exactly the same options on every platform. The reason is usually not a node change, but differences in operating-system network interfaces, background restrictions, and client implementations. When moving between platforms, confirm that the protocol and transport are supported instead of comparing client names alone.

Windows clients commonly offer both a system proxy and TUN mode. TUN may require a virtual network adapter driver and the appropriate permissions, while enterprise security policies may restrict driver installation. If the system still cannot access the internet after the client exits, check whether the system proxy was restored correctly.

macOS generally establishes the tunnel through a Network Extension, which requires user approval for the relevant system permission the first time it is enabled. The system proxy and Network Extension may be controlled by separate features, so even when the menu bar shows connected, confirm which traffic-handling mode is active. Other firewalls or network-filtering extensions can affect routing and DNS.

Android clients generally use the system VPNService interface and may offer per-app routing. Battery optimization and background restrictions can pause the client process after the screen locks, leaving the connection indicator visible while data stops flowing. For a persistent connection, check the system's background-running policy for the client.

iOS clients work through a system Network Extension, and available protocols depend on the client implementation and system permissions. A transport included in the subscription may be ignored or shown as unavailable if the client does not support it. Check the client's support list before importing instead of manually deleting unrecognized fields and continuing.

Linux differences come largely from the distribution, desktop environment, routing tools, and DNS management components. A command-line proxy affects only programs that explicitly use proxy environment variables; handling other applications generally also requires TUN, policy routing, or a transparent proxy. Troubleshoot the interface, routing table, DNS management, and firewall rules separately.

What Order Should You Follow When Troubleshooting?

Changing the protocol, node, DNS, split tunneling, and system proxy all at once makes the problem harder to isolate. A more effective method is to change one variable at a time and record which step changes the result. The sequence below starts with the configuration source and checks each layer through to the application.

1. Check the subscription: Confirm that the link is not truncated, the update shows a clear success message, and the node list is not an old cache.
2. Check client compatibility: Confirm that the client supports the current protocol, transport method, and security parameters.
3. Check the node connection: Identify whether the error occurs during DNS, TCP, UDP, TLS, or authentication.
4. Check the traffic-handling mode: Confirm that the target application follows the system proxy or is handled by TUN or the system VPN interface.
5. Check split tunneling: Temporarily use global mode to determine whether the domain was incorrectly assigned to direct access.
6. Check DNS: Clear the cache and verify remote resolution and the browser's independent DNS settings.
7. Check the local environment: Rule out conflicts with the firewall, other VPNs, network-filtering extensions, and enterprise policies.
8. Compare another network: If the same configuration works on another network, focus on UDP and routing restrictions on the original network.

Client logs are more useful than saying “it won't connect,” but remove subscription links, authentication details, server credentials, and local file paths before sharing logs. Tell technical support the platform, client version, traffic-handling mode, node protocol, stage where the error occurs, and comparison tests already performed. This usually helps locate the issue more effectively than sending a series of interface screenshots.