The short version: a subscription provides configuration, a node is a connection option, a route is the path traffic takes, a protocol defines how the connection works, and split tunneling determines which requests take which path. These are different things, and each may need to be checked separately when troubleshooting.
Proxy clients, encrypted proxies, and VPNs are often discussed together, but they don't all operate at the same network layer. A VPN icon in your system may simply mean the client is using the system's virtual network interface; it doesn't necessarily mean a traditional VPN protocol is running underneath. Understanding the terms below is more useful than judging by an app's name alone.
Subscriptions and Clients: Where Configuration Comes From
“Subscription” can mean two different things. On a plan page, it refers to a billing arrangement; in a client, a subscription link is an address used to retrieve configuration. Purchasing a plan doesn't automatically configure the client, and importing configuration doesn't mean the account has data available. Check your account status and local configuration separately.
Subscription links typically contain credentials. When a client reads one, it retrieves nodes and connection parameters, and sometimes policy groups, routing rules, or DNS settings. What can be imported depends on the link's output format and the client's supported features. A subscription link isn't an installer, and opening it in a browser won't switch your network on automatically.
“Update subscription” usually means fetching the latest remote configuration, not renewing an account. If a service changes its nodes, the local list may need refreshing. Whether manually added rules are preserved depends on how the client merges configuration. Save your own changes first; an update isn't necessarily a harmless refresh.
Nodes and Routes: A Label Isn't the Whole Path
A node is a selectable connection configuration in a client. It typically includes a server address, port, authentication details, and protocol parameters. A region may have multiple nodes, and differently named nodes may share some infrastructure. So the number of nodes doesn't tell you how many independent servers there are—or how much usable bandwidth is available.
A route is the path traffic takes between your device and the destination service. Traffic may reach an entry point first, pass through a relay, and then leave through an exit to reach a website. The entry point is where the connection enters the service network; the exit is the source location the destination sees. Check the service's documentation to see whether a node's region label refers to its entry or exit—don't assume from the name alone.
When accessing services in mainland China from abroad, first make sure you've selected a route optimized for access to China. For international websites, check the international route and exit region. A nearby location doesn't necessarily mean a shorter route, and a platform may also make decisions based on account region, content licensing, or the detected exit.
| Term | What it usually means | What you can't conclude from it |
|---|---|---|
| Direct | Your device connects directly to the selected server, without an additional application-layer relay provided by the service. | It doesn't mean the physical path is straight or that the connection will be faster; traffic still passes through carrier networks. |
| Relayed | Your device connects to an entry point, which forwards traffic to another server or exit. | An extra forwarding step doesn't necessarily make the connection slower; performance depends on the paths and load at each stage. |
| IEPL dedicated line | An international Ethernet private line, typically used to connect designated endpoints and potentially carry a cross-border segment of a route. | It doesn't mean the entire path from your device to a website uses a dedicated line, nor does it automatically include extra encryption or guarantee access to streaming services. |
These are general explanations, not claims about the configuration of every VPNBig route. Choose routes based on the service's published details and tests with your destination service. A client's latency test reflects only the response measured by its specific test method; it can't replace real-world file transfers, video playback, or work app performance.
Protocols: How the Two Sides Communicate
A protocol defines how a client and server authenticate, encapsulate, and transmit data. Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC are common names, but they aren't interchangeable switches. The client and server must support matching protocol configurations to establish a connection.
- Shadowsocks: An encrypted proxy protocol that requires a compatible encryption method and credentials. Support for specific methods varies across implementations.
- VMess: A proxy protocol with its own authentication and encryption mechanisms, generally used with transport-layer settings.
- Trojan: Typically carries proxy traffic over TLS. Certificate validation, server name, and authentication details must all be configured correctly.
- VLESS: The protocol itself doesn't encrypt traffic. It's typically used with a security layer such as TLS or REALITY, so its name alone shouldn't be taken as a promise of encryption.
- Hysteria2 and TUIC: QUIC-based proxy protocols that depend on UDP network conditions. The client and server must also support compatible implementations.
Terms like TLS, WebSocket, gRPC, and QUIC may appear alongside proxy protocols. They describe security layers or transport methods, not all interchangeable options at the same layer. More abbreviations in a node name don't mean better performance; correct configuration, client compatibility, and current network conditions matter most.
If your network restricts UDP, QUIC-based options may have trouble connecting. That doesn't mean your account is invalid or that every node is unavailable. Check the client's error message, then switch to a compatible option using the service's provided configuration rather than changing protocol parameters you don't understand.
Split Tunneling, Rules, and Global Mode
Split tunneling routes requests in different ways: connect directly, send them through a proxy, reject the connection, or pass them to a policy group. A policy group is a container for node selection. You can choose a node manually, or the configuration may switch nodes if one fails. It's a decision-making tool, not an additional physical route.
Rule-based mode typically matches conditions such as domain names, destination IPs, or app processes. Which conditions are supported depends on the client. Rules are usually evaluated in order, so an earlier match can determine the outcome; the final rule catches anything unmatched. Outdated rule subscriptions, poor rule ordering, or incomplete domain coverage can keep an app from using the proxy as expected.
Global mode generally means that traffic handled by the client uses the selected policy. It doesn't mean the client has taken over all traffic on your device. Apps that ignore the system proxy may still connect directly. To handle traffic at the system level, check the client's virtual network interface or TUN settings and permissions.
Routing every request through the same exit isn't always suitable when accessing services in mainland China from abroad. Services in China and local services abroad may need different routes. First make sure the target app uses the intended route, then check that other apps aren't affected. This is usually easier than repeatedly switching global mode to track down a problem.
Choosing a mode: For everyday use, start with rules that match the direction of access. Temporarily switching to global mode can help identify a split-tunneling issue, but it isn't a speed boost or a privacy guarantee.
DNS and Leaks: Check Domain Lookups, Too
DNS translates domain names into addresses needed to connect. Routing webpage content through a proxy doesn't mean DNS queries follow the same path. A DNS leak can occur when queries intended for a specified resolver or proxy are instead sent to your local network's resolver.
Encrypted DNS mainly protects queries in transit between your device and the resolver. It doesn't prevent the resolver from seeing the queries, and it can't replace proxy rules. A browser's secure DNS, system settings, the client's built-in resolver, and an app's own DNS behavior can interact, so checking just one setting isn't enough.
To troubleshoot, start by checking the client's DNS policy and connection logs to confirm that queries and subsequent connections are handled as intended. If you use a DNS test page, understand that it shows the resolver's apparent exit location; a country label alone doesn't prove there's a leak. Caching and the resolver's network layout can affect results. Comparing them with your expected configuration is more reliable than chasing a particular test label.
Importing a Client: From Configuration to Real Requests
Windows, macOS, Android, iOS, and Linux differ in system interfaces and permission models, and a mode with the same name may not cover the same traffic on each platform. Desktop clients commonly use either a system proxy or TUN to handle traffic; mobile clients often route traffic through the system VPN interface; on Linux, routing and DNS services may also need to work together. Refer to the client's documentation for specifics.
Don't confuse protocol support with configuration-format or feature support. A client that can parse a node may not support every rule or DNS field in its subscription. If the import looks fine but apps can't connect, compatibility may still be the issue.
- Get the client from an official source. Check supported platforms and setup instructions through the VPNBig client download page, and avoid installers from unknown sources.
- Check the configuration format. Get a subscription or configuration for your client from your account. Don't hand your credentials to an unfamiliar conversion service just to make an import work.
- Import and check the result. Confirm that nodes appear and no format errors are reported, then check your account status and data. If the import fails, first check whether the link was truncated, contains extra spaces, or uses an incompatible format.
- Choose a node for your access direction. Distinguish routes optimized for access to China from international routes, enable rules suited to the destination service, and grant any network permissions required by the system.
- Test with the target app. Once connected, open the content you need and check the exit and matched rules. If something goes wrong, troubleshoot one setting at a time instead of changing several at once.
If other network tools are running on your system, check for occupied proxy ports, routing conflicts, or overridden DNS settings. A client showing “Connected” usually means only that a connection or interface has been established; it doesn't prove that all apps are using it.
Troubleshooting Checklist: Pinpoint the Layer
The practical value of understanding these terms is being able to explain where something went wrong. Instead of just saying “it doesn't work,” share your operating system and client, connection method, exact error message, target app, and the conditions under which the issue occurs. Hide credentials in configuration screenshots, and never send your full subscription link.
- ✅ No nodes listed: Check the subscription format, link integrity, and fetch results before blaming route quality.
- ✅ Can't connect to a node: Check account status, protocol compatibility, authentication details, and whether your current network allows the required transport.
- ✅ Websites load but one app fails: Check whether the app follows the system proxy, whether a rule matches, and whether system-level traffic handling is needed.
- ✅ Connected, but content is from the wrong region: Check the exit region, account region, and platform rules. A successful connection doesn't guarantee access to specific content.
- ✅ Suspect an unusual DNS route: Compare DNS settings in the client, system, and browser, then check how queries and connections are actually handled.
Keep this relationship in mind: A subscription supplies configuration to the client; the client connects to a node using a protocol; traffic follows a route to an exit; and split-tunneling rules determine which requests take that path. Confirm the direction of access first, then check each layer. This is usually more effective than constantly switching nodes.
For help with specific steps, see the user guide. If your issue is with video playback, use the streaming guide to troubleshoot by symptom. This glossary doesn't replace configuration instructions, and you should still follow the destination service's access rules.