VPN terms often appear together: subscriptions, nodes, protocols, global mode, rule mode, and DNS may seem closely related, but each belongs to a different layer of the connection process. Understanding these terms is not about memorizing jargon. It helps you read a client interface, compare route differences, and know what to check when a website will not load or an app cannot connect.
It helps to picture a connection as a clearly divided path. The subscription delivers configuration data to the client, the node provides a remote entry point, the protocol defines how the client communicates with that entry point, the route determines how data travels across the network, and traffic rules decide which requests use the path. A problem at any layer may look like “unable to connect,” but the fix depends on which layer failed.
VPNs, Proxies, and Tunnels: What Do They Mean?
In everyday conversation, “VPN” is often used as a broad term for international-route clients or encrypted connection tools. Strictly speaking, a VPN focuses on creating a virtual network connection between a device and a remote network, with system traffic routed through the tunnel. A proxy usually works at the application layer or receives traffic through a local proxy port before forwarding it to a remote server according to defined rules.
The user experience can be very similar: after connecting the client, browsers and apps can access the network according to the configuration. The way traffic is captured, however, differs. A system VPN interface can cover apps that do not support proxy settings, while local proxy mode depends on system proxy settings, app-level proxy support, or transparent forwarding. Modern clients may also capture traffic through a virtual network adapter, giving proxy protocols coverage close to that of a system-level VPN tunnel.
“Tunnel” describes an encapsulated transmission path, not one specific protocol. After data enters the client, the protocol encapsulates it and sends it through the internet, a relay network, or dedicated-line resources to the exit. When you see “enable tunnel,” check whether the client uses a system proxy, virtual network adapter, or native VPN interface, because that affects app compatibility, DNS handling, and traffic-routing behavior.
Subscriptions, Configuration Files, and Subscription URLs
A subscription is a set of connection configurations that can be updated. It typically includes node names, server addresses, ports, protocol parameters, authentication details, and transport settings. Once the client reads this information, it generates selectable nodes in the interface. A subscription is not a running server, nor does it automatically mean that every node is suitable for every purpose.
A subscription URL is the entry point for retrieving this configuration set. After importing the URL into a compatible client, the client requests the subscription content and saves it locally. When the service updates nodes or changes configurations, you can refresh the subscription in the client instead of editing each item by hand. Some clients also support local configuration files. This works well for fixed settings, but does not automatically include future updates.
Subscription URLs often contain information used to identify an account or configuration permissions, so protect them like passwords. Do not post a complete URL on public forums, in screenshots, or in public code repositories, and do not hand it to an unfamiliar online conversion page. When switching clients, copy the URL again from the original service page and import it directly into a trusted client.
A General Workflow for Importing a Subscription
- First, confirm that the client supports the protocols and configuration formats used by the subscription. Being able to import a URL does not mean the client can recognize every node in it.
- Copy the subscription URL from the service dashboard, then choose “Add subscription,” “Import from URL,” or a similarly named option in the client.
- Complete the first update and check whether the node list appears. Look for messages about format errors, authentication failures, or unsupported fields.
- Choose a node suited to your purpose, then enable the system proxy, virtual network adapter, or VPN interface.
- Verify that the target website and app connect as expected. Also confirm that local websites, LAN devices, and essential system services have not been routed incorrectly.
If a subscription update fails but previously saved nodes still connect, the problem may be in the subscription retrieval step rather than an interrupted route. Conversely, a successful update only means that the configuration downloaded; it does not prove that every node in it can establish a connection. Treat “refresh subscription” and “test node” as separate checks to avoid repeatedly deleting the client or reinstalling the system.
Nodes, Exits, and Routes Are Different Concepts
A node is a selectable connection configuration in the client. It is usually named after a country, region, city, purpose, or route type. The name mainly helps with identification and does not fully describe how data travels. Two similarly named nodes may use different entry points, relay arrangements, exit networks, and protocols. Nodes in the same region can also perform differently at different times.
The exit is the location from which a request appears to leave the service network to the target website. The region shown for a node usually describes its exit, but the exact meaning depends on the service documentation. The entry is the server or access point where the client first establishes a connection. With relays or dedicated lines, the entry and exit may be in different network locations.
A route describes how data is transported from the user side to the exit. Do not judge a route solely by map distance. Physical distance affects propagation delay, but carrier interconnections, congestion, detours, cross-border link quality, and the target website’s network also affect the result.
| Route Type | Connection Path | Common Characteristics | What to Check |
|---|---|---|---|
| Direct | The device connects directly to the remote entry point | Simple structure; performance is more visibly affected by public-internet routing | Observe the actual path from the local carrier to the remote endpoint |
| Relay | The connection enters a relay first, then proceeds to the exit | Can change part of the public-internet path, but results depend on the entry point and relay resources | Check the entry location, congestion, and relay path |
| IEPL Dedicated Line | Uses enterprise-grade international dedicated-line resources to connect the relevant access points | The path is organized differently from a standard direct public-internet connection | Confirm the service label, exit purpose, and local access conditions |
IEPL is an industry term for a category of international Ethernet dedicated lines. Services for individual users typically use dedicated-line resources for part of the cross-border transmission path rather than giving the user’s device a dedicated line. Therefore, an “IEPL node” is best understood as a node whose route uses the corresponding dedicated-line resources; it does not imply fixed latency, fixed bandwidth, or any absolute stability guarantee.
A relay is not the same as a dedicated line. A relay simply adds one or more forwarding steps, which may still run over the public internet. A high-quality relay can avoid an unsuitable direct route, but it may perform worse than direct access if the entry point is congested or the relay arrangement does not suit the local network. Choose routes based on your use case and testing, not just their names.
Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC
A protocol defines how the client exchanges data with the server, including authentication, encapsulation, encryption integration, and transport. A protocol name is not a speed rating. The same protocol can perform very differently depending on server load, network path, and client implementation. When choosing a protocol, check client compatibility first, then whether the current network permits the required transport, and finally the intended use.
Shadowsocks
Shadowsocks is an encrypted proxy protocol whose configuration usually includes a server, port, password, and encryption method. It is mature and supported by many clients, making it suitable for ordinary web and app proxying. It does not provide a complex rule system itself; traffic routing is generally handled by the client. If the encryption method is unsupported, the connection will fail even when the other parameters are correct.
VMess and VLESS
VMess is a protocol in the V2Ray ecosystem. It includes authentication and protocol-layer encryption mechanisms and can be combined with different transport methods. The client and server must match on the user identifier, transport type, TLS settings, path, and other parameters. Any mismatch in a key field may appear as a handshake failure.
VLESS uses a lighter protocol design and does not treat protocol-level encryption as a complete security layer. It is commonly paired with TLS, REALITY, or other secure transport configurations. When working with a VLESS node, do not copy only the server address and port; flow control, transport, security type, and related identifiers are also part of the connection configuration.
Trojan
Trojan typically establishes connections through TLS. Its configuration often includes a domain, certificate verification, server name, and password. An incorrect system clock, domain resolution problem, or certificate-validation issue can cause the TLS handshake to fail. Disabling certificate verification for temporary troubleshooting is not a sound long-term solution; first check the domain, system time, and configuration consistency.
Hysteria2 and TUIC
Hysteria2 and TUIC both build their transport mechanisms on QUIC and UDP and provide capabilities such as congestion control for challenging network conditions. They may behave differently from traditional TCP transports on links with instability or packet loss, but only when the current network allows UDP and the client fully supports the relevant protocol.
Some office, public, or router networks restrict UDP. In that case, Hysteria2 or TUIC may fail to complete a handshake or become unstable after connecting. First compare them with a configuration that supports TCP instead of concluding that the account, subscription, or entire service is unavailable.
Global Mode, Rule Mode, and Direct Mode
Traffic routing is the process by which a client decides where requests should go. Based on domains, IP addresses, apps, ports, or rule sets, it can send traffic to a proxy node, connect directly, or block access. Routing happens in the local client and is separate from the service’s route type.
Global mode usually means that most traffic the client can capture is sent through the current proxy node. It is useful for troubleshooting: if the target app works in global mode but not in rule mode, the issue is more likely to involve rule matching, DNS decisions, or app-level bypass than a completely failed node. Global mode can also send local websites, LAN services, or apps that do not need international routes through a longer path.
Rule mode selects a path according to preset conditions. A common setup sends local resources directly, routes domains that need international access through the proxy, and keeps LAN addresses direct. It is better suited to everyday use but depends on rule quality and update status. If new domains, embedded app domains, or content-delivery network addresses are not identified correctly, the main page may load while images, login requests, or API calls fail.
Direct mode generally means that traffic does not pass through the selected node. It can help compare whether the local network is working and is useful for accessing LAN resources. Note that disabling the system proxy in some clients does not also stop the virtual network adapter, while other clients may leave a background service running after the interface is closed. During troubleshooting, check the actual runtime state rather than only whether the window is closed.
| Mode | Traffic Handling | Best For | Common Issues |
|---|---|---|---|
| Global mode | Most traffic goes through the current node | Quickly checking node and app compatibility | Local resources take a longer path; LAN access may be affected |
| Rule mode | Chooses a path by domain, address, or app | Everyday access and purpose-based routing | Missing rules, rule-order problems, or incorrect DNS decisions |
| Direct mode | Requests use the local network directly | Baseline testing and LAN access | Assuming the node is still handling traffic |
DNS, DNS Leaks, and Domain Resolution
DNS translates domain names into network addresses. A browser usually needs to resolve a domain before visiting a website. Even when a node connects successfully, the page may not load if DNS requests fail, return unreachable addresses, or conflict with traffic-routing rules.
A DNS leak generally means that DNS requests expected to travel through a tunnel or specified resolver are instead sent through another path on the local network. This may expose the domains being queried or cause regional inconsistencies and incorrect routing decisions. Changing the node name alone will not fix it. Check how the client captures DNS, along with system settings, the browser’s secure DNS, and virtual network adapter configuration.
Encrypted DNS can protect DNS requests in transit between the device and resolver, but it does not automatically ensure that requests pass through the selected node. If the browser enables its own secure DNS, it may bypass the client’s DNS module. If the client uses domain-based rules, resolving domains early at the system level may also affect rule matching. The browser, system, and client should use coordinated resolution policies.
Virtual IP or Fake IP mode first returns an address managed by the client to the app, then uses domain rules to decide the real connection path. This preserves domain information and can improve transparent routing, but some LAN apps, games, or programs that depend on real addresses may need to be excluded. Redir Host mode returns real resolution results instead; its compatibility differs and depends more heavily on coordination between DNS and routing rules.
What to Check When Investigating DNS Issues
- Can the target domain be resolved, and does the failure occur only after the connection is enabled?
- Has the browser enabled secure DNS independently of the system?
- Does the client capture system DNS, and is virtual network adapter mode actually running?
- Are LAN domains and local device addresses being sent to a remote resolver by mistake?
- Are IPv4 and IPv6 resolution and routing taking different paths?
System Proxy, Virtual Network Adapters, and Platform Differences
Windows and macOS clients often provide both system proxy and virtual network adapter modes. A system proxy changes the operating system’s proxy settings, but only apps that follow those settings will use it. A virtual network adapter captures a broader range of traffic through a network interface and routing, making it more suitable for apps that ignore system proxy settings, though it requires the appropriate system permissions.
On iOS and Android, third-party network clients usually capture traffic through the VPN interface provided by the operating system. A VPN indicator in the status bar only shows that the relevant interface is working; it does not identify a particular proxy protocol. The actual protocol is determined by the imported node configuration. Mobile operating systems may also pause connections because of power-saving policies, network changes, or background restrictions.
Linux environments vary considerably. Desktop apps may modify proxy environment settings or create virtual interfaces, while command-line tools may require proxy variables to be configured separately. If a terminal connects but a browser does not, or the browser works while the package manager fails, the programs are probably using different proxy entry points rather than the node imposing a special restriction on a particular command.
The same subscription may show a different number of nodes on different platforms. Common reasons include the client’s protocol support, configuration parsing capabilities, and platform network interfaces. If an import is incomplete, first check the client log for “unsupported protocol” or “field parsing failed” before deciding whether to switch to a compatible client.
A Troubleshooting Sequence Based on the Symptoms
Effective troubleshooting starts with changing only one condition at a time. Switching nodes, protocols, clients, and DNS settings repeatedly makes results impossible to compare. Narrow the cause step by step, from the local network and subscription to protocol handshakes, routing rules, and the target website.
- Confirm that the local network can access common websites normally in direct mode, ruling out an offline device, router problems, and an incorrect system clock.
- Refresh the subscription and look for a specific error. If the refresh fails, check the subscription status and the client’s network access. If it succeeds, test the node separately.
- Choose a protocol the client explicitly supports. When a UDP-based protocol fails, compare it with a TCP transport configuration. When a TLS handshake fails, check the system time, domain, and configuration fields.
- Verify the target app in global mode first. If it works globally but not in rule mode, focus on routing rules, DNS, and app bypass settings.
- Compare the browser with other apps. If only one app behaves abnormally, check whether it uses its own proxy, independent DNS, or built-in network stack.
- Review client logs for connection timeouts, authentication failures, DNS errors, or rule-match information. Logs reveal the failing layer more clearly than repeatedly clicking Connect.
A “timeout” usually means that the expected response did not arrive within the allowed wait period. It may occur between the local device and entry point, between entry and exit, or between exit and the target website. “Connection refused” more specifically suggests that the target port did not accept the request. “Authentication failed” should prompt you to check whether the subscription has expired, the configuration is current, and all authentication fields are present. Wording varies slightly by client, but these three symptoms should not be treated as the same issue.
What Beginners Should Really Check When Choosing a Route
Region is only the first filter when choosing a node. For ordinary web browsing, prioritize a clear path, stable connectivity, and a route that fits the target service’s regional requirements. Video meetings and real-time collaboration are more sensitive to latency variation and packet loss, while large-file transfers depend more on sustained throughput and long-session stability. A route that works well for downloads is not necessarily suitable for real-time calls.
The protocol should also match the network environment. On a network that supports UDP but has noticeable fluctuations, compare Hysteria2 or TUIC. On a network that restricts UDP, prepare a protocol configuration that can connect over TCP. In rule mode, also confirm that meeting, login, static-resource, and API domains use a consistent exit so requests within one session do not come from different regions.
Finally, do not treat the client’s single latency reading as a complete verdict. It usually reflects one probe from the client to a test endpoint and does not represent the target website’s response time, sustained bandwidth, or peak-period performance. A more reliable approach is to compare the actual app for a short period while recording the node, protocol, mode, and network conditions, then choose the combination that fits your use case.