VPN Glossary: Subscriptions, Nodes, Routes, Protocols, Split Tunneling & Global Mode

Here’s the short version: a VPN subscription provides configuration, a node is a selectable connection endpoint, a route is the network path traffic takes, a protocol defines how communication works, and routing rules determine where requests go. Global mode usually sends traffic handled by the client through the proxy; it doesn’t mean every connection on your device is covered.

These terms describe different layers and aren’t interchangeable. A node appearing in a list doesn’t mean its configuration is still valid, and a client showing “connected” doesn’t guarantee that a particular website is reachable. Separating configuration, traffic handling, routing rules, and network paths makes it easier to pinpoint a problem.

Subscriptions and clients: where configuration comes from

A service-plan subscription covers account benefits such as billing, data, and validity; a subscription link is the URL a client uses to retrieve configuration. People often call both simply a “subscription,” so “subscription expired” and “subscription update failed” may refer to completely different issues.

When a client accesses a subscription link, it reads node addresses, authentication details, and other settings in a supported format. Whether it also includes routing rules, policy groups, or DNS settings depends on what the provider supplies and what the client supports. A successful import only means the client accepted the configuration; it doesn’t prove every route can connect.

A client is the software that runs the configuration; the core is the component that handles proxy protocols, routing, and connections. Clients that look alike may use different cores, and different versions of the same client may support different features. If you see an “unsupported protocol” error, check the client and core versions instead of repeatedly importing the same link.

Nodes and routes: an endpoint isn’t the whole path

A node usually refers to a configuration entry in a client’s list, with details such as server address, port, protocol, and authentication parameters. Its name is just a label, not proof of the network topology. Multiple names may share an entry point or use different exits. Check the provider’s documentation and your connection results to verify whether a location in a node name matches its actual exit.

An entry point is the server location your device connects to first; an exit is the apparent source of the connection to the destination website. A route is a broader term that may cover your local carrier, entry point, intermediate transit, and exit. Assess route quality through actual use—not just the location or protocol name.

Even when a dedicated line is used for transit, local access, entry-point processing, or the route from the exit to the destination website can still be bottlenecks. Low latency doesn’t mean high throughput: latency affects responsiveness, while throughput matters more for sustained downloads and video streaming. Packet loss and latency variation matter too, so a single speed test can’t capture everyday performance.

Protocols: how communication works and what’s compatible

Strictly speaking, a VPN and an application-layer proxy are different technologies. In everyday use, “VPN” is often a catch-all term for network access tools. Shadowsocks, VMess, Trojan, and VLESS are generally proxy protocols; a client with “VPN” in its name doesn’t necessarily use a traditional VPN tunnel.

• Shadowsocks: An encrypted proxy protocol. The client and server need matching passwords and encryption methods; available extensions depend on the implementation.
• VMess: A proxy protocol with authentication and encryption mechanisms. It can use different transport methods, and a significantly incorrect system clock may affect authentication.
• Trojan: Typically uses TLS to establish encrypted communication. Certificate validation, server name, and authentication parameters must match; checking only the password isn’t enough.
• VLESS: A lightweight proxy protocol that doesn’t encrypt content on its own. It’s commonly used with a security layer such as TLS or REALITY, so assess the complete configuration.
• Hysteria2 and TUIC: QUIC-based proxy protocols that rely on UDP. Networks that restrict UDP may affect connectivity; the protocol name is no guarantee of speed.

Transport methods and proxy protocols are different things. For example, WebSocket is one way to carry communications, not a node type that replaces all other proxy settings. In a manual setup, the protocol, transport, security layer, and server parameters must all match.

These are general industry concepts, not a list of protocols currently supported by VPNRain. Check the subscription options in the dashboard and the client documentation for supported protocols. When troubleshooting, don’t disable certificate verification without good reason: it weakens server identity checks and may not fix the actual configuration error.

Split tunneling, rule-based mode, and global mode

Split tunneling routes requests based on conditions. Rules can match details such as domain names, destination addresses, or application processes, then send requests direct, to a proxy policy group, or block them. Available conditions depend on the client and its core.

Rule-based mode handles requests according to the configured rules and is usually suitable for everyday use. Many clients match rules in order, with the first matching rule determining where a request goes; a final fallback rule handles requests not covered above. As a result, the same node can behave differently under different rule configurations.

Global mode usually sends requests handled by the client to the selected proxy policy. It can help diagnose rule issues temporarily, but it can’t give a node UDP support if it lacks it, or automatically capture traffic from every app that bypasses proxy settings.

