VPN Beginner’s Guide: Subscriptions, Nodes, Routes, Protocols & Traffic Rules

Understanding the relationship between subscriptions, nodes, and routes

One of the most common points of confusion for VPN beginners is the difference between having a subscription and being connected to a route. Think of a subscription link as an updatable list of routes: the client reads the list and displays the available nodes. Once you select a node and connect, some or all of your device’s network requests may be sent through that connection. A subscription provides configuration; it is not the connection itself. Copying a link without importing it into a client, or importing it without starting the connection, does not mean you’re connected.

A node is usually a selectable connection entry in a client. Its name may include a region, purpose, or route type. A route describes the path traffic takes from your location to its exit point and how that path is arranged. A node may involve an entry point, a transit path, and an exit point, so its name alone doesn’t reveal the actual route. Different routes may also be available in the same region. When you visit a website, the exit location it sees is particularly important—and may differ from the location of the entry point you connected to.

Remember the sequence: The subscription provides the configuration, the client displays the nodes, a node connects to a specific route, and traffic rules determine which requests use that route. When something goes wrong, checking these steps in order is more useful than randomly switching between node names.

Subscription links may contain access credentials, so treat them like account credentials: import them only into a trusted client, don’t post them publicly, and don’t share error screenshots that show the full link with people who don’t need it. “Update subscription” in a client fetches the list again; it doesn’t switch the active node. If the available nodes change after an update, check whether your selected node is still there.

How IEPL dedicated lines, transit, and direct connections differ

A direct connection generally means your device connects straight to a remote entry point, without a separate transit entry point closer to you. With transit, your device first connects to a nearby entry point, and the service provider arranges the onward route to the exit point. IEPL describes a type of international Ethernet private-line transport: it concerns network resources along the route, not an encryption protocol you can select from a client’s protocol menu. An “IEPL dedicated-line node” still needs a client-supported protocol and configuration to connect.

These terms aren’t a speed ranking. Your experience also depends on your local network, congestion at the entry point, the distance between the exit point and the destination website, the website’s own status, and your device. A route that works well for browsing won’t necessarily perform the same on every streaming platform. And being able to open a platform doesn’t mean all of its content is available in that region. To choose a region for a particular purpose, start with the global server locations page, then test the sites you actually use.

When reading node names: “Japan,” “transit,” and “IEPL” may refer to the exit region, route type, and transport resources, respectively. They answer different questions. If the provider hasn’t specified the entry and exit points, don’t assume a node label describes the complete physical route.

What common protocols do

A protocol is an agreed method of communication between a client and a server—not the country where a node is located or the name of a plan. Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC may appear in a client’s supported-protocol list. But support for a protocol name alone doesn’t guarantee that every configuration will work: the versions, transport settings, authentication details, and server implementation must match. Beginners should start with the configuration included in their subscription rather than assembling parameters based on a protocol’s name.

Protocol	What it does	What to check when importing
Shadowsocks	Uses an agreed encryption method and authentication details to carry proxy traffic.	The encryption method and other parameters must match on the client and server.
VMess	A proxy protocol; the connection also depends on the configured transport.	Don’t infer transport and authentication settings from the protocol name alone.
Trojan	Typically establishes a connection with TLS.	TLS settings, including certificate verification and server name, must match.
VLESS	The protocol itself doesn’t provide encryption; security depends on the transport layer used with it.	Don’t treat the VLESS name alone as an encryption guarantee.
Hysteria2、TUIC	Uses a UDP-based transport.	The connection may be affected if your current network restricts UDP.

Protocols and routes can also be combined. A node labeled “transit” might use one of the protocols in the table to connect to its entry point; how traffic travels over the cross-border leg is a separate question. When troubleshooting, distinguish between “Can the client connect to the entry point?” and “Can I access the destination website after connecting?” If only nodes using a particular protocol fail, first check whether the client supports the configuration, then check your current network. There’s no need to assume the entire subscription is unusable.

Choosing between split tunneling, global, and rule-based modes

Global mode generally routes all traffic handled by the client through the selected connection. Rule-based mode first checks conditions such as domains, addresses, or apps, then chooses a proxy, a direct connection, or another specified route. “Global” doesn’t necessarily mean every kind of traffic on your device is handled: browser extensions, system proxies, and virtual network interfaces cover different traffic, and client settings can change the outcome. Check how the client handles traffic before deciding what a mode setting will do.

