VPN Terms for Beginners: Subscriptions, Nodes, Routes, Protocols, and Split Tunneling

VPN basics: understand profiles and connections

This VPN glossary puts subscriptions, nodes, routes, protocols, and split tunneling in context. A subscription provides configuration, a node is a connection target, a route describes the path traffic takes, a protocol defines how devices communicate, and split tunneling determines which requests take which path.

People often use “VPN” as a catch-all for system VPNs, proxy clients, and international routing services, but they are not all the same. A system-level tunnel can handle a device’s network traffic. A proxy client may only handle requests from apps that follow system proxy settings, or it may cover more traffic through a virtual network interface. Similar names do not mean they cover the same traffic.

A subscription link is not the same as a monthly subscription

A “monthly subscription” is a billing option; a “subscription link” is a way to retrieve configuration. Users with a data package may also use a subscription link, but having a link does not mean the account always has data available. If you have connection issues, check your account status and client configuration separately instead of repeatedly importing the link.

After you add a subscription URL, the client downloads and parses its configuration. It may contain only node details or also include groups, routing rules, and DNS settings, depending on the format provided by the service. Configuration syntax varies between clients: being able to open a link does not mean the client can import its contents correctly.

Updating a subscription retrieves the configuration again, for example to sync node changes or updated rules. It does not add credit or directly fix local network problems. Some clients preserve your selections, while others may change the active policy group after an update. Check the selected node and mode when the update is complete.

Where are the node, entry point, and exit point?

A node in a client is usually a set of server addresses, ports, authentication details, and protocol options. Its name is a label for easy selection; it may not correspond to a separate physical server and does not show every region your traffic passes through.

The entry point is where your device first connects to the service; the exit point is the public IP address seen by the destination website. Traffic may pass through additional relays in between. A node’s region label usually indicates its exit location, but a website’s geolocation result can also depend on IP databases, account region, and platform policies. Don’t draw conclusions from the label alone.

Latency, throughput, and connection stability are different things. Latency is the round-trip wait for a request; throughput affects sustained data transfer; stability affects whether the connection stays up. A client’s connectivity test may only reach a specific test address, so its result may not match how videos, websites, or API requests perform.

If an IP lookup page shows no change, first check whether that page is routed through the proxy. In rule-based mode, the lookup site may connect directly; switching nodes may not change the exit IP used for that request. Use My IP to help check, but don’t treat the result from one site as proof for every app.

IEPL dedicated lines, relays, and direct connections

A direct connection usually means your device connects straight to a server outside your region, relying mainly on public internet routing. Don’t confuse a “direct route” with “direct” in a routing rule: the former describes the connection path from your device to the server, while the latter usually means a request bypasses the proxy.

A relay adds a forwarding node between your device and the exit point. Traffic reaches the entry point first, then continues to the exit. This may improve reachability or routing, but the result depends on relay capacity, carrier interconnections, and load. An extra hop is not automatically faster or slower.

IEPL usually refers to an International Ethernet Private Line, a dedicated Ethernet connectivity service. An “IEPL route” label on a subscription service may only cover the segment between the entry and exit points; it does not mean your home broadband connection is also a private line. A dedicated-line label is no substitute for testing the actual connection.

Compare routes on the networks you normally use, and note the affected app, time, and network type when issues occur. A region name, protocol name, or “dedicated line” label cannot tell you the exact bandwidth or latency, or guarantee ongoing access to a particular platform. See International Routes for VPN61 node entry points; available options are shown in your account.

A protocol name is not a speed ranking

Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC are common proxy protocols or protocol families, not plan tiers. A protocol defines the communication format and related capabilities, but the actual connection also depends on the transport, encryption settings, client implementation, and network conditions.

How Shadowsocks handles encryption depends on the selected method. VMess has its own authentication and encryption mechanisms, while Trojan typically establishes a connection over TLS. VLESS does not encrypt payloads on its own; check the actual configuration to see whether TLS or another mechanism provides protection. The protocol name alone is not enough to tell.

Hysteria2 and TUIC are based on QUIC and rely on UDP being reachable. Some networks restrict UDP, which can affect connectivity, so it’s not safe to assume that a newer protocol is always faster. This article explains general concepts and does not imply that VPN61 offers all of these protocols.

TLS is a secure transport mechanism, WebSocket is a transport method, and TUN is a virtual network interface mechanism; they are options at different layers. If an import fails, check whether the client and its core support the complete configuration combination. Don’t guess at authentication parameters or certificate verification settings.

