VPN Terms for Beginners: Subscriptions, Nodes, Protocols & Split Tunneling Explained

This VPN glossary for beginners starts with subscriptions, nodes, protocols and split tunneling. They are not the same thing: a subscription provides configuration, a node is a connection endpoint, a protocol defines how communication works, and routing rules determine where requests go. Understand these layers first, and you can navigate your client’s menus and find the right setting instead of switching routes every time something goes wrong.

Terms and where to find them in your client

In everyday conversation, “VPN” is often used as a catch-all for network proxy services, but a traditional VPN tunnel is not quite the same as an application proxy. A client that proxies your browser does not necessarily route traffic from every app on your device. The actual coverage depends on system proxy settings, app-specific settings and whether a virtual network interface is enabled.

Menu names vary between clients. If you can’t find an exact match, look for the equivalent function rather than searching for the precise button label used in a tutorial. In particular, distinguish “Import configuration” from “Connect”: seeing nodes in a list only confirms that the configuration was imported, not that your device’s traffic is going through them.

Subscription links: configuration sources, not connection switches

A subscription link tells your client to request configuration from a server. The response may contain a node list, proxy groups, routing rules and DNS settings, depending on the server’s format and what the client supports. It is not the same as a paid plan: a plan defines traffic allowances and billing, while a subscription link is how your client obtains connection details.

At VPNPart, first sign in to the user dashboard to get your subscription, then import it using your client. Don’t mistake the dashboard URL for a subscription link, and never enter your account password on a configuration-conversion site you don’t trust. Clients may accept different formats, so use the configuration option provided in the dashboard for your client.

“Update subscription” usually means fetching the remote configuration again. It does not add traffic to your plan or automatically update your client. If the server changes a node address, you may see the change after updating. Before editing nodes managed by a subscription, check whether an update will overwrite your changes. There’s no need to update repeatedly on a fixed schedule; if nodes change or the configuration has a problem, check the dashboard announcements and notices first.

Nodes and routes: the entry region isn’t the whole path

A node is a connection entry you can select in your client. Its name may indicate a country or region, purpose or route type, but that label is not a complete picture of the network path. If you need an exit in a particular region, verify the actual exit location rather than relying on the name. The entry server’s location, the route taken and the location seen by the destination site may all differ.

Direct, relay and IEPL routes explained

• Direct: The client connects straight to the destination proxy server. The route is more direct, but performance still depends on your local ISP, inter-network routing and server conditions.
• Relay: The client first connects to an intermediate endpoint, which forwards traffic to another server. This can change the route, but adding an intermediate hop does not necessarily make it faster.
• IEPL line: This usually means that part of the route uses an international Ethernet private line. It describes the transport infrastructure, not a proxy protocol, and does not mean every segment between your device and the destination site uses a dedicated line.

A dedicated line does not guarantee low latency at all times or access to every platform. Your home Wi-Fi, congestion at the entry point, exit quality and the destination site’s policies can all affect results. To evaluate a route, test the app you actually use at the times you use it, and compare options under the same conditions.

Protocols: communication methods, not a speed ranking

Shadowsocks, VMess, Trojan, VLESS, Hysteria2 and TUIC are all common proxy protocol names. They are not a ranking from old to new or slow to fast. The same protocol may also be used with different transport methods and additional parameters. A client supporting a protocol by name does not necessarily support every combination used by a server.

Shadowsocks uses parameters such as a key and encryption method to establish proxy communication. VMess has its own authentication and communication mechanisms. Trojan typically carries proxy traffic over a TLS connection. VLESS does not encrypt content on its own, so its security depends on the transport layer used with it; the protocol name alone does not tell you what is protected.

Hysteria2 is based on QUIC, and TUIC also uses QUIC for transport. Both rely on UDP being reachable, so network restrictions on UDP can affect the connection. Using QUIC does not guarantee better speeds than other protocols. The route, congestion control, server resources and client implementation all affect performance.

Beginners generally don’t need to manually “change” a node to another protocol. The server must provide a matching configuration. If an import fails because a protocol isn’t supported, first check whether your client and its core version are compatible, then confirm you’re using the right configuration source. Don’t remove TLS, certificate validation or authentication fields at random to make the error go away.

Split tunneling, rules and global mode: where requests go

Split tunneling applies conditions to incoming requests to decide whether they should connect directly, use a proxy or be blocked. Common conditions include domains, destination addresses and app processes, though support varies by client and operating system. Rules are generally evaluated in the order specified by the configuration, and the matching policy is applied; if nothing matches, the default policy takes over.

