When you first use a VPN, the hardest part is often not the buttons but the terminology: subscriptions, nodes, routes, protocols and routing rules. They may appear together in the same client, yet describe different parts of the process—where configuration comes from, how you connect, which path traffic takes, how data is transported and how requests are handled. Once these roles are separated, importing a subscription, switching nodes and troubleshooting disconnections become much easier.
One distinction is worth making first: in everyday conversation, “VPN” is often used as a catch-all term for encrypted tunnels and proxy tools. More precisely, Shadowsocks, VMess, Trojan, VLESS, Hysteria2 and TUIC are proxy protocols or transport schemes. A client may use the operating system’s VPN or TUN interface to take over device traffic, but that does not make every protocol a traditional enterprise VPN. Keeping these concepts separate prevents confusion between a client’s operating mode and a node’s protocol.
Separate the service, client and subscription first
The service is not the client
The service includes delivered configuration, route resources, traffic rules and account management, while the client is software installed on a computer, tablet or other device. The client usually does not come with usable routes by itself—just as an email app does not provide an inbox. You must import the service’s configuration into a compatible client before it knows the server address, port, protocol and authentication details.
The same service configuration may work with multiple clients, but compatibility does not mean identical functionality. One client may support rule-based routing and TUN while another offers only a system proxy; one may update subscriptions automatically while another requires a manual refresh. If a tutorial looks different from your screen, first check the client name, platform and version instead of relying on button colors to find the right control.
A subscription link is an updateable configuration entry point
A subscription link is usually a web address tied to your account. When the client accesses it, it retrieves node names, server endpoints, protocol parameters and group rules. It is not an ordinary webpage or a download page that must be opened in a browser. If opening it in a browser shows encoded text, a downloaded file or a blank page, that does not necessarily mean the link is broken. The usual approach is to paste the complete link into the client’s “Subscription,” “Configuration File” or “Remote Configuration” section.
Subscription links often contain a token that identifies your account, so treat them as sensitive configuration. Do not reveal the full link in public screenshots or paste it into an unfamiliar conversion website. Anyone who obtains a valid subscription may be able to read its node information, and could continue receiving updates when the service changes its nodes.
“Import subscription” and “Update subscription” are two different actions. Importing tells the client to remember the configuration source for the first time; updating makes the client revisit the original address and sync the latest server-side content locally. If nodes are renamed, endpoints are migrated or rules change, switching between old nodes may not help—update the subscription first. Some clients overwrite local edits inside the subscription when updating, so custom rules that need to persist should go in the client’s override or local-rules section.
- ✅ Make sure you copied the complete subscription address, with no missing characters at the beginning, end or middle.
- ✅ Import it through the client’s subscription or remote-configuration section; do not mistake encoded content for an error page.
- ✅ Run an update after importing, then check whether the node list appears.
- ✅ Before saving custom rules, confirm whether subscription updates will overwrite local changes.
- ❌ Do not publish the subscription link or submit it to an online conversion tool from an unknown source.
What is the difference between a node, server and route?
A node is an access configuration that you can select in the client. It usually contains a server address, access port, protocol, authentication details and transport parameters. Names such as “Tokyo,” “Los Angeles” or “Singapore” are generally labels for identification; they do not necessarily mean the data center, exit address and entire network path are all in the same place.
A server is the software and computing resources that actually handle a connection. One server can host multiple node configurations, and a node may first connect to a relay server before reaching a target website through an exit elsewhere. In short, a node is closer to the configuration entry shown by the client, while a server is closer to the underlying resources running in the background.
A route describes the approximate path and traffic-engineering method between your device and the exit. Route quality depends on more than geographic distance; carrier interconnection, detours, evening congestion, entry load and the target website’s network conditions all matter. A nearby node is often worth trying first, but you cannot judge performance from the country or region name alone.
| Term | What it actually describes | How it usually appears in the client | What to check first when something goes wrong |
|---|---|---|---|
| Node | A selectable access configuration | A single option in the node list | Whether the configuration has expired and the protocol is supported |
| Server | The software and resources handling access, forwarding or the exit | The backend structure is usually not shown in full | Whether a connection can be established and the service responds |
| Route | The network path between the local device, entry, relay and exit | Labels such as direct, relay or dedicated route | Congestion, detours and carrier interconnection |
| Exit address | The public source address ultimately seen by the target website | Check it through a network test after connecting | Whether the region is appropriate and the exit is still local |
Direct, relay and IEPL dedicated routes
A direct route generally means the device connects straight to an international entry point, without an additional relay deployed by the service. Its structure is simple, and the path is shaped mainly by the local carrier and international Internet routing. It can work very well when interconnection is smooth, but congestion or routing detours may produce more noticeable fluctuations.
A relay route generally means the device first connects to a nearby or well-connected entry point, then uses a carrier path controlled by the service to forward traffic to the exit. The value of a relay is the ability to choose a different cross-network path; it does not automatically mean higher speed. An unsuitable entry point, forwarding capacity or exit load can offset the benefit.
IEPL originally referred to an international Ethernet private-line connection provided by a carrier, emphasizing a relatively independent and manageable cross-border transport path. In product labels, “IEPL” may describe only part of the route; the user may still connect through a shared entry point or the public Internet. When comparing options, check how the service defines the entry, relay and exit instead of judging the entire path from the node name alone.
What common proxy protocols are responsible for
A protocol defines how the client and server authenticate, encrypt, encapsulate and transport data. A subscription only passes protocol parameters to the client; it does not automatically convert one protocol into another. If the client does not support the protocol used by a node, the node may fail to import, appear without required fields or fail immediately when you try to connect.
| Protocol | Key characteristics | Configuration details to check | Common use cases |
|---|---|---|---|
| Shadowsocks | A relatively simple encrypted proxy protocol | The encryption method, password, server and port must match | Broad client support; suitable for standard proxy forwarding |
| VMess | An earlier authentication protocol used in the V2Ray ecosystem | The identity, transport layer and clock synchronization can affect connectivity | Still found in existing configurations and compatibility environments |
| VLESS | A lightweight authentication and transport design, often combined with different transport layers | Flow control, security layer, domain and transport parameters must match | Suitable for configurations that need flexible transport combinations |
| Trojan | Typically establishes an encrypted connection over TLS | The domain, certificate validation, password and server name must be correct | Suitable for servers and clients with complete TLS configuration |
| Hysteria2 | Built on QUIC and UDP, with a focus on transport over high-latency or lossy links | UDP reachability, certificates and bandwidth parameters can affect performance | Suitable for networks with good UDP conditions and full client support |
| TUIC | Also uses QUIC and UDP for multiplexed transport | Authentication, congestion control, certificates and client versions must match | Suitable for environments that support the protocol and allow UDP traffic |
The protocol name alone cannot determine final speed. When a route is congested, changing the encapsulation may not solve a capacity problem; if the local network restricts UDP, QUIC-based options may fail while TCP- or TLS-based configurations still work. Conversely, on links with obvious latency or packet loss, a well-designed QUIC option may recover more smoothly. Confirm network conditions first, then compare different protocols at the same time and near the same exit.
TLS does not mean that a connection has already succeeded. With Trojan or TLS-enabled VLESS configurations, the client must validate the certificate and server name. A badly incorrect device clock, mismatched domain, expired certificate or disabled required validation can all cause a handshake failure. When you see a certificate error, correct the configuration or update the subscription rather than treating disabled verification as a long-term fix.
How to choose between global mode, rule-based mode and direct mode
The “mode” in a client determines where traffic goes; it is not a protocol switch. Global mode generally sends all traffic taken over by the client through the proxy node. Rule-based mode checks the domain, address, app or network type, then chooses proxy, direct or block. Direct mode bypasses the proxy and is useful for temporary troubleshooting or pausing proxying.
Global mode is useful for testing, but not always for daily use
Global mode has the simplest rule chain and is useful for checking whether a node works after importing a configuration. If a target website works globally but fails in rule-based mode, the problem is probably not the node itself but rule matching, DNS results or the scope of traffic captured by the client. Keeping global mode enabled indefinitely may also send local websites, LAN devices and downloads that do not need a proxy through a remote exit, creating detours and worsening the experience.
Rule-based mode depends on matching order
Rules usually start with more specific conditions, such as an app, domain suffix or address range, and finish with a fallback rule for unmatched requests. If the same domain matches multiple conditions, the client generally uses the first match. Placing a broad rule first can prevent later, more precise rules from ever taking effect.
“Proxy” in a rule does not necessarily point directly to one fixed node; it may point to a policy group. The policy group then selects a node based on manual choice, connectivity checks or logic supplied by the service. A rule that says proxy therefore does not prove that traffic has exited through the expected region. Check the policy group’s current selection and the actual exit address.
System proxy and TUN cover different traffic scopes
A system proxy writes the proxy address into the operating system settings, and apps that follow those settings send traffic through the client. Some games, command-line programs, standalone network components and apps with their own connection stacks may ignore the system proxy. TUN creates a virtual network interface and captures IP traffic at a lower level, usually covering more apps but also making conflicts with security software, other VPNs, virtual machines or enterprise network policies more likely.
- ✅ When testing a node for the first time, start with global mode and confirm that the basic connection and exit are working.
- ✅ If global mode works but rule-based mode does not, check domain rules, policy groups and DNS settings.
- ✅ If the browser works but command-line tools or standalone apps fail, check whether those programs follow the system proxy.
- ✅ Consider TUN only when you need broader app coverage, and check whether other network tools are also capturing traffic.
- ❌ Do not enable multiple clients that can capture traffic at the same time, or their routes and DNS settings may overwrite one another.
What do DNS leaks, exit addresses and WebRTC mean?
DNS translates domain names into network addresses. After connecting through a proxy, a DNS leak generally means that domain lookups are still handled directly by a resolver provided by the local network, even though you expected them to use an encrypted tunnel or a specified remote resolver. This may not immediately stop webpages from loading, but it can reveal which domains were accessed or return addresses that do not match the proxy exit, leading to routing or region-related problems.
“DNS through the proxy” and “web traffic through the proxy” are separate settings. Some clients resolve locally and then route traffic based on the result; others use domain rules to determine the path and send queries to different resolvers; some provide virtual address mapping so domain rules remain usable before a connection is established. Implementations vary by client, so do not blindly copy an entire DNS configuration without understanding its mapping method.
The exit address is the public source address seen by a website. After a successful connection, if the exit still shows an address from the local network, the current app may not be captured, the rules may have selected direct access, or the client may only have configured a system proxy that the app ignores. If the exit has changed but the DNS location still looks wrong, inspect DNS routing separately instead of continuing to switch nodes.
WebRTC is a set of technologies used by browsers and real-time communication apps. In some environments, it may expose candidate network addresses that differ from those used by ordinary page requests. Modern browsers, operating systems and network layouts handle this differently, so seeing a private network address on a test page alone does not prove that proxying has failed. Focus on whether public candidates bypass the expected exit and whether the browser follows the current proxy or TUN route.
Why do clients behave differently across platforms?
Windows and macOS clients can often provide both a system proxy and TUN, but they handle virtual network components, system permissions and route conflicts differently. Desktop browsers usually read the system proxy, while command-line tools may require separate environment variables or their own proxy settings. A failure in the terminal does not by itself mean that the node used by the browser is broken.
Android clients usually capture traffic through the system VPNService. Common features include per-app proxying, LAN bypass and choosing proxy or direct access by app. Battery-saving policies may restrict background operation; if the client disconnects repeatedly after the screen locks, check background restrictions and battery optimization instead of repeatedly changing protocols. Also read the per-app list carefully: in some clients, it means only selected apps use the proxy; in others, selected apps bypass it.
iOS clients rely on the network-extension capabilities provided by the system. After importing a subscription, the first connection usually requires permission to add a VPN configuration. Support for rule sets, scripts, protocols and per-app controls varies considerably between clients, so desktop options such as TUN, system proxy or complex overrides may not be available on iOS in the same form. If a configuration is incompatible, use a format explicitly supported by the service instead of forcing changes to unknown fields.
Browser extensions handle only requests that can be proxied inside that browser; they do not automatically capture other apps, system updates or command-line programs. A router client can cover multiple devices connected to the network, but the router carries the rules, DNS and hardware workload, making troubleshooting more difficult. Beginners should first verify the subscription, nodes and rules on one device before moving the setup to a router.
| Platform or method | Common capture method | Easy-to-miss issues |
|---|---|---|
| Windows | System proxy or TUN | Command-line programs may not read the system proxy, and virtual network components may conflict |
| macOS | System proxy or network extension | System permissions, proxy bypass lists and other network tools can affect routing |
| Android | System VPNService | Background restrictions, per-app list direction and battery-saving policies |
| iOS | System network extension | Protocol compatibility, configuration authorization and differences in client features |
| Browser extension | Handles requests inside the browser only | Other apps do not use the proxy automatically with the browser |
| Router | Centralized routing at the network gateway | Rules, DNS, performance and faults can affect downstream devices |
The complete order from importing a subscription to testing the connection
A common beginner mistake is changing the node, protocol, DNS, TUN and rules all at once, then losing track of which change helped. A more reliable approach is to verify each layer in a fixed order, changing only one variable at a time. The workflow below applies to most clients that support remote subscriptions; exact button names depend on the client you use.
- Confirm client compatibility. Check the platform, client name and protocols supported by the service first. A subscription importing successfully does not mean the current client can correctly recognize every node in it.
- Import the complete subscription link. Paste the link into the subscription or remote-configuration section, give the configuration an easy-to-recognize name, then run an update.
- Review the update result. Confirm that the client reports no authentication, format or network error, and check whether the node list appears. If it is empty, fix the subscription before moving on to speed tests.
- Choose a recommended node. Prefer a node the service clearly marks as commonly used or well connected to your current network. Do not try to guess the fastest route from its name at the outset.
- Test with global mode. After connecting, visit a network-testing page to confirm that the public exit has changed, then test the target website or app.
- Switch back to rule-based mode. If global mode works, enable rule-based mode and check your usual websites. Local services should connect directly and international services should use the proxy; the actual path is determined by the rules and policy group.
- Adjust DNS or TUN last. Change these options only when there is a clear symptom, such as an unexpected DNS location or an app that does not follow the system proxy.
Diagnose by symptoms, not by randomly changing settings
- ✅ Subscription will not update: check the link, client clock, authorization status and current network.
- ✅ Node fails immediately: check protocol support, authentication parameters, TLS validation and UDP conditions.
- ✅ Browser works but other apps fail: check the system proxy’s coverage, the app’s own proxy settings and TUN.
- ✅ Global mode works but rules fail: check rule order, policy-group selection and DNS results.
- ✅ Connection drops after some time: watch for local network changes, background restrictions and connection keep-alive behavior.
- ❌ Do not change every switch at once, or reproducing the issue and identifying the real cause will be difficult.