How these terms fit together
Start with how the connection works. Your plan determines which services are available; a subscription delivers configuration details for available nodes to your client; a node is the connection endpoint you choose; a protocol defines how the client and server communicate; and routing rules determine which requests use that connection. These are separate parts, not a single switch. If changing nodes doesn’t fix access to a website, the cause may be a rule, DNS, or a client setting.
In everyday conversation, “VPN” is often used as a catch-all for tools that provide cross-border access. But clients don’t all use the same connection technology: some create system-wide tunnels, while others use proxy protocols to handle selected traffic. Knowing which client and mode you’re using is more useful than memorizing technical names. Use the table below as a reference when reviewing your settings.
| Term | What it tells you | What to do first |
|---|---|---|
| Subscription | Where does the client get its configuration? | Copy the link from your service dashboard and import it. |
| Node | Which connection endpoint should I choose? | Choose based on the service you need and the exit region. |
| Protocol | How does the client communicate with the server? | Start with a compatible configuration provided by your subscription. |
| Traffic routing | Which requests use the selected route? | Check the rules and DNS behavior for your use case. |
This sequence also helps with troubleshooting: first confirm the configuration has been added to the client, then check that the node connects, and finally verify that the rules send the intended traffic through the expected exit. Repeatedly switching nodes based only on their names can distract from the setting that’s actually affecting your route.
A subscription link isn’t a plan
“Subscription” can mean a billing period, as in a monthly subscription, or a way to import configuration into a client, as in “add subscription.” In the latter case, it’s usually a link from your service dashboard that the client reads to display available nodes and related settings. The terms look alike but serve different purposes: choosing a plan doesn’t automatically put its configuration in a client, and importing a link doesn’t mean you can ignore the plan’s usage rules.
To get started, find the subscription link for your client in the service dashboard and copy it. In the client, choose “Import from URL” or a similarly named option, paste the link, and refresh. Menus vary across platforms: some clients require you to add a profile first, while others list subscriptions separately from individual nodes. Once the import succeeds, you should see a node list. Choose a node and connect.
If the list is empty, don’t assume the entire route is unavailable. First check that you copied the complete link and chose an import method supported by your client, then try refreshing the subscription manually. If the client reports an incompatible format, check the service’s client-specific instructions rather than modifying the link to use another protocol.
Nodes, regions, and connection types
A node is a selectable connection configuration in your client, often named for a region or use case. The region usually indicates the apparent location of the service’s exit, but a node’s name doesn’t guarantee that a website will identify you as being in that region. Sites may also use account settings, cached data, or other location signals. For region-restricted content, check the service’s own rules, choose a suitable exit, and verify the result after connecting.
Connection type describes how traffic reaches the exit, not a speed tier. A direct connection typically means the client connects straight to a remote endpoint; a relay routes traffic through a forwarding endpoint provided by the service; and IEPL refers to a specific private-line transport option. Even with the same label, performance depends on your local network, congestion, exit load, and the destination service. “Private line” alone doesn’t mean it will always be faster, and a region shown in the node list isn’t a map of the full end-to-end route.
Choose based on what you need. For everyday browsing, start with a region where the service you need is accessible and the connection is stable. For work, consider video calls, file uploads, and your company’s network policies. For streaming, judge by playback on the platform itself. If a node already works for your needs, there’s no reason to switch just because another name looks more appealing. Frequent changes to your exit may also trigger extra sign-in checks.
Protocols must match your client
A protocol defines how two sides exchange data. Common names include Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC. They aren’t interchangeable “speed settings”: each has its own configuration fields, transport methods, and client support. VLESS can also use different transport and security settings, so seeing VLESS on a node isn’t enough to reconstruct the full connection configuration by hand.
Hysteria2 and TUIC commonly use QUIC-based transport, and how a network handles that traffic can affect connection performance. That doesn’t mean they’re necessarily faster than other protocols. You also can’t judge the privacy characteristics of Shadowsocks, VMess, or Trojan by name alone; the specific configuration, client behavior, and encryption used by the destination all matter. A reliable starting point for beginners is the complete subscription configuration provided by the service—not manually changing ports or transport settings when an unfamiliar protocol appears.
Client support matters too. The apps, system permissions, and settings available on Windows, macOS, Android, and iOS aren’t identical. Even when each app has a “Connect” button, system proxy settings, virtual network interfaces, and traffic-routing capabilities may differ. A subscription importing successfully on one platform doesn’t mean a feature with the same name covers exactly the same traffic on another. If it imports but won’t connect, first check that your client version supports the configuration format, then review the specific error message.
Traffic routing, global mode, and rule-based mode
Traffic routing determines where requests go: traffic matching a rule uses the selected route, while other traffic uses the local network or another route. Rules may match by domain, address, app, or network category, depending on the client. Rule-based mode can suit situations where you need both international websites and local services to work as expected. But rules aren’t always accurate; if a website adopts a new domain, older rules may miss related requests.
Global mode generally means the client routes as much of the traffic it can take over as possible through the selected route. It doesn’t guarantee that every process or connection on your device will use it. Browser extensions, system proxies, and virtual network interfaces cover different traffic, and some apps may not follow the system proxy. To understand the route, check what “global” means in your particular client rather than relying on the mode name alone.
DNS translates domain names into addresses that devices can connect to. If a website’s traffic uses a route but its DNS queries are handled by your local network, DNS may not follow the expected path. This can affect privacy assessments and cause a mismatch between rule matching and actual access. If a site works intermittently in rule-based mode, check the client’s DNS settings, which rules are being matched, and your browser’s secure DNS settings—not just the node. Don’t assume DNS automatically follows the same route when you connect.
Beginner connection and troubleshooting steps
You don’t need to learn every protocol and advanced rule before your first setup. Focus on one goal—getting a specific website to use the expected route—and verify each step as you go. If something goes wrong, you’ll know which part changed.
- ✅ Get the subscription for your client from the service dashboard, import it, refresh the list, and confirm that the nodes appear.
- ✅ Choose an exit region and node for your destination service. Start with the client’s standard connection settings; don’t change protocol parameters in the subscription at random.
- ✅ After connecting, visit the destination website and check whether it opens, lets you sign in, or plays content as needed.
- ✅ If the website isn’t available, first check whether the client shows a successful connection, then verify that the routing rules send the site along the expected route.
- ✅ If the connection appears normal but domain access is failing, check the DNS settings. If needed, try another node suited to your use case and test again.
A common false alarm: a webpage opens, but a feature in the app still doesn’t work. The app may contact different domains or use a different connection method than the website. Note the app, action, and error message—that’s more helpful for troubleshooting than simply saying “the node is down.” To learn more about choosing nodes, see the nodes page. For setup and import instructions by device, start with the guides.