This VPN glossary for beginners starts with the difference between subscriptions, nodes, routes, protocols, and split tunneling: a subscription provides configuration, a node is a connection option, a route describes the network path, a protocol governs how data is exchanged, and split tunneling determines where requests go. These terms describe different things and aren't interchangeable.
Understanding these terms isn't about memorizing more acronyms. It helps you choose the right client settings and know where to look when something goes wrong. The concepts below are general and don't mean VPNFar offers every protocol or route type. Check the dashboard and client for the options actually supported.
Subscription: A plan and a configuration link aren't the same thing
“Subscription” commonly has two meanings. On a pricing page, a monthly subscription is a billing arrangement; in a client, it usually means a source of configuration. A subscription link lets the client retrieve details such as server addresses, ports, and authentication data. Some subscriptions also include proxy groups and rules. Whether they include a complete rule set depends on the server's output format and the client's capabilities.
Copying a subscription link doesn't copy an installer or establish a connection. Think of it as connection information that can be refreshed. If a service updates its nodes, the client usually needs to refresh the subscription to get the new configuration. Refreshing it won't resolve local authorization issues, network reachability problems, or an account with an invalid plan status.
The same account may offer subscription formats for different clients. If importing fails with a format error, first check that you're using the right import option instead of repeatedly editing the link. A link for sharing one node describes a single connection configuration; it isn't the same as a subscription source that can be refreshed over time.
A subscription URL may contain credentials that grant access to your account. Don't post it in public comments, paste it into unfamiliar online conversion tools, or include it in screenshots. If you think the URL has been exposed, check the dashboard for how to reset it, then update the subscription in your client.
Nodes and Routes: Client options and the actual network path
A node is usually a selectable connection option in a client. It may point to a physical server or to a load-balanced entry point. So two differently named entries in a list don't necessarily represent two separate physical machines. The region in a name can help identify the exit location, but check the service details for context.
A route describes the network path from your local network to an entry point and then to an exit. A node with a Japan exit doesn't necessarily have an entry point in Japan; a nearby entry point doesn't mean the entire route is short. The exit address seen by a website, the server address your device connects to, and the networks along the way are different pieces of information.
| Type | In plain English | What to consider |
|---|---|---|
| Direct | Your device connects to the remote service entry point over a regular network, without an additional relay node configured by the provider. | Routing and congestion between your local ISP and the remote endpoint. |
| Relayed | Your device connects to an intermediate server, which forwards traffic to the next node or exit. | Entry-point reachability, relay capacity, and the rest of the route; an extra hop doesn't necessarily mean a slower connection. |
| IEPL dedicated line | Usually refers to using an international Ethernet private line for part of a cross-border data route. | Which part of the route uses the private line and how the entry and exit connect; the label alone doesn't guarantee end-to-end performance. |
“Direct” can also appear in routing rules, where it means a request bypasses the proxy and reaches its destination over your local network. That's different from a “direct route.” When you see DIRECT, first check whether it refers to a rule action or a route description.
The latency shown in a client is just one kind of probe result. The target, method, and network load during the test all affect the reading. Lower latency doesn't mean higher download bandwidth, and it can't tell you on its own whether a live sports stream will be stable. A better check is to use the app you care about and watch for buffering or reconnects over time.
Protocols: How data is transmitted, not a plan tier
A protocol defines how a client and server exchange data. Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC may all appear in proxy clients, but not every client supports them. The name alone doesn't tell you how fast or private a connection will be.
Shadowsocks is a proxy protocol family, and the client and server need to use a compatible encryption method. VMess and VLESS are different protocols; VLESS doesn't encrypt data by itself, so deployments typically pair it with secure transport such as TLS. Trojan commonly uses TLS, and its configuration may involve domain names and certificate verification.
Hysteria2 and TUIC are based on QUIC and rely on UDP at the transport layer. If your network restricts UDP, connection performance may be affected. That doesn't make either protocol inherently better than the alternatives; suitability depends on network conditions, server configuration, and client version.
Beginners don't need to change a protocol to an option that simply sounds newer. The protocol, transport, and authentication details must match the server. Copying someone else's port or turning off certificate verification can break the connection or weaken authentication. Use a compatible configuration provided by the service whenever possible.
Bottom line: First check that your client supports the protocol in the subscription, then confirm the network is reachable, and finally test the apps you actually use. A protocol name, dedicated-line label, or region name alone isn't a reliable speed ranking.
Split Tunneling, Rule-Based Mode, and Global Mode
Split tunneling sends different requests along different paths. Depending on the client, rules may be based on domains, destination addresses, app processes, or geolocation databases. A rule might send local services direct, route international sites through a proxy, or block certain requests. Most rule systems check rules in order and apply the action for the first match.
Rule-based mode uses configuration to decide where requests go, making it useful when different services need different routes. Global mode usually sends all traffic captured by the client through the selected proxy policy. “Global” doesn't mean every app on the device is captured: coverage also depends on the system proxy, virtual network interface mode, and app behavior.
A system proxy tells apps that respect system settings to use a proxy; some programs ignore it. TUN mode captures traffic through a virtual network interface and usually covers more apps, but still requires correct routing, DNS, and permissions. A VPN icon on a mobile device doesn't mean the underlying connection uses a traditional VPN protocol.
If a site works in global mode but not in rule-based mode, first check which rule it matched and which proxy group was selected. Don't assume the node is broken. Conversely, if global mode slows down local services, it may be routing requests that don't need a proxy through a remote server.
DNS and Leaks: Check Where Domain Lookups Go
DNS translates domain names into network addresses. A browser typically needs to resolve a domain before opening a website. Even after a proxy connection succeeds, DNS queries may still follow different settings. Being able to open a page and having DNS queries follow the intended route are two separate checks.
A DNS leak generally means queries aren't taking the expected path and are instead being sent to a local or other resolver. Whether that's a leak depends on the intended routing design. If the rules explicitly send local services to a local resolver, seeing that resolver doesn't by itself indicate a problem.
A browser's encrypted DNS settings, system resolver configuration, and DNS handling in the client can affect one another. Encrypted DNS protects part of the query's journey; it doesn't mean all app traffic goes through the proxy. When troubleshooting, check both browser and client settings instead of just changing a DNS address.
Checking your exit address can help confirm the route used by the current web page, and a DNS test can show which resolver handled a lookup. Neither proves how all app traffic is routed. A test page only reflects the requests it can observe; for privacy or workplace networks, follow your organization's usage requirements too.
Import a Subscription: From Dashboard to Connection
Start with a compatible client, import the matching subscription, then enable traffic capture and choose a policy. Button labels vary by platform, but the overall sequence is much the same. VPNFar subscriptions are available after you sign in. Except on iOS, the VPNFar client is available from the dashboard without a purchased plan; on iOS, availability depends on an eligible plan shown in the dashboard.
- Check your account status. Sign in to the dashboard, check your plan and data balance, then find the client for your platform.
- Get the right configuration. Copy the subscription URL for your current client from the dashboard. Don't use conversion results from unknown sources.
- Import and refresh. Add the subscription in your client and check that nodes appear. If the list is empty, start by checking the refresh error.
- Grant system permissions. Allow the relevant network configuration when prompted, then make sure the client's connection switch is on.
- Choose a policy and test it. Start with the default rules and a suitable node to open the app you want, then check that local services still work.
Windows and macOS may require permissions for a system proxy, network extension, or virtual interface. iOS and Android usually capture network traffic through a system VPN configuration; an existing work network configuration may affect the connection. On Linux, also check permissions, routes, and resolver services. Follow the VPNFar guides and the prompts in your current client for platform-specific steps.
- ✅ The node list refreshes: the subscription was retrieved successfully, but that doesn't mean the proxy connection is working.
- ✅ The target app works and local services are still available: this is a more meaningful test than relying on a connection icon alone.
- ❌ Repeatedly switching nodes when the list is empty: check the subscription URL, format, and account status first.
- ❌ Treating disabled certificate verification as a universal fix: check the system clock, configuration source, and service documentation instead.
Troubleshooting Steps and Plan Terms
When something goes wrong, first identify the failing step. If the subscription won't refresh, check the URL and format. If it refreshes but won't connect, check client compatibility, permissions, and network reachability. If only one app is affected, check split-tunneling rules, DNS, and the app's own proxy settings. Change one thing at a time and note the original settings so you don't muddy the diagnosis.
Data allowance in a plan is the amount of data you can use, not bandwidth. Bandwidth describes data transfer capacity; latency describes round-trip delay. Device limits are a separate consideration. VPNFar has no limit on the number of devices connected at the same time, but shared plans still have a data allowance: unlimited devices doesn't mean unlimited data.
VPNFar monthly plans are ¥9.9/month for 60GB, ¥18/month for 250GB, and ¥28/month for 500GB. Data resets monthly on the activation date; mid-cycle upgrades are prorated for the remaining days. Data add-ons cost ¥158/300GB, ¥358/1000GB, and ¥658/3000GB; they remain available until used and never expire. Choose based on how consistently you use the service, not on the assumption that more data means a faster route.
VPNFar covers 100+ countries and 230+ routes. No email address is required; create an account with a username and password. You can request a full refund for any reason within 60 days of your first payment. For pricing details, see plan details; to check node regions, see regions and routes. Don't infer additional benefits from a glossary.
Remember the relationship: Your account determines available benefits, a subscription provides configuration, nodes offer connection options, routes carry traffic, protocols govern communication, and split tunneling determines where requests go. Follow that order when reading a client interface to find issues more easily than by chasing acronyms.