Rule-based mode works well when you want local services to connect directly and international websites to use a route as needed, but rules aren’t always accurate. A website may use different domains to load images, handle sign-in, or play content. The main page may use a proxy while related requests follow a different rule. If a page opens but you can’t sign in, note where the failure occurs, then briefly try global mode for comparison. If global mode works but rule-based mode doesn’t, check the traffic rules first instead of repeatedly reinstalling the client.

DNS translates domain names into addresses. If a request should go through your selected route but DNS queries are sent over an unexpected network path, you may see a DNS leak or get results that don’t match the destination region. Don’t check only the exit address shown by a website: review the client’s DNS settings too, and compare DNS results with actual browsing behavior on the network test page. Its results reflect your current environment and don’t replace checking every app individually.

Don’t treat the mode as a security switch: Global and rule-based modes mainly change how traffic is routed. They won’t automatically fix your browser account’s region, a website’s own restrictions, or separate proxy settings in other apps on your device. After changing modes, reopen the destination page and test again.

From importing a subscription to testing your connection

Once you have the subscription link provided by your service, follow these steps. Button names may differ between clients, but the basic process is the same: import the configuration, select a node, start the connection, and verify that your traffic takes the expected route. For your first connection, choose a region that suits your needs without changing protocols, DNS, and traffic rules all at once. That way, if something goes wrong, you’ll know which step caused the change.

Check the client’s source and compatibility. Get the client for your platform from the service’s download page and check that it supports the protocol used by your subscription. Don’t mistake a subscription link for a webpage to open in your browser.
Import and update your subscription. In the client, find the option to add a subscription or import from a link. Paste the complete link and wait for the node list to load. If the list is empty, check that the link was copied in full, is still valid, and can be reached over your network.
Select a node and connect. Choose a node in the region needed for your destination website, then check that the client clearly shows it’s connected. Selecting a node name alone doesn’t mean your device’s traffic is being routed through the client.
Verify the route in use. Open a network test page to check your exit information, then visit the website you actually want to use. If the exit location looks right but the site still reports a region restriction, check your account, the region where the content is licensed, and your browser cache. Don’t rely on the connection icon alone.

Windows and macOS clients may offer different traffic-handling options, such as a system proxy or virtual network interface. Android’s background battery management can affect persistent connections, while iOS requires system permission to enable a VPN configuration. Being able to import the same subscription on different platforms doesn’t mean the buttons, per-app settings, or background behavior will be identical. If a platform lacks a particular feature, check that client’s documentation rather than copying a screenshot from another device. For step-by-step instructions, see the beginner’s guide.

Troubleshooting by symptom

Before troubleshooting, distinguish between “subscription won’t update,” “node won’t connect,” and “connected, but websites aren’t working.” These issues happen at different stages and need different fixes. Change one setting at a time and note the result before and after. If you change the node, protocol, and traffic mode all at once, you won’t know which change fixed the issue.

✅ Node list won’t load: Check that the subscription link is complete and accessible, and confirm that the client supports the subscription format. Don’t post access credentials in a public support thread.
✅ Can’t connect to any node: Make sure your device is online, then try another compatible route in the subscription. If your current network restricts UDP, compare with a non-UDP option. Check the specific error shown by the client instead of relying on the loading indicator.
✅ Connected, but websites won’t open: Check your exit location with a network test, then compare the results in global and rule-based modes. Also check DNS, whether the destination website is down, and any existing proxy settings in your browser.
✅ Connection drops repeatedly after the device sleeps: Check your device’s battery-saving settings, background permissions, and reconnection behavior after a network switch. Don’t assume a background interruption means the route is at fault.
❌ Don’t change settings blindly in bulk: Changing protocol parameters and DNS together without saving your original settings can turn one problem into several.

If you still can’t pinpoint the issue, contact the help center with your device’s operating system, client version, selected node name, steps that triggered the issue, and any error message. Hide your subscription link and authentication details before sharing screenshots. Comparing other websites on the same device, or the same website on a different network, can also help identify whether the issue is with your local network, connection configuration, or the destination website.

In short: First make sure the subscription imports, then confirm that a node connects, and finally check that traffic to your destination website follows the expected route. The protocol determines how the connection is established; dedicated lines and transit describe the route; traffic rules determine where requests go. Looking at each layer separately is more useful than searching for a supposed “works for everything” node.