When you first look at a VPN or cross-border networking service, the most confusing part is often not the buttons but terms such as “subscription,” “node,” “protocol,” and “routing.” Each belongs to a different layer: the subscription delivers configuration, the node is a connection endpoint, the protocol determines how the client transfers data, and routing rules decide which connections use the proxy. Once these layers are separated, product pages and client interfaces become much easier to understand.
Here is a simplified data path: an app sends a request, and the client uses routing rules to decide how to handle it. Requests that need a proxy connect to a node using the selected protocol, then travel through the node or an onward relay route to the destination website. Requests that do not need a proxy use the local network directly. The subscription link itself does not carry your everyday web traffic; it mainly delivers nodes and related parameters to the client.
What are a subscription link, client, and configuration file?
A subscription is an updateable configuration source
In proxy tools, a subscription is usually a server-generated URL. After the client accesses it, it can retrieve node names, server addresses, ports, protocol types, authentication details, and other connection parameters. When the service updates its nodes, refreshing the subscription in the client fetches the new configuration without requiring every field to be entered manually.
A subscription URL often contains credentials that identify an account or plan, so it should not be posted on public pages, included in screenshots, or shared in documents. Anyone who knows the URL may be able to read its node configuration or consume the plan’s traffic. If you suspect the URL has been exposed, reset the subscription through the service dashboard rather than only deleting it from the client.
The client parses configuration, connects, and applies rules
A client is software installed on your device. It reads subscription content, displays the node list, establishes protocol connections, and handles network requests from the system or apps according to the selected mode. Different client names do not necessarily mean different underlying protocols; the same protocol may be implemented by multiple clients. To determine whether an import will work, check the client’s supported protocols and subscription formats instead of comparing software names alone.
A configuration file is a static configuration that the client can read. It may contain one node or include node groups, DNS settings, rule sets, and policy selections. Unlike a subscription, a static file does not automatically follow server-side changes. If the service changes its endpoints, the old file may retain outdated information, so long-term use usually requires re-importing or updating it.
| Term | Primary purpose | Common misconception | What to check |
|---|---|---|---|
| Subscription link | Delivers and updates node configuration in the client | Treating the subscription as an everyday transport protocol | Whether it comes from a trusted dashboard and whether it has been exposed |
| Client | Parses configuration, establishes connections, and applies routing | Assuming that changing clients always changes the route | Protocol compatibility, system permissions, and rule support |
| Configuration file | Stores static parameters such as nodes, DNS, and rules | Assuming it will update automatically forever after import | Whether the format matches and the content is still current |
| Node | Provides a network endpoint the client can connect to | Equating a node name with the complete route | Entry location, exit location, and route type |
How are nodes, entry points, exit points, and routes different?
“Node” is one of the most common options in a client interface, but a node name may describe only part of the complete path. The client first connects to an entry server, while the destination website typically sees the exit address. The entry and exit may be in the same region, or they may be connected by a relay route. A city name or flag in the node label is not enough to determine the full path.
Direct route
A direct route usually means that the client connects straight to a server in the destination region, without an additional forwarding entry arranged by the provider. Its structure is simpler and has fewer relay steps, but the international segment depends more heavily on the current public routing of the network operator. Evening congestion, changes in carrier interconnection, and local network quality can all affect the experience.
Relay route
A relay route first connects to a nearby or more stable entry point, then forwards traffic to the exit through a link arranged by the provider. The goal is usually to avoid poor-quality public-network segments or place the entry point closer to the user’s network. A relay does not guarantee lower latency, because forwarding adds processing and path costs. Actual performance depends on the entry location, international segment quality, and exit load.
IEPL private line
IEPL is commonly used to describe international Ethernet private-line products for business use. In retail networking services, an IEPL label often means that the core international segment uses a corresponding private line or private-line resources; it does not mean that the user’s device connects directly to a dedicated physical circuit. When reading a product page, distinguish between the route type used for the international segment and the local public-network connection from the user to the entry point. Even a stable core segment can be affected by local access quality.
A node is a selectable entry configuration, a route is the path data actually takes, and the exit determines the network location seen by the destination website. They are related, but they are not the same thing.
What do proxy protocols determine?
A protocol defines how the client and server establish a connection, authenticate, encapsulate data, and handle transmission. It affects compatibility, handshakes, loss recovery, and resource use, but it cannot determine the speed of the entire route by itself. A high-quality route may perform poorly with an unsuitable protocol, while correct protocol settings cannot fix severe congestion in the underlying network.
| Protocol | Key characteristics | Scenarios to consider | Check before use |
|---|---|---|---|
| Shadowsocks | A relatively simple structure that uses an encryption method and password to establish the connection | Conventional proxy setups with broad client compatibility and simple configuration | Whether the encryption method is supported by the client |
| VMess | Common in the V2Ray ecosystem, combining authentication with transport-layer options | Configurations that require WebSocket, TLS, or other transport settings | The transport method, hostname, and path must match |
| Trojan | Typically authenticates and transfers data over a TLS connection | Servers with an established domain name and certificate configuration | Whether the certificate, domain, and system time are correct |
| VLESS | A lightweight authentication structure that usually relies on an external transport layer for security | Environments that need flexible combinations of TLS or other transport methods | Both the security and transport layers must be configured |
| Hysteria2 | Built on QUIC and UDP, using congestion control to handle unstable links | Networks with high latency or some packet loss | Whether the local network permits stable UDP transmission |
| TUIC | Also built on QUIC and UDP, with an emphasis on multiplexing and connection migration | Environments with mobile-network handoffs or many concurrent connections | Whether the client and server implementations are compatible |
The “encryption method” in Shadowsocks is part of the protocol configuration, so the server and client must use the same method. VMess, Trojan, and VLESS are often combined with transports such as TLS, WebSocket, and gRPC. An import failure is therefore not always caused by incorrect authentication; the domain, path, service name, or security-layer settings may also be mismatched.
Hysteria2 and TUIC depend on UDP. If a corporate network, campus network, or router restricts UDP heavily, the client may fail to complete the handshake or become unstable after connecting. In that situation, switch to another available protocol or route instead of repeatedly changing unrelated routing rules.
Global mode, rule mode, and direct mode
After a connection is established, the client still needs to decide where each request should go. That decision is made jointly by the operating mode and routing rules. With the wrong mode, common symptoms include local websites taking a longer route, some apps failing to connect, local-network devices becoming unreachable, or an app appearing connected without actually using the proxy.
Global mode
Global mode usually sends every connection the client can take over through the selected node. It is useful for temporarily diagnosing rule problems: if rule mode fails but global mode works, the issue may lie in domain classification, app rules, or rule priority. However, global mode also sends local services that would normally use a direct connection through the remote exit, which may increase latency and change the region shown to websites.
Rule mode
Rule mode uses domains, IP addresses, apps, processes, or rule sets to decide whether traffic should use the proxy, connect directly, or be blocked. It is usually better for everyday use because local services can stay direct while requests that need international routes are sent through a node. Its accuracy depends on whether the rules are up to date and whether the client can identify the destination domain and app traffic.
Direct mode
Direct mode generally keeps ordinary requests out of proxy nodes and can be used to pause proxying or compare the local network state. It does not necessarily mean the client has been fully exited: some software may retain local DNS settings, a virtual network adapter, or system proxy settings. When troubleshooting, check both the client status and the system network settings.
- ✅ To temporarily check whether rules are the problem: keep the same node and compare global mode with rule mode.
- ✅ For everyday access to local and international services: prioritize a rule mode that is properly maintained.
- ✅ If local-network devices cannot be opened: check whether the local subnet was mistakenly sent through the proxy.
- ❌ Do not run multiple clients that take over the system proxy or virtual network adapter at the same time.
- ❌ Do not overwrite the existing configuration in bulk before confirming what the rules do.
Why DNS leaks and domain resolution matter
After a user enters a domain, the device usually uses DNS to look up its IP address. If the web connection goes through a proxy while DNS queries still leave directly through the local network, the local resolver may see the requested domain—this is commonly called a DNS leak. It can also create inconsistent regional results: the connection exits in one region, while DNS returns results tailored to the local network, leading to an unsuitable content endpoint.
Clients do not all handle DNS in the same way. Some take over system queries and route them according to rules; some use encrypted DNS; others map domains to virtual addresses so domain rules can be associated with later connections. Whatever the approach, the goal is to keep name resolution consistent with the connection path while preventing local domains, local-network devices, and internal corporate domains from being sent to external resolvers incorrectly.
Common signs of DNS problems
- The node shows as connected, but a specific domain will not open, while entering a known IP address produces a different result.
- After switching nodes, the website’s region does not change promptly because an old DNS cache is still being used.
- Rules depend on domain matching, but the app connects directly to an IP address, so the expected rule is never matched.
- Local-network device names cannot be resolved because the query was sent to a resolver that does not know the internal names.
Client imports and platform differences
The basic subscription-import process is similar: copy the subscription URL from the service dashboard, choose Import from URL or Add Subscription in a compatible client, refresh the configuration, select a node, and enable the system proxy or virtual-network-adapter mode. The parts most likely to cause trouble are system permissions, protocol compatibility, and the scope of traffic takeover.
Windows clients commonly offer system proxy and virtual network adapter modes. System proxy mainly covers apps that follow system settings; a virtual adapter can usually handle more types of traffic but requires the relevant network component and system permission. If a browser works but a desktop app does not, check whether that app bypasses the system proxy.
macOS has a defined authorization flow for network extensions and VPN configurations. The first time a client enables these capabilities, the system may ask for confirmation. If authorization is incomplete, the client may show that the configuration was imported even though system traffic has not been taken over. If problems appear after a client update, also check whether the network extension is still enabled.
On iOS and iPadOS, clients take over traffic through the system VPN configuration, and the first connection requires confirmation to add the configuration. Android clients may be affected by battery-saving policies, background restrictions, and the always-on setting. When a mobile device switches between Wi-Fi and cellular networks, QUIC-based connections may continue working through connection migration, but the result still depends on the client implementation and network environment.
Linux environments vary more widely: desktop clients may work through the system proxy or a virtual network adapter, while command-line programs may need to read environment variables or be handled by a transparent proxy. Containers, subsystems, and remote sessions may also have separate network namespaces, so a working browser on the host does not prove that requests inside a container use the same path.
- ✅ Before importing, confirm that the client supports the protocols and transport methods in the subscription.
- ✅ After importing, refresh the subscription first, then select a node for a basic connection test.
- ✅ Check that the system proxy, virtual network adapter, or network extension is actually enabled.
- ✅ When one app behaves abnormally, confirm whether it uses its own proxy settings.
- ❌ Do not paste a subscription URL containing authentication details into a public testing website.
- ❌ Do not enable conflicting system proxy, virtual network adapter, and browser-extension settings at the same time.
How to read product specifications before choosing a plan
Once the terminology is clear, translate the specifications into your own usage path. First confirm whether the plan uses cycle-based traffic or a non-expiring traffic package, then check supported clients and protocols. Next review the entry and exit locations and route type, and finally read the refund policy, traffic-reset method, and device limits. Do not judge a service only by node names, protocol counts, or a single label on the page.
If your main needs are browsing and light office work, rule quality, DNS handling, and client stability are often more important than peak speed-test results. For extended video playback, focus on sustained throughput, route congestion, and exit availability. If you frequently move between networks, consider client reconnection speed, the UDP environment, and background restrictions on your platform.
“Supports a protocol” on a product page only means that the server and configuration provide the relevant capability; it does not mean every platform client can use it. Likewise, a “node in a region” usually describes an exit or node label, not the entry location or complete route. If the information is unclear, check the node page or help documentation, or ask support what the field means.
- ✅ Whether the plan clearly explains how traffic is measured and reset.
- ✅ Whether compatible clients are available for your usual platforms and whether the required protocols can be imported.
- ✅ Whether the node details distinguish entry, exit, direct, relay, and private-line routes.
- ✅ Whether clear refund, troubleshooting, and subscription-reset instructions are provided.
- ✅ Whether routing rules and DNS settings can be adjusted for your actual use cases.
- ❌ Do not treat the node count as a direct substitute for connection quality or stability.
A focused guide to common questions
Will refreshing a subscription overwrite manual changes?
That depends on how the client manages remote configuration. Some clients regenerate subscription nodes during refresh, restoring directly edited fields to the server-provided values; local policy groups and override rules may be stored separately. Custom settings that need to persist should be added through the client’s supported override, merge, or local-rule features rather than by editing remote nodes directly.
If a node connects but webpages do not open, does that mean the node is broken?
Not necessarily. A connected status only indicates that the client and server may have completed the handshake. Webpages can also fail because of DNS, routing rules, system time, browser proxy settings, destination-site restrictions, or the local network. Test different domains first, then compare global and rule modes and check DNS and system takeover status.
Why does the same subscription behave differently in different clients?
Clients implement protocol details, DNS, rule syntax, virtual network adapters, and system permissions differently. Some subscription-conversion processes may also ignore fields the client does not recognize. For a fair comparison, keep the node, protocol, DNS, and operating mode consistent; otherwise the difference may not be due only to client performance.
Which should be changed first: the route or the protocol?
If a connection cannot be established at all, first check protocol compatibility, authentication parameters, and whether the network supports UDP or TLS. If it connects but speed or latency is unstable, compare different entry points and routes first. If only a specific website is affected, check the exit, DNS, and routing rules. Change one variable at a time to get a reproducible result.