VPNBasics: Nodes, Routes, Protocols and Routing Explained

This beginner-friendly VPN glossary puts nodes, routes, protocols, and traffic rules in context. A subscription provides connection details, a node is a selectable connection option, a route is the path data takes, a protocol defines how devices communicate, and traffic rules determine which path each request follows. Understanding these differences is more useful than memorizing product names.

For example, a cross-border store dashboard may load while its images do not. The cause could be traffic routing or DNS resolution, not a lack of plan data. The sections below follow the process from getting connection details to connecting, routing traffic, and troubleshooting, with each term tied to a practical scenario.

Subscriptions and clients: connection details vs. software

Subscription: a paid service, or connection details

A “monthly subscription” describes a billing arrangement. In a client app, “Add subscription” usually means importing connection settings. These are not the same thing. Users with data packages may also use a subscription link to get configuration details, so seeing a “Subscription” button does not necessarily mean there will be a monthly charge.

A subscription link is an address a client uses to retrieve nodes or a complete configuration, and it usually contains account-related credentials. It is not the provider’s regular homepage or the password for the account dashboard. For example, copy the link from the dashboard and paste it into the client’s subscription field so the app can retrieve the relevant connection details.

Client, core, and configuration: interface, engine, and instructions

The client provides the interface for importing configurations, connecting, and switching options. The core handles protocols, routing, and DNS, while the configuration tells it where to connect and how to route traffic. Clients with similar interfaces may support different protocols and configuration formats. Different versions of the same core may also vary in compatibility.

So, “the link opens” and “the current client can import it” are two different things. A configuration may contain only nodes, or it may include proxy groups, rules, and DNS settings. Before importing a full configuration, check whether it will replace existing rules. Do not assume every setting is appropriate just because the import succeeded.

Nodes and routes: an option name is not the whole path

A node is a connection profile you can select in a client. It typically includes a server address, port, protocol, and authentication details. Think of it as an available connection option, but it may not correspond to a separate physical server, and its name alone cannot verify the actual egress location.

Ingress is where the connection first reaches a server; egress is the location websites see as the source of a request; and a route describes how traffic travels in between. For example, an option labeled with a particular region may first connect through an ingress elsewhere, then access websites through egress in that region. Labels can help with categorization, but check the service documentation for the actual route.

More nodes do not mean every option is right for the task at hand. Dashboard logins may depend more on consistent egress, file transfers on sustained throughput, and video calls on a stable connection. Once you have a suitable egress, there is no need to switch repeatedly just because the list has different names. A website may also treat an egress change as a change in your environment that requires verification.

There is another easily confused use of “direct”: in traffic rules, DIRECT usually means a request bypasses the selected proxy and goes straight to its destination. This is not the same as “direct connection to the proxy server” in the table above; the terms describe different layers. When someone says “use a direct connection,” clarify whether they mean the service route or a rule action.

IEPL describes a transport service, not an encryption protocol or permission to access a website. The “dedicated line” label alone does not prove end-to-end encryption, a fixed bandwidth, or guaranteed access to any particular website. Those claims need separate evidence.

Protocols: check compatibility before choosing

A protocol defines how a client and server exchange data. The client must implement the protocol offered by the node; changing the name in a configuration cannot make the server support a different protocol. A protocol does not determine the egress region, and its name alone says nothing about connection speed.

• Shadowsocks: An encrypted proxy protocol. Compatibility also depends on the specific method and version. Support for Shadowsocks does not necessarily mean support for every related configuration.
• VMess: A proxy protocol in the V2Ray ecosystem, with authentication and data-protection mechanisms. Other settings, such as transport parameters, must also match. Configurations are not interchangeable just because they use the same protocol name.
• Trojan: Typically uses TLS to protect communication between the client and server. Certificate verification and the server name are important settings; disabling verification should not be treated as a routine fix.
• VLESS: A lightweight proxy protocol that does not provide data encryption on its own and must be paired with an appropriate security layer. The VLESS label alone does not reveal how the entire connection is protected.
• Hysteria2 and TUIC: Both use QUIC-based approaches and depend on UDP network conditions, but they are different protocols and their configurations cannot be imported interchangeably.

For example, if the network restricts UDP and the current configuration relies on QUIC, the connection may be affected. Check the options actually offered by the server instead of repeatedly changing the displayed name. This article explains general industry concepts; it does not mean VPNRP offers every protocol listed here. Refer to the dashboard and client documentation for available configurations.

Traffic routing, rule mode, and global mode

