Here’s the key relationship to remember: a subscription provides configuration, a node is a connection endpoint, a route is the path data takes, a protocol defines how it communicates, and split tunneling determines which requests use the proxy. These are different things. A client showing “Connected” doesn’t guarantee that a particular website is reachable.
Subscriptions and plans are not the same thing
“Subscription” means different things on a service’s website and in a client. On a plans page, a monthly subscription refers to billing; in a client, it usually means a source of configuration. A subscription link lets the client retrieve details such as server addresses, ports and protocol settings. Depending on the configuration format, it may also include proxy groups, routing rules and DNS settings.
Copying a subscription link doesn’t install a client or open a website. Typically, you get the link from your account panel, choose the import or add-subscription option in a compatible client, then refresh it. The client reads the content returned by the link and creates a list of available nodes or configurations. If the service updates its configuration, you may need to refresh the subscription to see the changes.
Subscription links often contain credentials that can identify your account, so protect them like passwords. Don’t post the full link in public comments, screenshots or unfamiliar online conversion tools. If you need to share troubleshooting details, provide the error message and client name instead. If the link is exposed, reset it through the panel if that option is available, then update it on devices where it was imported.
Nodes and routes: what’s the difference?
A node is a connection configuration you can select in your client. The region in its name usually suggests the exit location, but the name alone doesn’t verify it. The entry address may be in another region, and backend routing can determine the exit location seen by websites. So you can’t tell where your data travels just by looking at a node name.
A route describes the path and resources used to carry traffic. Direct typically means the client connects straight to the proxy server. A relayed route passes through an access or forwarding server before reaching the exit. An IEPL dedicated line refers to dedicated transport resources along part of the route. It doesn’t mean the entire path from your device to a website avoids public networks; your local connection and the route from the exit to the destination still affect performance.
| Client term | What it means | Common misconception |
|---|---|---|
| Subscription link | A way for the client to retrieve configuration | Mistaking it for an installer or a regular webpage |
| Node | A server configuration you can connect to | Assuming the node name proves the exit location or access result |
| Direct | A route that connects straight to the proxy server | Assuming fewer hops always means faster speeds |
| Relay | A route that enters the network through a forwarding server | Assuming every relayed route uses a dedicated line |
| IEPL dedicated line | Part of a route that uses dedicated transport resources | Assuming a dedicated line guarantees access to every platform |
When choosing a route, first check which region the service requires, then test actual access. A client’s latency test usually checks only a specific probe request; it doesn’t directly measure continuous video playback, file transfers or responses from AI tools. A failed test may simply mean the probe address is unreachable, so check the service you actually use. See route information on the Nodes page, and verify access for your specific needs.
Protocols aren’t a speed ranking
A protocol defines how a client and server exchange data. Shadowsocks is a proxy protocol; VMess, Trojan and VLESS also require compatible implementations and settings on both ends. Trojan typically uses TLS. VLESS security depends on the transport and security layers it’s paired with, so the name alone doesn’t tell you how the connection is protected.
Hysteria2 and TUIC use QUIC-based transport and rely on UDP. If a network restricts UDP, connection performance may suffer. A newer-sounding name doesn’t make either protocol suitable for every environment. TCP connections are also affected by congestion, packet loss and server conditions. Choose a protocol based on client compatibility and your network connection.
Your client can connect only with configurations supported by the server. Don’t casually change a node’s protocol field to a different name, and don’t assume every client supports the same subscription format. If an import fails, first check the format provided in your panel and whether your client supports it, rather than repeatedly switching nodes. These are general terms; this list doesn’t mean VPNQA offers every protocol mentioned.
Split tunneling determines where requests go
Split tunneling uses rules to route requests. Common actions include connecting directly, sending traffic to a proxy group or rejecting the connection. Rules can match details such as domain names, destination addresses or processes, depending on the client. Most rule engines check rules in order, so a broad rule near the top may match first and prevent more specific rules below it from taking effect.
Rule-based mode routes traffic according to your configuration, making it useful when you need both local services and international websites. Global mode typically sends traffic intercepted by the client through the selected proxy; it doesn’t automatically capture every app on your device. Direct mode typically sends intercepted requests without a proxy, but check your client’s documentation for the exact behavior.
“System proxy” and “global mode” aren’t the same thing. A system proxy lets apps that follow the system settings use a proxy endpoint; apps that ignore those settings may still connect directly. TUN mode captures more IP traffic through a virtual network interface. It usually involves permissions and routing settings, and may still have exclusions. It doesn’t guarantee that all traffic is covered or that you’re anonymous.
Rule-based mode is a good starting point for everyday use. If an app doesn’t work, temporarily switch to global mode for comparison. If it works, check your rules, proxy group and DNS settings first. If it still fails, look at the node or restrictions imposed by the service. When you’re done comparing, switch back to your original mode to avoid changing your account region, route and metered traffic all at once.
DNS and location checks
DNS translates domain names into network addresses. Visiting a website involves both connecting to its server and resolving its domain name. If DNS queries take a different route than expected, the queried domain may be exposed, or the result may not match the connection’s exit location. That’s the key concern behind DNS leaks; seeing a local DNS address alone isn’t enough to draw a conclusion.
The client, operating system and browser may each use their own DNS settings, including encrypted DNS in the browser. Encrypted DNS mainly protects DNS traffic in transit; it doesn’t guarantee that queries go through the proxy. Check the client documentation and DNS records to find out which component makes the query, which route it takes, and how rules handle the response. Don’t disable protections such as certificate verification just to troubleshoot.
A platform may also consider your exit IP address, account region, payment details, device location and existing sessions. Connecting through a Japan node doesn’t mean a platform will treat your account as Japanese. And a region restriction doesn’t necessarily indicate a DNS leak. Diagnose whether the issue is “DNS resolution failed,” “connection failed” or “access denied by the platform” before deciding whether to change network settings or check account requirements.
Client differences and import steps
Windows and macOS clients commonly offer system proxy and virtual network interface settings. iOS typically routes traffic through a system network extension. Android clients often use the system VPN interface and may support per-app routing. On Linux, you may need to configure services, permissions and routes separately. Settings with similar names don’t necessarily work the same way on every platform.
VPNQA supports Windows, macOS, iOS, Android and Linux. Check the relevant guide for client configuration formats, permission requirements and background operation. In particular, distinguish between “configuration imported,” “proxy service running” and “the target app is actually using the proxy.” Don’t rely on the status bar icon alone.
- Get your configuration. Sign in to the panel, follow the guide for your platform to get the subscription, and confirm that your client supports its format.
- Import and refresh. Check that the node list appears and that the update completes without errors. If import fails, troubleshoot the format or how you obtained it first.
- Choose a node and mode. Pick a region that suits your needs, start with the mode recommended in the guide, and don’t run conflicting proxy tools at the same time.
- Test the app you need. Open the target website or app and try the task you need to complete. Don’t rely on latency test results alone.
- Keep reproducible details. Note the error message, platform, client and mode. Change one thing at a time, then repeat the same steps.
Data usage, resets and troubleshooting checklist
Data usage is the total amount of data transferred; bandwidth describes transfer capacity, and latency measures response time. These are not interchangeable. A higher data allowance doesn’t mean a route will be faster. Check the service’s metering policy to see how uploads and downloads count toward usage, and don’t estimate your full bill from the size of one downloaded file.
VPNQA monthly subscriptions reset data each month on the activation date, not at the start of a calendar month. If you upgrade mid-cycle, the price difference is prorated for the remaining days. Data add-ons remain available until used and never expire. A subscription suits ongoing use, while an add-on lets you manage usage over time. Compare prices and allowances on the Plans page.
- ✅ No nodes in the list: Check subscription retrieval and import status first, then check format compatibility.
- ✅ The node connects, but the app doesn’t: Check whether the client is capturing the app’s traffic and whether the rules match the right proxy group.
- ✅ The website opens but shows a region restriction: Check the exit route, account requirements and the platform’s decision separately. Don’t assume it’s a route failure.
- ✅ Long transfers are unstable: Compare different network connections and routes, and check whether the operating system is suspending the client.
- ❌ Changing the node, protocol, DNS and rules at the same time: Too many variables change together, making the cause impossible to identify even if things start working again.
Still stuck? See common questions on the Support page, or share sanitized troubleshooting details through the Contact page. A clear description of when the error occurs and how to reproduce it is more helpful than a screenshot that just says “Connected.”