System proxy and TUN are traffic-handling methods

A system proxy sets the proxy entry provided by the operating system, but whether an app uses it depends on the app. TUN uses a virtual network interface to capture traffic covered by the relevant routes. It usually requires additional permissions and may conflict with other networking tools.

TUN isn’t the same as global mode, and rule-based mode isn’t the same as a system proxy: the former describes how traffic is captured, while the latter describes how captured traffic is routed. Even with TUN enabled, route exclusions, app exclusions, and address-family support can affect what’s covered.

DNS, leaks, and exit locations

DNS translates domain names into network addresses. If a website won’t load, the domain lookup may have failed, or the lookup may have succeeded while the connection to the destination failed. These can look similar, but changing routes and changing DNS don’t do the same thing.

A DNS leak usually means a query that should follow a specified resolution path is sent to a different resolver instead. For example, proxy traffic may be captured while DNS requests from the system or an app still use the local network. Compare the results with your expected configuration; a resolver showing a different location doesn’t by itself prove there’s a leak.

Encrypted DNS protects queries in transit, but doesn’t automatically route them through a proxy. Browser Secure DNS, system DNS, and client DNS may all be active, so check the client documentation. Some clients use Fake-IP: they return an address for internal mapping, then recover the domain from the request to determine its route. This address isn’t the destination website’s actual exit IP.

An exit location isn’t determined by the node label alone. A website may use IP geolocation databases, account region, browser location permissions, and previous sessions to estimate your location. If the result doesn’t change after switching routes, that doesn’t necessarily mean the client failed to switch—and it doesn’t guarantee that a route will keep accessing specific content.

Importing a subscription: from configuration to connection

VPNRain offers clients for Windows, macOS, iOS, Android, and Linux. Sign in to the dashboard to get a client and subscription. For iOS, follow the availability details shown in the dashboard. Permissions, background operation, and system traffic handling differ across platforms, so don’t assume button names are the same.

1. Check the configuration source. Get a subscription for your client from the dashboard. Don’t enter a subscription URL in a field intended for a single-node server address.
2. Import and check the result. Use the client’s subscription import option and check for format or protocol errors. If the list is empty, first confirm that the subscription was retrieved successfully.
3. Update the configuration. Run a subscription update and confirm that the current configuration is enabled. Creating a new configuration repeatedly doesn’t update the existing one.
4. Choose a node and policy. Start with the default rules, then confirm that the proxy policy group points to the intended node—not direct connection or another automatic selection.
5. Grant system permissions. Follow the client’s prompts to enable the system proxy or required traffic-handling mode, then visit the destination website to test the connection.
6. Troubleshoot based on what you see. Keep the error message and note the conditions that triggered it. Change one setting at a time so you can tell whether it helped.

On Android, VPN permission is generally used to create a local interface for handling traffic; it doesn’t tell you which protocol is used remotely. On iOS, allow network configuration as prompted by the system. Desktop systems may have both system proxy and TUN settings; Linux desktop and command-line environments may also use different proxy variables. For platform-specific steps, see the setup guide.

Common errors: troubleshoot layer by layer

• ✅ Subscription won’t update: Check that the link is complete, authentication is valid, and the network can reach the subscription URL. The subscription server and proxy node may have different addresses.
• ✅ Node is listed but won’t connect: Check your account benefits, client compatibility, and error logs. Handshake failures, authentication failures, and connection timeouts should be investigated separately.
• ✅ Global mode works, but rule-based mode doesn’t: Check which rule matches the destination domain, the selected policy group, and DNS handling. Don’t start by deleting all the rules.
• ✅ Browser works, but an app doesn’t: Check whether the app follows the system proxy, has its own proxy settings, and falls within the client’s traffic-handling scope.
• ✅ Problem persists after switching routes: Check the destination platform’s status, account restrictions, and existing connections. If you need to submit a support ticket, hide subscription credentials and other sensitive information.

“Latency test successful” only means the test path responded; “connected” may only mean the local proxy is listening. A proper check should include accessing the destination website and using the actual app. Don’t treat a single green icon as a complete diagnosis.

When submitting a support ticket, include your operating system, client version, traffic-handling mode, when the issue occurred, and the error message. That’s more useful for troubleshooting than “it doesn’t work.” Contact VPNRain via support, and hide subscription links and account credentials in screenshots.