Traffic routing uses conditions such as domain, destination address, or app to decide whether a request connects directly, goes through a proxy, or is blocked. Rule mode checks the configured rules in order; typically, the first matching rule determines how a request is handled. A final fallback action handles requests that match no other rule.

For example, route a store dashboard through a designated proxy and access local business websites directly. But a dashboard page may call different domains for login, images, and APIs. A rule for the main domain may not cover every resource. Check failed requests and the rules they match, then add only the necessary scope instead of putting every domain into one rule.

A proxy group is a set of candidate actions or nodes that a rule can point to. The rule decides “which group”; the selection within that group decides “which node.” An automatic selection group may switch based on test results, but whether that suits a task depends on the circumstances. For dashboard work that needs consistent egress, consider the effects of automatic switching.

Global mode typically routes all traffic captured by the client through a selected proxy. It does not necessarily cover every app on the device. Requests that never enter the client may still follow their original route. Global mode, therefore, does not prove that “all traffic is being captured.”

System proxy vs. TUN: different traffic coverage

A system proxy provides an entry point for apps that follow the system settings, but some programs ignore it. TUN typically captures more IP traffic through a virtual network interface, but is still subject to permissions, routing, exclusions, and platform limits. When troubleshooting, verify both which mode is in use and which traffic is actually captured; the connection toggle alone is not enough.

DNS leaks and the limits of connection protection

DNS resolves domain names to addresses that devices can connect to. DNS requests and subsequent web traffic may take different routes: web traffic going through a proxy does not mean DNS queries use the same channel. A DNS leak usually means resolution requests did not follow the expected protected route and were instead sent to another resolver.

That does not mean the full contents of a webpage have been exposed, but it may reveal the domains you looked up and affect resolution results. An app’s encrypted DNS, system resolver settings, and the client’s DNS rules can also interact. Encrypted DNS protects part of the query’s journey, but cannot by itself prove that the entire access path behaves as expected.

For a proper check, review the client’s resolution policy, request logs, and egress result, then see whether the target website works normally. Do not conclude there is a leak just because a test page shows a particular region. Nor should you blindly disable certificate verification or other security settings just to make test results match.

Latency, bandwidth, and data: three separate questions

Latency is the time it takes for a request and response to make a round trip; bandwidth is the capacity to transfer data; data usage is the amount of data transferred. A probe latency shown in a list is measured using a specific method, so it may not reflect the full path to a webpage. It also cannot replace sustained download tests or the experience of using a dashboard.

Jitter is variation in latency, while packet loss means some data does not arrive. Video calls, live streams, and interactive tasks may be more affected by these issues. Slower speeds at peak times may also involve local Wi-Fi, ISP interconnection, relay ingress, or the destination website. Troubleshoot each segment instead of assuming the network is fine because a bandwidth label looks good.

For billing, check the data allowance rules. VPNRP monthly plans are ¥9.9/month for 60GB, ¥18/month for 250GB, and ¥28/month for 500GB; data resets monthly on the activation date. Data packages are ¥158/300GB, ¥358/1000GB, and ¥658/3000GB, and remain valid indefinitely until used up. The two product types handle data validity differently, so do not confuse them.

From import to troubleshooting: a checklist

What a platform can capture and which connection options are available vary by operating system. On Windows, macOS, and Linux, check system proxy settings, routing, and permissions. On iOS and Android, system network extensions or VPN permissions may also be involved. Seeing a system VPN indicator does not mean the app uses the same protocol on every platform.

• ✅ Get a subscription link suited to your client from a trusted dashboard, and check the import format and protocol compatibility. See the setup guides for client-specific instructions.
• ✅ After importing, check that the nodes appear, the configuration updated successfully, and existing rules or DNS settings were not replaced.
• ✅ Connect to a node suited to the task. Verify the target page, login process, and resource loading before starting dashboard work or transferring files.
• ✅ If only one app fails, check system proxy coverage, TUN settings, and the app’s own proxy settings. If only some resources fail, check traffic routing and DNS resolution.
• ✅ Change one relevant setting at a time and note what happens, including any error messages. If the cause is still unclear, use the support ticket form in the dashboard and share redacted details.

VPNRP supports Windows, macOS, iOS, Android, and Linux, with no limit on the number of devices connected at the same time. Except for iOS, clients are available through the account dashboard; for iOS, check the account status in the dashboard for available options. The device limit describes supported usage across devices; it does not change the plan’s data allowance or mean every device should use the same traffic rules.