When looking up VPN terms, subscriptions, nodes, protocols, and routing rules are easy to confuse—but they are not the same thing. A subscription delivers configuration, a node provides a connection endpoint, a protocol defines how communication works, and routing rules determine which path each request takes. Understanding how they fit together makes it easier to import a client config, choose a route, and troubleshoot playback problems.
Subscriptions, Nodes, and Clients: How a Config Becomes a Connection
A client is a connection app running on your device. A node is a set of server connection settings the client can use, usually including an address, port, authentication details, and protocol parameters. A region label in a node name can help you choose a route, but it does not prove the actual exit location or guarantee that a particular platform will play.
A subscription link is how you retrieve configuration. The client accesses the link to download nodes or a complete config, then syncs changes when it updates. A subscription is not a network tunnel that stays on by itself, and pasting the link into a browser does not establish a connection. After importing it, select the config, enable the connection, and check that the rules are working.
There are two common meanings of “subscription”: a monthly subscription on a plan page refers to billing, while a subscription in a client is a way to update configuration. Users with data packages may also use a subscription link to retrieve configuration. Check plan status and remaining data separately from whether the client can update its config.
| Term | What it does | Common misconception |
|---|---|---|
| Client | Reads configuration and handles network connections | Installing the app means you're connected |
| Subscription link | Retrieves or updates nodes and full configuration | Every client can import the same format |
| Node | Provides a set of connection parameters | The region in the name is the region a platform detects |
| Proxy group | Organizes nodes for manual selection or automatic routing | Changing the group name always changes the actual exit route |
| Rule | Determines how a request is handled based on conditions | If the client says connected, every app uses a node |
Common Protocols: Names and Compatibility
Strictly speaking, traditional VPN protocols and proxy protocols are not exactly the same. Services aimed at beginners often group them together as network connection tools, but whether a client handles system traffic or supports a particular protocol depends on its implementation. Don’t judge by whether the app’s name includes “VPN.”
- Shadowsocks: An encrypted proxy protocol commonly used with proxy clients. Encryption methods, extensions, and implementations can vary in compatibility; a successful import does not mean every parameter is supported.
- VMess: A proxy protocol in the V2Ray ecosystem that uses user authentication and transport settings. If a connection fails, check the authentication details, transport method, and related parameters—not just the region.
- Trojan: Typically carries proxy traffic over TLS. The server name, certificate validation, and authentication details need to match. Don’t disable certificate validation just to get a temporary connection.
- VLESS: Does not provide data encryption by itself and is usually paired with TLS or another appropriate security mechanism. The name VLESS alone does not tell you the connection’s overall security properties.
- Hysteria2 and TUIC: Both are based on QUIC and use UDP for transport, but they are different protocols. UDP restrictions on the network, client implementation, and server configuration can all affect how well they connect.
Protocols are not a speed ranking. The same protocol can perform very differently across connection endpoints, exit routes, and carrier networks; different protocols can also be affected by the same congested exit. This article explains general concepts and does not imply that VPNHill offers every protocol listed. Check the dashboard configuration and client documentation for current support.
When choosing a client, first check the configuration format provided by the service, the protocols the software supports, and the capabilities of its current core. Manually changing a node address to a different protocol name won’t make the server support that protocol.
Direct, Relay, and IEPL Routes: How the Paths Differ
A direct node usually means your device connects directly to an overseas entry point, without an additional upstream relay operated by the service. “Direct” does not mean there are no routers or that it’s the shortest route. The actual path still depends on your local network, carrier interconnections, and international gateways.
A relay node adds a forwarding point between your device and a downstream server. It may improve access to the entry point or the route between networks, but it can also add a bottleneck. A relay label in a node list describes how the route is set up, not a guarantee of picture quality or latency.
IEPL refers to an international Ethernet private line, typically used for dedicated connections between enterprise or service-provider sites. An IEPL service does not mean the entire route from your device to the destination website uses a private line: local access, the private-line entry point, the overseas exit, and the website’s network all matter.
When choosing a route, consider its label separately from how you plan to use it. For live sports, focus on uninterrupted playback and buffering during the event. For on-demand libraries, first confirm the exit region and how the platform identifies it, then check how quickly playback resumes after seeking. Route type alone cannot validate a specific viewing setup.
Rule-Based vs. Global Mode: Where Requests Go
Rule-based mode matches requests against domains, destination addresses, or other supported conditions to decide whether to connect directly, send them to a proxy group, or reject them. The available conditions depend on the client core. Rules usually run in order, so an earlier match may prevent later rules from being evaluated.
Global mode generally sends all requests handled by the client through the selected proxy policy. The key phrase is “requests handled by the client”: if an app does not use the system proxy and the client does not capture its traffic through a virtual network interface or another method, global mode does not guarantee that the app will use the proxy.
Direct mode generally means accessing the destination over your local network without a proxy node. A direct action in a rule is not the same as a direct route in a node list: the former bypasses the proxy, while the latter is still a proxy connection route.
System Proxy, TUN, and Proxy Groups: What’s the Difference?
A system proxy tells apps that support the setting where to find a proxy; some apps may ignore it. TUN mode captures traffic through a virtual network interface, then lets the client handle routing and rules. It typically requires appropriate system permissions and may conflict with other networking software. Follow the client documentation and enable it only if it suits your needs.
Proxy groups are part of the routing logic. A manual group lets you choose a node; an automatic or failover group runs checks and switches according to its configuration. A reachable test address does not mean a streaming account will work, and the automatically selected node may not match the region of the library you want.
Exit IP, DNS, and Streaming Regions: Why Things Can Differ After Connecting
An exit IP is the source address a website typically sees for your request. The entry point connects you to the service; the exit point accesses the destination, and they may be in different regions. After switching nodes, use IP Check to verify your browser’s current exit. The browser’s result may not reflect the route used by other apps.
DNS translates domain names into addresses that can be reached. DNS lookups and web connections are separate steps: routing web traffic through a proxy does not automatically mean DNS queries are handled as expected. A browser’s encrypted DNS, the system resolver, and the client’s DNS settings can also affect one another.
A DNS leak generally means DNS queries take a path other than the one you expected—for example, queries still go through your local network when you intended them to use a specified resolver. Check the actual configuration when troubleshooting. A test page showing a resolver’s location does not mean your personal location has been exposed, and a single name is not enough to draw every conclusion.
If the exit region looks right but the streaming library does not, also consider the platform account’s region, content licensing, cached data, and how the exit IP is identified. “Native IP” is not a standardized certification; services may define the label differently. Residential or datacenter IP type does not guarantee access to a platform.
For more effective troubleshooting, note the platform, node name, traffic-capture mode, and exact error, then test one factor at a time. Avoid changing DNS, nodes, rules, and browser settings all at once; even if playback resumes, you won’t know what fixed it.
Importing a Client and Verifying the Connection: Check in Dependency Order
Once you understand the terms, follow this sequence: configuration source → client parsing → node connection → traffic capture and routing → destination access. If an earlier step fails, switching modes later in the chain usually won’t fix it. Platform differences mainly involve config compatibility, network permissions, and background behavior—not button placement.
- Choose a compatible client. Check the instructions under Get the Client in the dashboard and make sure the operating system and config format match. Desktop clients and command-line tools for Windows, macOS, and Linux may support different features.
- Import through the official configuration channel. Copy the complete subscription link and add it using the import method provided by the client. On iOS and Android, also check system network access permissions. A client config is not the same as a system-managed configuration profile; don’t install profiles from unknown sources.
- Update first, then choose a node. Confirm that the subscription was parsed successfully and the node list is populated, then select the target region. If the update fails, first check that the link is complete, the config format is supported, and the service is available.
- Enable and verify traffic capture. Following the instructions, enable the system proxy or an appropriate virtual network interface mode. Avoid having multiple tools rewrite routes at the same time. On mobile devices, check whether the system restricts the client from running in the background.
- Check the exit and target app separately. Verify the browser’s exit, then open the platform you actually want to use. If only a specific app fails, check whether its traffic is captured, which rule it matched, and whether it has separate network settings.
A successful import only means the config was accepted; a successful node test only means the test destination was reachable; a webpage loading only confirms that request worked. Treat these as separate states to avoid going in circles over “connected, but playback still won’t work.” For setup instructions, see the client guide in Quick Start.
Common Errors: What the Terms Mean and How to Troubleshoot
- ✅ Subscription update failed: First check the configuration source, link completeness, and format compatibility. Don’t start by changing streaming platform settings.
- ✅ None of the nodes connect: Check service status, your local network, and client permissions, then verify protocol support and authentication parameters.
- ✅ Works in the browser but not in an app: Check whether the app uses the system proxy and whether you need to adjust traffic capture as described in the client documentation.
- ✅ Connected, but the library is wrong: Confirm the actual exit and proxy group selection, then check the account region and the platform’s content restrictions.
- ❌ Don’t treat a speed test as the whole picture: Bandwidth, latency, jitter, and packet loss describe different conditions. No single result predicts sustained playback quality.
- ❌ Don’t share your config when asking for help: The error message is usually enough. Hide the subscription link, authentication fields, and account credentials before sharing screenshots.
Finally, distinguish data usage from bandwidth: data usage is the total amount transferred, bandwidth describes transfer capacity, latency is the round-trip time, and jitter is variation in latency. More data in a plan does not mean every node will be faster, and lower node-test latency does not guarantee more stable playback during a major event.