Start with how the pieces fit together: your plan determines your usage allowance, a subscription link provides configuration, the client reads that configuration, a node gives you a connection endpoint, a route carries the traffic, and rules determine which requests use the proxy. These are different things, and one cannot substitute for another when troubleshooting.
People often use “VPN” as a catch-all term for network acceleration services, but proxy clients and system-level VPN tunnels are not exactly the same. Some clients only configure a system proxy; others route traffic through TUN or a system network extension. Seeing a VPN indicator on your device only means that the relevant network interface is enabled—it does not prove that every app is using the proxy.
Subscriptions and subscription links: keep usage and configuration separate
“Subscription” commonly has two meanings. A plan subscription is a billing arrangement that defines your data allowance and reset schedule. A client subscription is a source of configuration, usually provided as a link. Buying a plan does not automatically connect your device, and copying a link does not activate an allowance. Check your plan status in the dashboard, then confirm that the client has successfully loaded the configuration.
A subscription link usually contains credentials used to identify your account. When a client accesses the link, it retrieves node parameters and may also retrieve rules, proxy groups, and DNS settings. The exact contents depend on the subscription format and what the client supports. A link importing successfully into one client does not mean every client can read it.
“Update subscription” means fetching the configuration again—not renewing your plan or resetting your data. If the service changes connection addresses or adds nodes, an update may change the list. If your allowance is depleted, refreshing the configuration will not restore your plan access. Treat subscription links like account credentials: do not post them publicly or submit them to untrusted online conversion tools.
When asking for help, hide subscription links, access tokens, and node passwords in screenshots. If a link has been exposed, look for a reset option in the dashboard first. If there is none, contact support, then update the configuration on your devices.
Nodes and routes: connection endpoints and traffic paths
A node is a connection profile you can select in a client. It may include a server address, port, protocol, and authentication parameters. Node names often suggest a region or purpose, but the name itself is not proof. The entry point’s location may differ from the final exit location, so you cannot determine the region a website will see from the node name or entry IP alone.
A route describes the path data takes from your local network to the exit server. Different nodes may share some entry points, backbone links, or exit resources. A long node list therefore does not mean every node has entirely separate network capacity. Whether switching nodes helps depends on the actual route and results.
| Route type | What it usually describes | What to check |
|---|---|---|
| Direct | The client connects to the destination server over the public internet, without a separately configured relay entry point | Routing, congestion, and connectivity from your local carrier to the destination |
| Relayed | Traffic reaches a relay entry point first, then goes on to another server; the second leg is not necessarily a dedicated line | Entry-point reachability, the onward route, exit performance, and peak-hour experience |
| IEPL dedicated line | Usually refers to a segment of the route carried over an international Ethernet private line | Which segments use a dedicated line, and whether the entry and exit are still affected by the public internet |
IEPL describes the transport infrastructure; it is not a proxy protocol and does not guarantee access to any particular website. A dedicated-line label is no substitute for testing. Your local wireless network, entry-point congestion, exit load, and restrictions at the destination can all affect performance. Lower route latency does not necessarily mean higher download throughput.
For VPNKQ’s actual coverage and node details, visit the servers page. Check the route list and test the connection to confirm route types and access results for a specific region; do not assume every node offers the same coverage as the brand overall.
Protocols and clients: can the configuration run correctly?
A protocol defines how a client and server communicate. Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC are common protocol names, not speed tiers or platforms. Whether a protocol works depends first on whether the client’s core supports it and its specific parameters.
The encryption method for Shadowsocks must match on both ends. VMess has its own authentication and protocol mechanisms. Trojan is typically used with TLS. VLESS does not encrypt the payload by itself, so its security depends on the transport configured alongside it. Hysteria2 and TUIC are based on QUIC and generally rely on UDP network conditions; if your current network restricts UDP, switching to one of these protocols may not fix the connection.
Beyond the protocol name, check the transport, TLS settings, server name validation, and authentication details. Removing an unsupported field may make a configuration pass validation while changing how the connection behaves. Do not disable certificate verification just to clear an error. First check the device clock, server name, and configuration source.
Setup options vary by platform
Windows and macOS clients may offer system proxy, TUN, or network extension options. Clients on Android and iOS usually need system permission to create the relevant network interface. Exact buttons and permissions vary by client, so do not assume an option on one platform has the same name or behavior on another.
The client runs the configuration; its core handles proxy connections. Similar-looking interfaces do not mean the underlying cores have the same capabilities. Check the service’s compatibility notes before importing. To get a VPNKQ client, visit the client downloads page. You must sign in first; the dashboard determines download access.
Split tunneling, global and rule modes: which traffic takes which route
Split tunneling uses conditions to decide whether a request connects directly, goes through a proxy, or is blocked. Conditions may be based on domains, destination IPs, processes, or rule sets, depending on the client. A proxy group is a set of destinations rules can use as proxy exits. You may select a node manually or, in some clients, let the client choose automatically. A proxy group is not a new transport protocol.
Rule mode matches requests against configured rules and sends each match to the designated exit. Many clients use a first-match-wins approach, but check the documentation for your client’s core. A broad rule placed near the top may override more specific rules below it. Updating the node list and updating rules are separate actions.
Global mode usually sends all requests captured by the client through the selected proxy. The key phrase is “captured by the client”: with system proxy enabled alone, apps that ignore that setting may still connect directly. With TUN enabled, check routing, exclusions, and DNS settings too. Global mode does not mean every bit of device traffic goes through the proxy.
Direct mode usually makes requests captured by the client connect straight to their destinations. It can help with troubleshooting, but client DNS and other network settings may still affect results. If a website will not load, briefly compare rule mode with global mode. If it works in global mode but not in rule mode, check rule matches and proxy groups before changing plans.
Bottom line: For everyday use, configure rule mode according to your client’s compatibility instructions. For troubleshooting, switch modes temporarily and check the actual exit in the connection log. The mode name is only a policy setting; the real indicators are what traffic the client captures and which rules match.
DNS and leaks: domain lookups take a route too
DNS translates domain names into addresses that a device can connect to. A website request may go through a proxy while its DNS lookup still uses the local network. The reverse can also happen: a remote resolver handles the lookup, but the connection goes direct according to the rules. When checking DNS, examine where the lookup goes separately from where the connection goes.
A DNS leak generally means domain lookups are not sent through the expected protected path, allowing the local network or an unintended resolver to observe them. A different region shown for a resolver on a test page does not, by itself, prove a leak. Public resolver deployment, forwarding, and exit locations can all affect the result.
Browser Secure DNS, app-specific resolvers, and system DNS may all be active at once. DoH and DoT encrypt DNS requests, but encrypted DNS does not guarantee that requests use a proxy or prevent the resolver from seeing them. Check whether the client handles DNS, whether the browser uses a separate resolver, and whether rules cover DNS traffic.
Some clients use Fake-IP to assign synthetic addresses to domain names, then map them back to domains when connecting. This is a way to implement routing and DNS resolution, not the real address of the remote website. Do not assume a synthetic address shown by your system indicates a network problem, and do not copy DNS settings that are incompatible with your client’s core.
From import to verification: troubleshoot in order
Once the terms are clear, work through the steps in this order: account status, configuration, connection, rules, DNS resolution, and app behavior. Change one relevant setting at a time so it is easier to interpret the results and avoid introducing noise by repeatedly reinstalling the client.
- Check your account status. Confirm that your plan is active and data is available. VPNKQ does not require an email address; create an account with a username and password. Keep your account credentials and subscription link separate.
- Import a compatible configuration. Use the setup guides to choose a client and subscription format. After importing, make sure the configuration is enabled—not just saved as a link. If it fails to load, first check that the link is valid and the format is supported.
- Select a node and connect. Confirm that system permissions have been granted and the proxy setting or network interface is enabled. A connection test only confirms some aspects of connectivity; it does not prove that the target app is working as expected.
- Check your exit and test the app. Use the My IP page to see the exit used by your current browser, then test the target app. The browser’s result does not necessarily reflect how other apps connect.
- Check rules and DNS. If a node connects but a website will not load, review the connection log, rule matches, and DNS errors. For further troubleshooting, see the troubleshooting guide and share the error details with credentials removed.
- ✅ After importing, confirm that the newly imported configuration is enabled.
- ✅ When a rule matches, confirm that its proxy group has an available exit selected.
- ✅ After changing network settings, reconnect and test the target app instead of relying on the status icon.
- ❌ Do not treat speed-test results as a guarantee of access to every website at every time.
- ❌ Do not run multiple clients that take control of network traffic at the same time; proxy, routing, and DNS settings may interfere with one another.
Check your plan last, rather than assuming every issue is caused by an exhausted allowance. VPNKQ monthly subscription data resets each month on the activation date; data add-ons never expire and remain available until used. These are billing options, separate from protocols, rule modes, and node configuration. VPNKQ supports unlimited simultaneous devices and offers a 7-day no-questions-asked refund.
VPNKQ’s privacy policy states that it keeps no logs. This statement does not replace protecting your account credentials, checking where your client came from, or reviewing your DNS path. Understanding what each setting does is more useful for reliable everyday use than simply chasing more nodes or more complex configurations.