Rule mode uses these conditions to send different requests along different routes. Global mode typically sends requests handled by the client through the selected proxy or proxy group, but it does not mean the client handles all traffic on your device. Traffic that never reaches the client is unaffected by this mode.

System proxy settings mainly serve apps that honor them. Some command-line tools need proxy environment variables set separately, while some apps make connections on their own. TUN mode often covers more traffic, but its reach still depends on routing, permissions, exclusions and operating-system restrictions. If something still fails in global mode, that alone does not prove the node is down.

A proxy group is a selection layer between rules and nodes. A rule can send a type of request to a group such as “International access,” and the group then selects a specific node. Auto select usually relies on the client’s test results; it does not guarantee that a destination site will work. A successful response from the test address also doesn’t prove that sign-in, video or persistent connections will work.

DNS and privacy: what to check beyond an encrypted connection

DNS translates domain names into network addresses. Whether you can reach a site depends not only on the proxy connection, but also on how the domain is resolved, whether the result is usable and which route the DNS request takes. Your client, operating system and browser may each have their own DNS settings, so check the actual configuration.

A “DNS leak” usually means that a DNS request expected to follow a particular proxy or privacy path instead went to an unexpected resolver or took an unexpected network route. However, routing rules may intentionally resolve local sites locally. Seeing a local resolver in a test doesn’t automatically indicate a problem; first establish which domains should use the proxy, then check how those domains are resolved.

When troubleshooting, note the browser, connection mode and DNS settings used for the test. If an app has its own encrypted DNS enabled, it may bypass the system’s DNS configuration. But encrypted DNS alone does not mean traffic goes through a proxy—or that there’s a leak. Never disable website certificate verification to troubleshoot DNS; investigate certificate warnings separately.

VPNPart’s no-logs policy describes the service’s privacy stance; it is not a guarantee of anonymity at every stage. Your account status on websites, app permissions and browser session data can still affect how sites identify you. Encrypted traffic also does not hide all connection metadata.

Import and verify: the right order of operations

The steps below are ordered by dependency. Don’t change protocols, DNS and rules all at once before confirming the previous step. Otherwise, even if access is restored, it will be hard to know what fixed the problem.

1. Get the client for your platform. Check the client download page in the dashboard for currently supported options. On platforms other than iOS, sign in to get the client. Access to the iOS option depends on your current plan status in the dashboard.
2. Import your own subscription. Use the corresponding format provided in the dashboard, then confirm that the configuration and nodes appear in your client. If parsing fails, first check that the URL was copied in full and that the format is compatible.
3. Select a node and proxy group. Start by testing a single node to avoid interference from automatic switching. Confirm that the proxy group used for the traffic you want to route actually points to that node.
4. Enable the appropriate traffic-routing method. On desktop, check the system proxy or TUN settings. On mobile, confirm that you’ve granted the required network configuration permission. Don’t run apps that compete for the same tunnel at the same time.
5. Test the app you actually use. First confirm that the destination site opens, then check the features you need, the exit region and DNS behavior. Save any error messages and compare with another node if needed.

Windows, macOS, Android and iOS have different interfaces and permission systems. On desktop, firewalls and command-line environments can also affect connections; on mobile, watch for background restrictions and conflicts with other network tools. If a tutorial refers to a setting that isn’t there, check your client’s current documentation instead of installing several tools and stacking them.

Common issues and troubleshooting limits

• ✅ No nodes in the list: Check whether the subscription downloaded and parsed correctly, then confirm your account status and configuration source. It’s too early to compare route speeds.
• ✅ Shows connected, but websites won’t load: Check the system routing method, DNS and the relevant proxy group. Distinguish between “connection established” and “requests routed correctly through the connection.”
• ✅ Websites load, but one app doesn’t: Check whether the app honors the system proxy, uses its own DNS settings, or has region and account requirements imposed by the destination service.
• ✅ Protocol not supported after import: Check client-core compatibility and the subscription format. Don’t force the configuration to save by removing security parameters.
• ✅ Unstable only during peak hours: Compare nodes and your local network under similar conditions. When contacting support, include when it happened, your client details and the error message with credentials redacted.

The simplest way to remember the basics: subscriptions provide configuration, nodes provide connection endpoints, protocols handle communication, rules determine routes, and DNS resolves domain names. Even a complex client interface becomes easier to navigate when you sort problems into these layers. For step-by-step setup, see our Guides. If your connection is still having issues, work through the troubleshooting handbook.