This complete VPN guide for beginners answers a common question: when a client shows subscriptions, nodes, protocols, latency, global mode, and routing rules, what should you look at first? You do not need a networking background. Separate where the configuration comes from, where traffic travels, and which apps need a route, and most client basics become easier to understand.
A VPN client may use the operating system’s VPN interface, a local proxy, or a TUN virtual network adapter to handle traffic. Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC usually refer to transport or proxy protocols, not traditional enterprise VPNs. For most users, the key questions are whether the configuration is compatible, whether the route suits the target service, and how to verify the result after connecting.
What are subscriptions, configuration files, and subscription links?
In a client, a “subscription” is not simply a payment action. It is a set of connection configurations that can be updated. The service organizes node names, server addresses, ports, protocol parameters, and authentication details in a format the client can read. The client then retrieves them through a subscription link. Once imported successfully, the nodes appear in the client.
Think of a subscription link as a key for retrieving your personal configuration. It usually contains identifying information associated with your account or subscription, so do not post it publicly in forums, screenshots, or shared documents. Anyone with a valid link may be able to read its node configuration. When troubleshooting, hide the full address and share only the error message and client name.
Subscription links vs. single-node configurations
A subscription link usually contains multiple nodes and lets the client fetch updates. A single-node configuration describes one connection entry and may appear as a link, a file, or manually entered parameters. If the service changes an address or route name, the subscription list can reflect the change after an update; manual configurations usually need to be edited yourself.
| Item | Subscription link | Single-node configuration |
|---|---|---|
| Contents | Usually a set of updateable configurations | Usually corresponds to one entry |
| Update method | Client fetches the subscription again | Re-import or edit manually |
| Best for | Long-term use and switching routes | Temporary testing or standalone configuration |
| Storage guidance | Avoid sharing the full address publicly | Avoid sharing authentication parameters publicly |
What happens when you import a subscription?
The client first requests the subscription address, parses the response, and then writes recognizable configurations to the local list. An import failure does not necessarily indicate a route problem. The link may be incomplete, the subscription may have changed, the client may not support the format, or the current network may be unable to retrieve it. Old imported nodes can still appear without proving that updates are working, because the list may only be cached locally.
Nodes, servers, and routes are different concepts
A “node” in a client is a selectable connection configuration. It may correspond to a server or simply serve as an entry point for a network path. Two nodes showing the same region may use different entry points, exits, protocols, or relay methods, so their real-world performance can differ.
A “server” emphasizes the device or instance providing computing and network services; a “route” emphasizes the path data takes from your local network to the destination network. When a region name appears in a client, do not judge quality from geography alone. The target website’s region, your local carrier, congestion, and changes in international routing can all affect the result.
Direct route
A direct route means the client connects straight to the remote entry point without an additional relay entry arranged by the service. Its structure is simpler, but the actual path depends largely on the local network and public routing. A shorter geographic distance does not guarantee a shorter path: data may pass through different exchange points, and performance may vary between day and night.
Relay route
A relay route first connects to an entry point better suited to local access, then sends traffic through a relay network to the exit region. The goal is usually to improve routing control in a specific network environment, not to guarantee faster performance everywhere. An extra forwarding segment adds complexity, but a relay may still be more stable when the direct public route is poor.
IEPL private line
IEPL generally refers to an international Ethernet private-line connection and is used on service pages to describe one way of organizing an international link. It is not simply a speed label on the same level as ordinary public-network direct access or relaying. Entry access, exit location, capacity management, and the target service’s route must also be considered. Seeing IEPL in a client only identifies the route type; it does not replace real-world testing.
| Route type | Basic path | Main characteristics | How to choose |
|---|---|---|---|
| Direct | Local network connects directly to the remote entry point | Simple structure; clearly affected by public routing | Test an entry point near the target region first |
| Relay | Local access point forwards traffic to the remote exit | More controllable path, but greater structural complexity | Compare when direct performance is unstable |
| IEPL private line | International traffic organized through a private-line connection | Focuses on link organization and access method | Judge together with the target region and actual access results |
A region in a route name usually describes the exit location or a use-case label. It does not necessarily mean every part of the traffic path stays within that region. For streaming, online courses, or work platforms, first choose an exit near the target service, then judge it by actual loading, login, and playback results.
How to understand common protocol names
A protocol defines how the client and server establish a connection, authenticate, and transmit data. The protocol alone does not determine route quality. Server implementation, network path, congestion, client compatibility, and parameter settings matter too. When you see a protocol name, first confirm client support, then verify that the configuration imports correctly, and only afterward compare real network performance.
Shadowsocks
Shadowsocks is a common encrypted proxy protocol. Its configuration usually includes a server address, port, password, and encryption method. It has a mature ecosystem with compatible clients on many platforms. Encryption methods vary between clients, so when a node exists but cannot connect, check the client version and supported configuration instead of repeatedly switching nodes.
VMess and VLESS
VMess and VLESS are common in clients that support multiple transport combinations. VMess configurations include their own authentication and transport parameters; VLESS uses a more streamlined authentication design and is often combined with TLS, Reality, or other transport settings. During import, copying only the server address is not enough. Missing transport, host name, or security parameters can also cause connection failures.
Trojan
Trojan usually establishes connections through TLS. Its configuration often involves the server name, certificate verification, and password. A badly incorrect system clock, DNS resolution problems, or certificate verification failure can prevent the connection from completing. Disabling certificate verification is not a standard troubleshooting step because it removes the identity check that should be in place.
Hysteria2 and TUIC
Hysteria2 and TUIC mainly use UDP-based transport approaches and are often used on networks with noticeable instability or packet loss. Under suitable conditions, they may improve transmission performance, but enterprise, campus, hotel, or certain router networks may restrict UDP. If the client times out, the issue may not be account-related; test a route compatible with TCP transmission instead.
How to read latency, bandwidth, packet loss, and jitter
Latency is the time required for data to make a round trip. It helps show whether a node is reachable and whether interactive responses feel smooth. A client’s latency test usually sends a request to one test target, so it is not identical to webpage loading, file downloads, or video playback. A low-latency node may have limited bandwidth, while a slightly higher-latency node may be steadier during sustained transfers.
Bandwidth describes how much data can be transferred per unit of time and often affects downloads, uploads, and high-bitrate video. Packet loss occurs when data fails to arrive properly during transmission and may cause buffering, retransmissions, or disconnections. Jitter is the variation in latency; live meetings, voice calls, and remote control are usually more sensitive to it.
A client’s “speed test” is only a snapshot of the current network, test target, and time. When evaluating a route, complete the actual task: open the target website, perform a normal login, play the intended content, or connect to the work service. Sorting only by listed latency can hide the exit region, protocol compatibility, and the target website’s route.
- Web browsing depends more on initial response, sustained loading, and whether the connection repeatedly drops.
- Video playback depends more on sustained throughput, buffering, and whether the exit region meets the platform’s requirements.
- Online meetings depend more on jitter, upload stability, and whether voice becomes choppy.
- Remote work also requires checking whether company systems, authentication, and local network policies allow the connection.
Global, rule-based, and direct modes
After connecting, the client still needs to decide which traffic should be handled by the node. That is the purpose of routing modes. The wrong mode can make the client appear connected while the target app does not use the selected route. It can also unnecessarily forward local services, slowing access or producing an unexpected region result.
Global mode
Global mode generally sends all traffic taken over by the client through the current node. It is useful for temporarily checking whether rules are missing: if rule mode cannot access a target but global mode can, the issue may be in split-tunneling rules or domain matching. Global mode does not guarantee that every type of system traffic is captured. The actual scope depends on whether the client uses the system proxy or TUN mode and whether the app follows system network settings.
Rule mode
Rule mode decides whether traffic uses a node, connects directly, or is blocked based on domains, IPs, apps, or rule sets. It suits everyday use by keeping local services direct while sending destinations that need international routes through a node. Rules need updates and may miss a domain, an app may use its own connection method, or a target service may change its address.
Direct mode
Direct mode generally means traffic does not pass through the selected node. It is mainly used to pause proxying, compare the original network, or troubleshoot local connectivity. If the client is still running, an interface status such as “Started” does not necessarily mean business traffic is using a remote route, so check the current routing mode as well.
| Mode | How traffic is handled | Best for | Common considerations |
|---|---|---|---|
| Global mode | All captured traffic uses the node | Temporary testing and checking rules | Local services may also be forwarded |
| Rule mode | Traffic is split by domain, address, or app | Everyday access alongside local services | Rules need updates and may miss destinations |
| Direct mode | Traffic uses the local network directly | Restoring the original network for comparison | A running client does not mean the node is active |
System proxy, TUN mode, and app proxy differences
A system proxy is a proxy setting provided by the operating system. Browsers and apps that follow it send supported traffic to the client, but some games, command-line tools, or apps with their own network stack may ignore it. This can make one app work in a browser while another still uses the local network.
TUN mode uses a virtual network interface to capture a broader range of IP traffic and usually covers more apps than a system proxy. It may require system permissions and is more likely to conflict with firewalls, enterprise security software, other VPNs, or virtual adapters. If local-device access, printing, or a company intranet becomes unreliable after enabling it, check routing and split-tunneling rather than assuming the node has failed.
An app proxy is configured by entering a proxy address and port in a specific piece of software. Its scope is clearest, but each app must be configured separately. The local listening address commonly shown in a client is usually only for apps on the same device. It is not the remote node address and should not be exposed directly to an untrusted network.
What are DNS resolution and DNS leaks?
DNS converts domain names into network addresses. Before opening a website, the system or client usually performs a lookup. Even when webpage traffic passes through a node, a DNS leak may occur if domain queries are still sent to an unexpected local resolver. Here, “leak” means that lookup requests were not handled through the configured path; it does not mean all browsing content was exposed.
Rule mode depends especially on DNS and routing working together. The client may need to identify a domain before deciding whether to connect directly or use a node. If an app uses encrypted DNS directly, has cached an old address, or the system has multiple network interfaces, the actual result may differ from the rules’ expectation. If changing DNS makes no difference, reconnect to the network and clear the system or browser DNS cache.
When checking DNS, focus on two things: who handles the query and whether the returned address suits the current route. A changed exit address alone does not prove that the DNS path matches expectations. Conversely, a test page showing multiple resolvers is not necessarily a fault, because browsers, security software, and the operating system may use different mechanisms.
- Confirm that the client’s DNS mode matches the current routing mode.
- Avoid enabling multiple network tools that all take over DNS.
- Test again after switching routes to rule out the effect of an old DNS cache.
- If an enterprise or campus network requires a specific resolver, follow its network policy.
Why clients look different across platforms
Windows clients often provide system proxy, TUN, routing rules, and startup options together. A system proxy suits browsers and other conventional apps, while TUN is better when traffic from additional software needs to be captured. Enabling TUN usually involves a virtual adapter and system permissions; when connections conflict, check whether other network tools are still running.
macOS also distinguishes between a system proxy and a virtual network interface. The system may request permission the first time a network extension is enabled. Clients present menu-bar status, rule updates, and DNS settings differently, but the underlying issue can still be broken down into whether the subscription updated, the node is reachable, traffic is captured, and DNS behaves as expected.
Android clients usually capture traffic through the system VPN interface, so a VPN indicator may appear in the status bar. App split tunneling can specify which apps use the route, but some system components or manufacturer-specific features may behave differently. Battery-saving policies that pause background apps can also interrupt the connection after the screen locks.
iOS and iPadOS clients must use the network-extension capabilities allowed by the system. The names for subscription imports, policy groups, and on-demand connections vary by client. A VPN status shown by the system only means the network extension is enabled; you should still verify the selected node, policy, and target app’s access result.
Linux clients may offer a graphical interface or run mainly through configuration files and the command line. The desktop environment, network manager, and firewall rules affect the system proxy and TUN. Command-line tools may also need separate environment variables, so “the browser works but the terminal does not” usually indicates a difference in proxy scope, not necessarily a route failure.
The complete process from importing a subscription to verifying a connection
When using an unfamiliar client, follow a fixed sequence and avoid changing too many parameters at once. Change one variable at a time so it is easier to tell whether the issue comes from the subscription, node, protocol, routing, or target service.
- Install a compatible client. Confirm that it supports the subscription format and protocols provided by the service. Get the download from the service page or the client’s official release channel.
- Import the subscription link. Use the client’s “Add subscription,” “Import from URL,” or similar feature. Do not paste the subscription address into a regular search box.
- Update the configuration list. Check whether node names appear. If parsing fails, verify that the link is complete and that the client supports the returned format.
- Choose the target region. Start with a node near the target service, then compare route types such as direct, relay, or IEPL.
- Choose a routing mode. Beginners can start with rule mode for everyday use. To check whether rules are missing destinations, temporarily switch to global mode for comparison.
- Start traffic capture. Confirm that the system proxy, TUN, or system VPN interface is enabled as required by the client. Selecting a node alone does not start the connection.
- Verify the real task. Open the target website or app and check whether login, loading, playback, or the connection works normally. Do not rely only on the client’s speed test.
- Check recovery after quitting. Stop the client and confirm that the system proxy and network access have returned to normal, preventing an abnormal exit from leaving unusable proxy settings.
If the service supports automatic subscription updates, set a sensible update schedule in the client rather than refreshing repeatedly. If the node list suddenly becomes empty, preserve the error details instead of deleting every configuration. The original information is more useful for distinguishing a format error, a failed network request, or a subscription status change.
How to troubleshoot connection failures step by step
Effective troubleshooting starts by identifying the layer where the failure occurs. Calling every problem “the VPN cannot connect” makes it easy to switch unrelated settings back and forth. The sequence below starts with the local network and then checks configuration, nodes, traffic capture, and the target service.
Check the original network first
Pause the client and confirm that ordinary websites and local network resources are accessible. If the original network is already offline, switching protocols or nodes usually will not help. Hotel, airport, and public networks may require browser authentication first; until that page is completed, the client connection may also time out.
Then check the subscription and node
Update the subscription manually and read the specific message. If the subscription updates but every node fails, possible causes include the protocol, system time, network restrictions, or client compatibility. If only one node fails, try another route in the same region before reinstalling the client.
Compare different transport conditions
If the current network restricts UDP, compare it with a compatible route using TCP-based transport; conversely, test Hysteria2 or TUIC among the configurations already provided by the service. Use an existing configuration rather than guessing ports and parameters. If the connection works after changing networks, the issue is more likely related to the original network policy or route.
Confirm that the app uses the proxy
If a browser works but a desktop app fails, check whether the app ignores the system proxy. If rule mode fails while global mode works, check domain rules and DNS. If only the local device or company intranet is affected in TUN mode, check direct rules and routing conflicts.
Check the logs last
Timeouts, resolution failures, certificate errors, authentication failures, and unsupported protocols in logs point to different areas. Before sharing logs, hide subscription links, authentication fields, and server credentials. An occasional retry does not necessarily mean the connection is unusable; judge it together with the target app’s actual behavior.
The questions beginners confuse most often
Does a successful connection mean every app is covered?
Not necessarily. A system proxy may affect only apps that follow it, and rule mode may send some traffic directly. Consider the client’s capture method, current mode, and the app’s own settings. The most reliable approach is to test the target app directly rather than looking only at the status icon.
Is the lowest-latency node always the best?
Not necessarily. A latency test reflects the round-trip time of a specific request and cannot fully represent bandwidth, packet loss, jitter, exit region, or the target website’s route. Browsing, video, meetings, and file transfers have different priorities, so choose based on the actual task.
Does the node region equal the region shown by the target website?
Usually, a node label describes the exit location or service purpose, but the target website may also consider address databases, account region, cache, DNS, and app settings. After switching regions, reopen the app or clear the relevant cache before checking again.
Will updating a subscription remove local settings?
It depends on the client. Some clients replace only the nodes in the subscription, while others also sync policy groups and rules. Whether locally added configurations are kept depends on how they are stored alongside the subscription. Export essential settings first, and avoid placing personal changes directly in a subscription group that may be overwritten.
Does a newer protocol always mean faster performance?
No. A newer protocol may offer different transport capabilities for certain network conditions, but compatibility, server configuration, and network restrictions matter too. A stable, usable configuration is more practical than chasing a protocol name. When troubleshooting, cross-test existing nodes with different protocols instead of changing advanced parameters at random.
Once these concepts are clear, the client interface is no longer just a collection of unrelated switches. Protect the subscription link, choose a node suited to the target region, confirm protocol compatibility, enable rule or global mode as needed, and verify the route with a real task. Layer-by-layer troubleshooting is more likely to reveal the cause than repeated reinstalls or changing several settings at once.