Split tunneling, rule-based mode, and global mode

Split tunneling handles requests according to conditions. These may be based on domains, destination addresses, processes, or other information supported by the client. Requests may go direct, through a proxy, be blocked, or be assigned to a policy group. Rules usually have an order, and the first matching rule may determine where a request goes.

A policy group is the node selection layer. A rule can send a request to a policy group, which then selects a node. So if you switch nodes and a website behaves the same, the switch may have worked—the site may be connecting directly or using a different policy group.

Rule-based mode routes requests according to configuration, which is useful when you use both local services and international websites. Global mode generally sends requests the client receives through one policy, but it does not automatically expand the traffic the client handles. With system proxy enabled alone, apps that ignore that setting may still bypass the client.

TUN or system VPN interception can cover more traffic, but routing, exclusions, app behavior, and system permissions still matter. Global mode does not make you anonymous: sign-in status, browser storage, and account activity can still identify you to websites. For troubleshooting, compare rule-based and global modes temporarily, then adjust the rules based on what you find rather than switching back and forth indefinitely.

How to understand DNS resolution and leaks

DNS translates domain names into network addresses. Routing web requests through a proxy does not mean DNS queries take the same path; the client, operating system, and browser may all take part in resolution. Encrypted DNS in a browser does not guarantee that its queries go through the current proxy.

A DNS leak usually means a query did not follow the expected route and was sent to an unintended resolver. First clarify what you expect: rule-based mode may resolve some domains locally, which is not necessarily a fault. If specific domains should be resolved through the proxy, check DNS routing rules and the client’s traffic interception settings.

The resolver names shown on a test page are only a clue. Public DNS services may operate servers in multiple regions, so the name or reported location may differ from your exit point. A location mismatch alone does not prove a leak. Check the active rules, browser settings, and the client’s local diagnostics together.

From client import to connection testing

Once you understand the terms, follow these steps to get set up. VPN61 provides client access for Windows, macOS, iOS, Android, and Linux. Your account panel determines download access, and you need to sign in to get a subscription. The same platform does not mean every client has the same features or configuration format.

1. Check your account and configuration source. Sign in to the account panel, check your plan status, and get a subscription compatible with your client. VPN61 does not require an email address; create an account with a username and password.
2. Get the client from the account panel. Use the client download page and check the platform and installation instructions. A subscription URL is not a client download link.
3. Import and check the result. Use the client’s subscription import feature and confirm that nodes appear. If the format is unsupported, first check the import type and core compatibility instead of pasting the link repeatedly.
4. Grant permissions and choose a mode. Virtual network adapter features on macOS and Windows may require elevated permissions; iOS and Android usually prompt you to authorize the system VPN. On Linux, configure service permissions, routing, and DNS according to the client’s instructions.
5. Select a node and connect. Check the active policy group, node, and system proxy or tunnel status. If another tool is already managing network traffic, first rule out routing and DNS conflicts.
6. Test real requests. Visit the target website and check the exit point and app behavior. If a webpage works but an app doesn’t, first check whether the client is handling that app’s traffic. If domain resolution fails while the connection is active, check the DNS route.

For detailed instructions, see Guides and the User Handbook. When reporting an issue, include your platform, client, selected mode, and error details. Don’t share subscription tokens, passwords, or complete configurations that contain them.

After connecting: check data usage and service limits

Monthly subscriptions and data packages differ in billing and how long data remains available, not in protocol. VPN61 monthly plans are ¥9.9 / 60GB, ¥18 / 250GB, and ¥28 / 500GB; data resets monthly on the activation date. If you upgrade mid-cycle, the price difference is converted into remaining days. Data packages are ¥158 / 300GB, ¥358 / 1000GB, and ¥658 / 3000GB; they last until used and never expire.

“Unlimited devices” refers to the number of devices, not unlimited data or a separate plan allowance for each device. VPN61’s no-logs statement describes its privacy policy; it does not replace device security, website account protection, or app permission management. The refund policy offers a 30-day no-questions-asked refund; see the terms page for details.

• ✅ Import failed: Check the subscription format, authentication status, and client compatibility.
• ✅ Connected but can’t access sites: Check the node, routing, DNS, and the destination website.
• ✅ Only one app is having problems: Check system proxy coverage, TUN, and exclusion rules.
• ✅ Behavior changed after an update: Check the active policy group, selected node, and newly added rules.