Here’s the key relationship to remember: a subscription provides configuration, a node is a connection endpoint, a protocol defines how data is transmitted, and routing rules determine which traffic takes which path. These are separate settings, and none can replace another. If a connection fails, check them in this order to narrow down the cause instead of repeatedly changing options.
People often use “VPN” broadly to mean a tool for cross-border access, but a system VPN tunnel and an application proxy aren’t exactly the same thing. A client with “VPN” in its name doesn’t necessarily route every app through a proxy. Understanding the terms below helps you work out what the client actually handles.
Start with the Beginner Glossary
| Term | What it means | What it affects | Common misconception |
|---|---|---|---|
| Subscription link | An address the client uses to fetch or update configuration | Which nodes and settings can be imported | Copying the link means you’re connected |
| Node | A connection entry with details such as a server address and authentication | The server you connect to and your chosen exit route | The node name proves where your traffic exits |
| Protocol | The communication method agreed on by the client and server | Compatibility and connection behavior | A newer name means faster speeds |
| Route type | How the route is arranged, such as direct, relayed, or dedicated | The network path your requests take | It’s the same as the protocol name |
| Proxy group | A set of nodes or actions that rules can use | Manual selection, automatic selection, or failover | Selecting a node always changes the route for all requests |
| Routing rule | A condition based on a domain, address, process, or other criteria that determines where traffic goes | Direct connection, proxy, or blocked connection | Rule-based mode means all traffic uses a proxy |
| DNS | DNS | How domain names are resolved to network addresses | The DNS resolution path and some rule matches |
A typical request flow looks like this: the client gets its configuration, receives requests according to its traffic-capture method, matches them against rules, selects a policy, then connects to the destination through a node. DNS handles domain lookups, but whether they happen locally or remotely depends on the configuration and client implementation.
How Are Subscriptions Different from Nodes?
A paid subscription and a subscription link are two different things
A paid subscription is a billing arrangement for a service; a subscription link is a way to distribute configuration. After choosing a plan, you’ll usually get a client-compatible link from the user panel and import it into your client. The link isn’t an installer or a webpage you need to keep open in your browser.
A configuration may contain only nodes, or it may also include proxy groups, rules, and DNS settings, depending on the format provided by the service. When a client says “Import successful,” it only means the configuration was accepted. It doesn’t confirm that a node is reachable or that every app is using the proxy.
Node entries and proxy groups
A node usually includes a server address, port, authentication details, and protocol settings. Its display name is for identification and may not match the entry location or final exit region; with relayed routes, the entry and exit can differ. To verify a region, check your exit after connecting.
A proxy group is a selection layer between rules and nodes. For example, a rule might send a type of request to an “International Access” group, which currently selects a node in Japan. Changing a different group that the rule doesn’t use won’t change where those requests exit. When troubleshooting, check both that the node works and that the request is using the expected group.
Protocol Doesn’t Determine Connection Quality
Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC are protocol names you may encounter in a client, but the name alone doesn’t tell you which is best. Connection results depend on the client core, server version, authentication parameters, transport settings, and current network conditions. These are general explanations and don’t mean 4BVPN offers every protocol listed.
- Shadowsocks: A family of encrypted proxy protocols. The client and server need compatible encryption methods and authentication parameters; entering only the server address isn’t enough.
- VMess: A proxy protocol with authentication and encryption mechanisms that can work with different transport methods. Its transport settings still need to match the server.
- Trojan: Typically uses TLS to establish a protected proxy connection. Incorrect certificate validation or server name settings can cause a handshake to fail.
- VLESS: The proxy protocol itself doesn’t provide encryption. It’s commonly used with security mechanisms such as TLS or REALITY, so the name alone isn’t an encryption guarantee.
- Hysteria2 and TUIC: QUIC-based proxy protocols that rely on UDP. If your current network restricts UDP, connections may fail or perform poorly.
HTTP and SOCKS often appear in “local proxy” settings. They describe how an app hands requests to a client running on your device, and aren’t necessarily the protocols used to connect to a remote node. TLS protects communications, while WebSocket is one transport method; neither is the same thing as a node’s region.
Beginners should use a compatible configuration provided by the panel rather than manually assembling settings to get a particular protocol name. If you see a certificate error, check the device’s clock, server name, and configuration source. Disabling certificate verification shouldn’t be treated as a routine fix.
Direct, relayed, and dedicated routes: what’s the difference?
Route type describes the path a request takes; protocol describes how it’s transmitted. They can be combined in different ways: the same protocol can be used on a direct or relayed route. Seeing Trojan or VLESS doesn’t tell you whether a route is dedicated.
Direct and relayed routes
A direct route usually means the client connects straight to a server outside your region, with the cross-border path affected by your local carrier and public internet routing. A relayed route connects to an entry point first, then forwards traffic over an intermediate network to an exit point. Relays add hops, but a well-chosen route may avoid poor public internet paths, so fewer hops don’t automatically mean faster speeds.
IEPL dedicated lines
IEPL stands for International Ethernet Private Line. It’s a network transport method, not a proxy protocol. A service’s “dedicated line” may use this transport on some segments, but you still need to consider the path from your device to the entry point and from the exit point to the destination. A node name alone doesn’t prove that the entire route uses a dedicated link.
How to choose: Compare protocols for compatibility and routes for real-world performance. For everyday work, consider whether the connection stays available, the apps you use work properly, and performance holds up during your usual hours—not just the node name or a single latency reading. Don’t infer route capabilities that aren’t stated in public information.
Routing, Global Mode, and Rule Mode
Rule-based mode decides where requests go based on conditions—for example, sending local services directly while routing specific international websites through a proxy. Rules usually run in order, so an earlier match may take precedence over a fallback. The exact behavior depends on the client. After updating rules, check which ones match before switching nodes.
Global mode usually sends traffic that has already entered the client through the selected proxy policy. It doesn’t necessarily capture traffic from the entire device. If an app bypasses the system proxy, it may still connect directly even when the client is in global mode. “Global” describes the routing policy, not the scope of traffic capture.
A system proxy provides an entry point for apps that follow your device’s proxy settings. TUN or virtual network adapter mode receives more traffic at the network layer, but is still subject to routing, exclusions, permissions, and implementation. Enabling TUN doesn’t force every request through a proxy; rules may still send some traffic directly.
“Bypass local network” generally keeps local network access available. It isn’t exactly the same as routing domestic websites directly. If this conflicts with company systems, printers, or a remote-work tunnel, check the exclusions first and follow your organization’s network policies. Don’t overwrite company settings without permission.
How to check DNS resolution and leaks
DNS looks up the address associated with a domain name. If certain domains are expected to resolve remotely but their queries are unexpectedly sent to a resolver on your local network, that may be a DNS leak. DNS queries and website connections can take different paths, so checking your exit IP alone won’t tell you whether DNS behaves as expected.
Your browser’s secure DNS, system resolver, and client DNS module may all work independently. If a test page shows a local resolver, don’t draw conclusions without checking your routing policy: local resolution may be expected if local domains are meant to connect directly. Likewise, seeing a resolver outside your region doesn’t prove that every app’s traffic is being captured.
Fake-IP is a mechanism some clients use to associate domains with connections: the client returns a synthetic address first, then handles the actual connection. It doesn’t fake your exit region, and an unfamiliar resolution address doesn’t necessarily mean something is misconfigured. If company domains or local network services stop working, check the client’s documentation for exclusion rules.
Steps from import to verification
Windows and macOS clients may offer separate system proxy and TUN switches. iOS and Android clients commonly use the system VPN interface to receive traffic, but the actual capture scope still depends on the configuration. Linux may also require separate system proxy, routing, or service permissions, and terminal apps may not automatically use the desktop proxy settings.
The same client may have different interfaces and capabilities on different platforms, and import methods may depend on the link format. Don’t force an import based only on a file extension; follow the quick start guide for your platform. You can find the client download in the user panel.
- Get the right configuration: Copy the subscription link for your client from the panel. Check for extra spaces, and don’t use a regular webpage URL in place of a configuration link.
- Import and update: Check that the nodes and any required proxy groups appear. If an update fails, check the link, network, and client compatibility first. Don’t keep creating duplicate configurations.
- Select the policy in use: Find the proxy group used by the target rule, choose a node, then enable the system proxy or TUN mode if needed.
- Verify separately: Visit Network Check to see your browser’s exit, then check the target app. A working browser connection doesn’t mean other apps are using the proxy.
- Identify where it fails: Distinguish between failing to fetch a configuration, a node connection failure, a rule not matching, and the target service denying access. Then check FAQs for the relevant fix.
- ✅ After importing, check which configuration is active; don’t just look for nodes in the list.
- ✅ Check the rules, proxy group, and exit region to confirm where the target app’s traffic goes.
- ✅ Check DNS and the app’s connection. After changing settings, reconnect before testing again.
- ❌ Don’t treat a successful latency test as proof that a website is reachable or that your account region meets its requirements.
- ❌ Don’t share your full subscription link as a routine troubleshooting step.
If the connection works but a website remains unavailable, check your account region, service availability, website status, and the reputation of your exit IP. A proxy can’t replace account eligibility or guarantee that a streaming or AI service will accept a particular exit.
Understanding Subscriptions in Plans
Once you understand the technical terms, take a look at the billing details. 4BVPN monthly plans are ¥9.9/month for 60GB, ¥18/month for 250GB, and ¥28/month for 500GB. Data resets monthly on the activation date; if you upgrade mid-cycle, the price difference is prorated for the remaining days. Here, “subscription” means a plan and is different from the configuration subscription link in your client.
Data packs cost ¥158/300GB, ¥358/1000GB, and ¥658/3000GB. They never expire and last until used. There’s no limit on the number of devices online at once, but data isn’t unlimited—keep your plan’s data allowance in mind when using multiple devices. See Plans and data packs for details.
4BVPN doesn’t require an email address. Create an account with a username and password. Its privacy policy states that it doesn’t keep logs. This is separate from your device’s DNS and routing settings, which still need to be configured correctly. The service offers a 7-day no-questions-asked refund.
In short: Subscriptions provide configurations, nodes are connection endpoints, protocols define communication, routes determine the path, and rules decide where requests go. When something goes wrong, identify the layer first, then change the relevant setting. A compatible configuration that reliably does the job matters more than piling on unfamiliar switches.