When people say “VPN,” they often mean a proxy subscription service. Start by distinguishing the source of a configuration, the connection endpoint, and how traffic is routed. A subscription delivers configuration to a client; a node is a connection option; a route describes the network path; a protocol defines how data is exchanged; and routing rules determine which requests use a proxy. These concepts are related, but they are not interchangeable.
In everyday use, “VPN” is also a catch-all term for proxy subscription services. Technically, a system VPN tunnel and an application-layer proxy are different things. Whether a client handles all device traffic depends on system permissions, its operating mode, and whether apps respect proxy settings—not just the connection icon.
Subscriptions, nodes, and clients: what each one does
A subscription link is an address used to retrieve configuration. When a client accesses it, it typically receives a list of nodes; some formats also include policy groups, routing rules, and DNS settings. It is not a streaming service membership, nor does importing it establish a connection. After importing, you still need to choose a policy, start the connection, and check that requests are routed as expected.
A node is a connection profile in a client, usually containing a server address, port, authentication details, and protocol settings. The region in a node’s name typically describes its exit location, but the name is a label supplied by the provider—not proof of the server’s physical location. Multiple names may share an entry point or exit, or use different paths. The number of nodes does not tell you how many separate physical servers there are.
The client reads the configuration and handles the connection. A subscription service provides access; a client provides the interface and network-handling features. They are not the same thing. The same service may offer different subscription formats for different clients. Pasting a link into incompatible software can cause errors or leave some settings unapplied.
| Term | What it means | What it does not tell you |
|---|---|---|
| Subscription link | An address that provides configuration to a client | That all apps are routed through the client after import |
| Node | A connection option with an address and authentication settings | That each name represents a separate physical server |
| Route | The network path traffic takes from entry point to exit | That two routes with the same name perform identically |
| Protocol | The rules that govern communication between client and server | That a newer protocol will be faster on every network |
| Routing rule | A rule that directs requests to a direct connection, proxy, or other policy | That selecting a regional node automatically changes the route for every request |
Direct, relayed, and IEPL routes: what’s the difference?
In the context of service routes, “direct” usually means the local network connects to an overseas entry server without an additional relay operated by the service. The path is simpler, but performance still depends on the local carrier, international gateways, the destination network, and time of day. “Direct” does not necessarily mean low latency or an unencrypted connection.
A relay adds a forwarding step between the client and an overseas exit. The client connects to the relay entry point, which then forwards traffic to another server. This may improve reachability or reduce congestion on part of the route, but it also adds a network hop. A nearby entry point does not guarantee a fast end-to-end connection, and a client’s latency test may not cover the full path to the website you visit.
IEPL is an international Ethernet private line service provided by a carrier. In a subscription service, this usually means that some cross-region backbone segments use this type of connection—not that every link from your device to the destination website is a private line. Your home broadband, access node, and the connection from the exit to a content platform can still affect performance.
“Direct” can mean two different things here. In a route description, it refers to the service’s access path. In routing rules, it usually means a request bypasses the proxy and goes directly over your local network. Check which settings page uses the term.
When checking a streaming library for a particular region, verify the exit region and how the platform identifies it. An IEPL label cannot guarantee access to a specific library. Platforms may also consider account region, licensing, and proxy detection. Choose a route based on access to the app you need, not just its label.
Common protocols: check compatibility first
Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC are all used in proxy clients, but their names are not interchangeable. The client must support the protocol and settings used by the server. Changing the protocol option in the interface will not convert an existing server to a different protocol.
- Shadowsocks: An encrypted proxy protocol. The client and server need matching passwords, encryption methods, and any relevant extension settings. A client merely listing support for the protocol may not be enough.
- VMess: A proxy protocol with authentication and encryption mechanisms that can use different transport methods. The transport settings must also match the server.
- Trojan: Typically carries proxy traffic over TLS. Certificate, server name, and verification settings all matter for a valid connection. Disabling certificate verification is not a good way to fix errors.
- VLESS: A lightweight proxy protocol that does not provide transport encryption by itself. It is commonly deployed with a security layer such as TLS or REALITY. The VLESS label alone does not reveal how the connection is protected.
- Hysteria2 and TUIC: QUIC-based proxy protocols that depend on UDP network conditions. If UDP is restricted or the route is unsuitable, they may not work as well as TCP-based options.
Protocol names do not provide a reliable speed ranking. Implementation versions, packet loss, congestion control, server load, and network paths can all affect results. For a more useful comparison, first make sure the recommended client imports the configuration correctly, then test the apps you care about on the same network and at similar times.
Rules, global mode, and TUN: where your traffic goes
Rule mode applies policies based on conditions such as domains, destination addresses, or processes; the available conditions depend on the client. A common setup sends local services direct and routes selected services through a proxy. Rules are often evaluated in order, so an earlier match may override a later one. Seeing a domain somewhere in the rule list does not guarantee that the intended rule applies.
Global mode usually sends requests handled by the client through a single proxy policy. It can be useful for briefly troubleshooting rules, but it does not guarantee that all device traffic goes through the proxy. Apps that ignore system proxy settings, UDP traffic the client does not handle, and separate network environments may still bypass it.
TUN mode uses a virtual network interface to capture traffic, often covering apps that do not follow system proxy settings. It is not mutually exclusive with rule mode: TUN can capture traffic first, then rules determine whether it connects directly or through a proxy. After enabling it, check routing, DNS, and permissions. It may also conflict with other tunneling software.
When setting things up for the first time, start with the rule configuration recommended in the service documentation. If only one app cannot connect, check whether the client handles its traffic. Avoid sending all requests through one exit long-term to fix a single app; local sites, workplace resources, or payment pages may be affected too.
Importing a subscription link: a client-by-client checklist
- Get the client from a trusted source. Follow the quick start guide to choose a client for your operating system, then find the relevant instructions on the user dashboard download page. A modified client from an unknown source should not be a required step.
- Copy the subscription link in the right format. In the client, choose an option such as import from URL or add subscription. Don’t paste the full link into a single-node server address field. The option may be named differently in different apps.
- Update the configuration and check the result. Make sure the node list loads and read any error messages. A web page returned instead of configuration, expired credentials, or an incompatible format can all cause an import to fail. Switching nodes repeatedly will not fix a configuration parsing error.
- Choose a policy and start the connection. Enable the system proxy or tunnel permissions recommended for your setup. If you select a node but do not enable network handling, your browser may still use its original connection.
- Test with the app you need. First check the exit shown on the IP check page, then open the service you intend to use. A changed IP is only one part of the check; it does not prove that every app and DNS request is being handled as expected.
Desktop clients may control the system proxy and TUN separately. Mobile clients typically use the system’s VPN interface to handle connections, but can still apply routing rules. On Linux, check whether command-line programs read proxy environment variables and whether desktop proxy settings apply to the app in question. Similar-looking interfaces across platforms do not mean they capture the same traffic.
Updating a subscription usually fetches the configuration again; it does not renew the service. Whether local changes are overwritten depends on the client. If you need custom rules, use the client’s supported override or separate rule features where possible to avoid losing changes during an update.
DNS leaks and connection failures: troubleshoot by symptom
DNS translates domain names into addresses. A DNS leak usually means a query that should have followed the tunnel’s routing policy instead went to an unexpected resolver or took an unexpected path. This may expose the domain being looked up, but it does not mean the contents of an HTTPS page were read directly.
A browser’s encrypted DNS, the system resolver, and the client’s DNS settings may all operate independently. Encrypted DNS protects queries in transit; it does not automatically ensure they go through a proxy. A different resolver region shown on a test page does not by itself prove a leak. Distributed public resolvers and inaccuracies in geolocation databases can affect what the page displays.
- ✅ Subscription won’t update: Check whether the error points to a network timeout, authentication failure, or incompatible format. Make sure the link is complete, then consult the service documentation.
- ✅ A node connects, but web pages won’t load: Check DNS, system proxy settings, and policy groups. Look for requests to the destination in the client log.
- ✅ The browser works, but an app doesn’t: Check whether the app follows system proxy settings. If needed, consult the documentation before trying TUN mode; don’t assume the node is down.
- ✅ Only one website has a problem: Check rule matching, account region, and platform restrictions instead of relying only on the client’s latency display.
- ❌ Don’t post your subscription link or full configuration on public testing sites. Hide authentication details in screenshots shared for support. If credentials are exposed, reset them using the service’s supported process.
Change one type of setting at a time and keep a copy of the original configuration. You can briefly compare rule and global modes while troubleshooting, but restore the appropriate policy afterward. If you contact support, include your system, client, network environment, and the specific error. Review logs and remove sensitive fields before sharing them.