Here’s what common VPN terms mean: a subscription delivers configuration, a node is a connection endpoint, a protocol defines how data is transmitted, and routing determines where requests go. If importing a configuration doesn’t get you online, check each part in turn instead of repeatedly switching nodes.
In everyday use, a “VPN client” may actually run a proxy protocol rather than a traditional device-wide virtual private network. An app’s VPN indicator may simply mean it routes traffic through the system’s virtual network interface. To confirm that a setup is working, check the configuration and request path—not just the status icon.
Terms at a glance: from configuration to exit traffic
| Term | What it means | Common point of confusion |
|---|---|---|
| Subscription link | An address used to retrieve or update nodes or a complete configuration | It is not a billing period and may not include routing rules |
| Node | A set of connection parameters available in the client | A node’s name may not reflect its actual exit location |
| Protocol | The method the client and server use to negotiate and transmit data | A protocol name is not a rating of bandwidth or reliability |
| Route | The path made up of an entry point, intermediate networks, and an exit point | The same region and protocol can still use different routes |
| Routing rule | A rule that selects direct, proxy, or blocked access based on a domain, address, or other condition | Rule mode does not automatically route every international website through a proxy |
| DNS | A mechanism for resolving domain names to network addresses | A webpage connection using a proxy does not mean its DNS queries use one too |
| TUN mode | Captures and processes traffic through a virtual network interface | Coverage still depends on routing, exclusions, and how the client is implemented |
Think of these as parts of a single path: the client reads the subscription to get nodes and rules. When an app sends a request, the rules select how it connects. Requests that need a proxy are sent through the node’s protocol and route to an exit point. DNS helps determine the destination address and may need separate configuration.
Subscriptions and nodes: configuration source vs. network exit
What does a subscription update actually change?
A “service subscription” describes billing, while a “client subscription” describes how configuration is retrieved. They are different things. A client downloads content from a subscription URL, which may provide a node list or a complete configuration with policy groups, DNS, and rules. The exact contents depend on the format the service provides.
After copying the URL, add it through the client’s subscription or configuration import screen, then update and enable the relevant configuration. Pasting the link into a browser does not necessarily import it. Updating also does not enable it: some clients can save multiple configurations, so the old one may still be active.
A node typically includes a server address, port, authentication details, protocol, and transport settings. Changing any one of them manually can cause a mismatch. Region, multiplier, or route labels in a node’s name come from the provider; they are not facts verified by the protocol. To check a node’s region, consult the route details and verify the exit after connecting.
Protocol differences: check compatibility, then network conditions
Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC are different proxy protocols or protocol implementations—not interchangeable labels. The client must support the specific protocol and configuration, and the server must provide matching parameters. Changing a node’s protocol field to a different name won’t make the connection work.
- Shadowsocks: Uses an agreed encryption method and credentials to carry proxy traffic. The client must support the specific encryption method used by the server.
- VMess: Has its own authentication and transport mechanisms. Some implementations require accurate device time, so check the system clock when troubleshooting.
- Trojan: Typically used with TLS. Certificate validation and server name parameters must be correct; disabling validation is not a routine fix.
- VLESS: Does not encrypt data by itself. Security depends on the accompanying security layer and complete configuration, not the protocol name alone.
- Hysteria2 and TUIC: Based on QUIC and rely on UDP. If the current network restricts UDP, handshakes may fail or connections may be unstable.
Keep protocols, transport layers, and routes distinct. WebSocket is a transport method, TLS provides a security layer, and IEPL describes a network transmission path. They are not alternatives at the same layer. A client that supports a protocol may not support every transport combination for it. If an import fails, first check the core version and format requirements.
Bottom line: Beginners should start with a configuration explicitly provided by the service and supported by their client. A newer or older protocol does not automatically mean faster or slower speeds. Real-world performance also depends on the local network, route congestion, server resources, and destination site.
Route types: direct, relayed, and IEPL
A direct connection usually means the device connects straight to an overseas proxy server, without an additional relay entry point arranged by the service provider. It does not mean the connection avoids ISP routing altogether. Performance depends more directly on the local network’s international gateways and interconnection with other networks.
With a relay, the device first connects to an entry point, which forwards traffic to another node or exit. “Relay” only means there is an extra forwarding step; it does not automatically mean a private line is used or that performance will be better than a direct connection. Consider the entry point’s reachability, the route from entry to exit, and congestion.
IEPL is an international Ethernet private line, often used for a specific segment of a route. It describes the network service carrying traffic, not a proxy protocol, and does not mean every segment from your device to the destination website uses a private line. The path from your device to the entry point and from the exit to the destination may use other networks.
When choosing a route, the region name can help you assess the exit location and whether it matches a service’s regional requirements. The nearest region does not necessarily have the smoothest ISP route, and lower latency does not guarantee faster sustained downloads. When reviewing the route list, compare the entry point, exit, route type, and intended use—not just the name.
Routing modes: how global and rule-based routing work
Rule mode usually checks requests against rules in order, then sends them direct, to a proxy policy group, or blocks them. Rules may match domains, destination addresses, processes, or other conditions; the client determines what is supported. Requests that match no rule usually follow a fallback rule. Check the current configuration to see whether that fallback is direct or proxied.
Global mode usually sends requests that have reached the proxy core to a single policy. It does not necessarily capture all traffic from the device. Apps that do not use the system proxy, excluded routes, and traffic the client cannot handle may still take a different path.
A system proxy provides proxy settings to apps, but each app decides whether to follow them. TUN mode captures traffic through a virtual network interface and can cover more traffic, but routes and DNS still need to be configured correctly. Android and iOS clients often use the system VPN interface, while desktop clients commonly offer separate switches for the system proxy and TUN.
For everyday use, start with a trusted rules configuration. If a website behaves unexpectedly, check the connection log to see which rule matched and which policy group was selected. Temporarily switching to global mode can help pinpoint a routing issue. If access returns, investigate the rules rather than assuming the node is always at fault.
DNS leaks and exit checks
A DNS leak usually means domain lookups that were expected to use a particular route were sent through an unintended one—for example, directly to the local network’s resolver. This may expose the domains being queried, but it does not mean HTTPS content has been decrypted.
A local resolver appearing in a test needs to be interpreted in light of your configuration. Using local DNS for direct connections may be intentional; if domains that should be proxied still use local DNS, investigate further. Encrypted DNS in the browser, system DNS settings, and the client’s DNS configuration may all apply independently. Changing one setting does not guarantee they are all aligned.
An exit IP check only reflects the connection used to make that test request. A browser showing a proxy exit does not mean other apps use the same route. DNS tests should also distinguish between regular DNS, browser-specific resolution, and how proxy server domains are resolved. If results conflict, checking the client’s connection log is usually more useful than repeatedly refreshing the test page.
Beginner workflow: import, connect, and troubleshoot
- Check client compatibility. Use the setup guides to confirm your platform and configuration format, then get a compatible client from the client download page in the dashboard.
- Import and enable the subscription. Use the URL in the correct format, confirm the update completes and nodes appear, then check that the newly imported configuration is enabled.
- Choose a node and policy. Select a node in the policy group you actually use. Changing the selected state in the node list alone may not update the policy group.
- Confirm traffic is being captured. Grant the permissions required by your platform, check the system proxy or TUN status, then test with the target app.
- Check the exit and DNS. Use exit checks, DNS tests, and connection logs to confirm the actual route. Don’t rely on the status icon alone.
- Troubleshoot one step at a time. If import fails, check the format and URL. If the connection fails, check the network, authentication, and protocol. If only some websites have issues, check the rules, DNS, and the site’s own restrictions.
- ✅ When asking for help, include the client name, operating system, error message, and step where the issue occurs.
- ✅ Keep a copy of the original configuration before making changes. Adjust one relevant setting at a time so you can compare results.
- ❌ Don’t share subscription tokens, complete node credentials, or unredacted configuration screenshots in public posts.
Here’s a concise troubleshooting order: Was the configuration retrieved? Can the node connect? Did the request reach the client? Where did the rules send it? Following these steps usually makes issues easier to isolate than enabling several proxy tools at once. For further help, submit redacted details through a support ticket in the dashboard.