This VPN glossary for beginners starts with the settings in your client: a node is a connection endpoint, a route is the path traffic takes, and a protocol is how it communicates. Split tunneling and global mode determine how requests are routed. Understanding these layers helps you tell whether a problem lies with importing a subscription, connecting to a route, or an app bypassing the proxy.
Nodes vs. Routes: Connection Endpoints and Traffic Paths
A node usually refers to a connection profile you can select in your client. It includes a server address, port, authentication details, and protocol settings, and may also have a region label. Selecting a node tells the client to connect using that profile. Node names are labels set by the provider, not proof of performance; similarly named nodes may use different entry points or exits.
A route describes how traffic is carried from your local network to an exit and how that path is organized. The entry point is where your client connects first; the exit is the source location a destination website sees. The entry region, node name, and region associated with the exit IP may differ. If you need a specific exit region, check it after connecting rather than relying on the region shown in the list.
| Type | How the route works | What to consider |
|---|---|---|
| IEPL private line | An international Ethernet private line that may serve as a dedicated transport segment within a service route. It does not mean the entire path from your device to the destination website uses a private line. | The actual access route, exit region, and whether the target app works consistently. |
| Relayed | The client connects to an entry point first, which forwards traffic to another server or exit. The relay segment may use different transport methods. | Connectivity from your local network to the entry point, the forwarding path, and exit status. |
| Direct | The client connects straight to the remote proxy server, with no separate service relay entry point. This does not mean the connection bypasses internet routing. | The route from your local carrier to the remote server, and how it performs at the time you use it. |
Route types and proxy protocols are separate classifications. A relayed route can carry different proxy protocols, and nodes using the same protocol may take different paths. So using a particular protocol does not prove that a private line is in use, nor does it guarantee a particular speed or level of stability.
VPNLQ offers IEPL private lines, relayed connections, and direct connections, covering 110+ countries and 170+ routes. This breadth gives you more options; it does not mean every destination service supports every exit region. Check the global server locations, then choose based on your client’s current settings and actual results.
Subscriptions and data: Configuration updates don’t renew your plan
In a client, “subscription” usually means a configuration subscription: the client retrieves a node list and related settings from a subscription URL. In an account panel, a “monthly subscription” refers to billing. Refreshing a configuration subscription updates connection details; it does not add data or renew your plan. Knowing the difference helps avoid mistaking a successful update for a restored account allowance.
A subscription link typically contains account-related access credentials. Treat it as private—not like an ordinary public webpage URL—and don’t share it in group chats, public repositories, or screenshots. Import it using the client-specific option provided in your service panel. Different clients may read different configuration formats, so not every link works as a universal configuration.
If the node list is empty, first check where you retrieved it, your account status, and client compatibility. If nodes appear but connections fail, check whether the configuration has expired and whether the selected node has changed. Follow the client and service guidance on refresh frequency; repeatedly refreshing won’t make it faster. If a link is exposed, reset it using the option in your panel and replace the old subscription on your devices. If you can’t find the reset option, contact support through a ticket.
VPNLQ monthly plans are ¥9.9 / 60GB, ¥18 / 250GB, and ¥28 / 500GB. Data resets monthly on the activation date; mid-cycle upgrades are prorated based on the remaining days. Data packages are ¥158 / 300GB, ¥358 / 1000GB, and ¥658 / 3000GB; they remain available until used and never expire. Check billing and data rules on the plans page. Don’t use the client’s subscription update time to estimate your reset date.
Common protocols: How they work and client compatibility
In everyday use, “VPN” is often a catch-all for tools that provide international network access. Technically, traditional VPN tunnels and application proxies are not exactly the same. Proxy protocols describe how a client and server authenticate, encapsulate, and transmit requests. Whether they cover the whole device also depends on system proxy settings, virtual network interface routing, and how each app handles network traffic.
| Protocol | What it is | Compatibility considerations |
|---|---|---|
| Shadowsocks | An encrypted proxy protocol that can forward TCP and UDP traffic. | The client must support the encryption method in the configuration; plugin support may also affect import. |
| VMess | A proxy protocol with authentication and encryption that can be used with different transport methods. | The protocol, transport method, and TLS settings must all match. Checking the protocol name alone is not enough. |
| Trojan | Typically carries proxy traffic over a TLS connection. | Check that certificate verification, server name, and related settings are correct. |
| VLESS | A lightweight proxy protocol that does not encrypt content on its own. Its security depends on the specific security and transport settings used with it. | Confirm that the client supports the chosen transport and security settings; VLESS support alone is not enough. |
| Hysteria2 | A QUIC-based proxy protocol that relies on UDP. | Both the client version and whether the network allows the required UDP traffic can affect the connection. |
| TUIC | A QUIC-based proxy protocol that supports traffic forwarding. | Match the protocol version, authentication, and transport settings, and check UDP connectivity. |
This table explains terminology; it is not a list of protocols supported by VPNLQ. Check the panel’s subscription and client instructions for currently supported protocols. A newer protocol is not necessarily a better fit for your network: UDP restrictions, client implementation, and server configuration can have a more direct impact than the protocol name.
If an import fails, don’t remove TLS, authentication, or transport fields just to “simplify” the configuration. They may be required to connect. Don’t turn off certificate verification as a routine fix, either. First check your system clock, server name, subscription source, and client compatibility.
Rule Mode vs. Global Mode: Route Traffic After It Enters the Client
Split tunneling routes requests based on domains, destination IPs, apps, or other conditions. Rule mode applies the rules in the order configured; common actions include direct, proxy, and reject. In general, the first matching rule determines how a request is handled. Requests that don’t match a specific rule follow the final rule in the configuration. Exact behavior depends on the client.
A policy group sits between rules and nodes. For example, a rule can send a type of request to a policy group, which then selects the current node or automatically chooses from a set of candidates. If you see “rule matched proxy group,” that doesn’t mean the group selected the exit you expected. If the region is wrong, check the group’s current selection too.
Global mode typically sends all traffic that has entered the proxy client through the selected proxy policy. It does not mean that every app is being captured. If an app ignores the system proxy or a request never enters the client, switching to global mode won’t change its route. Direct mode typically sends captured requests straight to their destinations without using a remote proxy exit.
For everyday use, start with rule mode to avoid unnecessary remote routing. If a site won’t load, you can briefly switch to global mode for comparison. If it works in global mode, check the rules and policy groups first; if it still fails, check the node, DNS resolution, and app status. Restore your original mode after testing so a temporary troubleshooting setting doesn’t become your permanent configuration.
System Proxy, TUN, and Platform Differences
A system proxy provides an entry point for apps that follow the system settings. Browsers may use it, but command-line tools, games, and some background processes may have separate settings. If a developer can browse the web but terminal requests fail, check whether the tool reads proxy environment variables or supports an explicit proxy before assuming the node is at fault.
TUN mode typically captures IP traffic through a virtual network interface and routing settings. It often covers more traffic than a system proxy, but is still affected by route exclusions, client implementation, and system permissions. TUN is not a remote proxy protocol, nor does it automatically guarantee that every request uses a remote exit. Read the client documentation before enabling it, especially if other network tools may cause routing conflicts.
Windows and macOS clients may offer separate system proxy and TUN options, with different authorization requirements. iOS and Android often use the system VPN interface to create a traffic-capture tunnel. A VPN indicator means the tunnel is enabled; it does not confirm that every destination request connected successfully. Linux clients may also require separate permission, routing, and DNS configuration.
VPNLQ supports Windows, macOS, iOS, Android, and Linux, with no device limit. Platform support does not mean every client has the same menus or import format. Sign in to the panel to get the client, then follow the quick start guide. Don’t assume the same interface steps apply across platforms.
DNS Resolution and Leaks: Domain Lookups Happen Before Connections
DNS translates domain names into addresses needed to connect. Even if the proxy connection works, an app may fail to load if domain lookups fail or return unsuitable results. DNS resolution and the connection itself may also take different routes: a browser’s built-in encrypted DNS, system resolver settings, and the client’s DNS module may all play a role.
A DNS leak generally means a domain lookup that was expected to use a specified proxy or tunnel path actually took a different resolver path. This may expose the queried domain or cause routing to differ from what you expected. But seeing the name of a particular resolver on a test page once does not, by itself, prove which network path the query took.
Start by checking the client’s DNS policy, then see whether the browser has its own encrypted DNS setting and whether the app resolves names independently. In rule mode, local DNS for domains intentionally set to connect directly is not necessarily a leak; compare it with the intended policy. Some clients’ Fake-IP mode returns a synthetic address first, then maps it to the real destination within the client. That does not mean the website’s server actually uses that address.
IP lookup can check the exit used by requests from your current browser. It cannot prove on its own that every app, DNS query, or UDP connection follows the same path. To assess privacy and traffic capture, consider your configuration, actual requests, and the connection details visible in your client.
Import and Troubleshooting: Turn Terms into Steps
- Check your account and configuration source. VPNLQ requires no email address; create an account with a username and password. After signing in, get your subscription from the panel overview and check your plan status.
- Use the right import option. Import using the format for your platform and client. If you see an unsupported protocol message, check the client version and compatibility notes first; don’t edit authentication fields manually.
- Refresh the list and select a node. Make sure the list has loaded, select the exit region you need, then confirm the policy group is actually using that node.
- Enable the right traffic-capture method. Test browser access and terminal requests separately. For broader traffic capture, configure TUN or the system VPN tunnel as described in your client’s documentation.
- Test one setting at a time. Keep the other settings unchanged and test the node, rule mode, global mode, and DNS path separately. Change just one condition per test so you can interpret the result.
- Share reproducible details. Note your platform, client name, error message, selected mode, and which traffic is affected. Hide access credentials, then send the details through a support ticket in the panel.
- ✅ The node list has loaded, so the configuration is readable. You still need to confirm the connection and access to your destination.
- ✅ Once the browser exit matches your expectations, test the app you actually need to use.
- ❌ Don’t treat a node name, protocol name, or “connected” icon as proof of performance or coverage.
- ❌ Don’t share subscription links or leave certificate verification disabled as a long-term workaround.
Finally, assess network connectivity separately from the destination service’s account rules. A proxy exit can change your network route, but the destination platform may still determine access based on account region, permissions, or other conditions. VPNLQ’s “anonymous, no logs” statement describes its privacy policy; it does not mean a destination website cannot identify an account after sign-in. Understanding these terms helps you know what each setting can change—and what it cannot tell you.