Confirm it’s working: distinguish connection status from actual traffic
How can you tell whether your VPN is working? Don’t rely on the connection icon alone. Compare your public IP, check how DNS queries are resolved, and confirm which rule applies to the app you’re testing. Consider these results together: a changed browser IP only shows that this web request used a different route; it doesn’t prove that all your apps use the VPN.
“Connected” can mean that a local proxy is listening or that the system has established a virtual network interface. The exact meaning varies by client. Even if a node test succeeds, your browser may connect directly if the system proxy is off. Conversely, some sites may stay on a direct connection in rule-based mode, which can be expected.
Before you start, decide what you expect: should only selected sites use the proxy, or should all supported app traffic go through the tunnel? Test against that goal. Successfully importing a subscription only means the configuration was read. Whether a node connects and how traffic is routed also depend on the client’s core, the selected configuration, and your network.
What to look for: An access attempt is working as intended only when it matches the expected rule, uses the expected exit route, and the app completes a real task. A connection icon, latency test, or location label alone isn’t enough.
Public IP check: establish a direct-connection baseline
Disconnect the client, then open the network test page in your browser. Note your current public IP, network provider, and the location shown on the page. Connect to the node you want to test and refresh the same page in the same browser. Keep your network unchanged if possible; switching from Wi-Fi to mobile data can change the baseline.
- Note the results while disconnected, and make sure the test page isn’t showing cached results.
- Select a node in the client, enable the proxy or tunnel mode you want to test, and wait for the connection status to stabilize.
- Check your public IP again, then review the client’s connection log to see which policy was applied to the test domain.
- Open the site or app you actually want to use and complete a real task, such as loading a page or signing in.
If your IP hasn’t changed, first check whether a rule sends the test domain directly. Don’t assume the route is broken. If needed, temporarily route that domain through the proxy and restore your original settings after testing. If the IP changes but the location label doesn’t match the node name, that doesn’t necessarily mean you chose the wrong node. Geolocation databases can be out of date, and a node name may refer to the entry point rather than the final exit. Check the network provider and service dashboard as well.
Check both IPv4 and IPv6. Some setups proxy only one address family, while your browser may prefer the other route. If your test tool can check them separately, test each one. If it doesn’t detect IPv6, that doesn’t confirm that IPv6 routing is correct; your network may simply not have an IPv6 connection available.
DNS check: DNS resolution isn’t the same as your traffic’s exit point
DNS translates domain names into IP addresses, while routing determines how the subsequent web connection travels. Even when a proxy connection is working, DNS queries may still go through your local network. Your browser may also use encrypted DNS instead of the system settings. So check the web traffic route and DNS path separately.
When using a DNS leak test, first check what it actually displays. Many tests trigger lookups for test domains and identify the recursive DNS resolvers involved. The provider and location shown don’t necessarily mean your device sent an unencrypted request directly to that location. Public DNS services may use distributed infrastructure, so multiple locations in the results don’t automatically indicate a leak.
The more useful questions are: if your policy requires DNS to use the proxy, are queries still going to your local ISP? Has the client enabled DNS interception? Is your browser’s secure DNS overriding system settings? Do your rules send some domains to local DNS and others to remote DNS? Compare these settings with the test results.
- ✅ Note the client’s DNS mode, your browser’s secure DNS setting, and the network used for the test.
- ✅ Check the client logs to see which DNS and connection policies applied to the test domain; don’t rely only on the country shown in the results.
- ✅ After changing DNS settings, restart the relevant apps or clear their cache as instructed by your system, then repeat the same test.
- ❌ Don’t conclude that the VPN isn’t working just because the DNS provider’s name differs from the node name.
In Fake-IP mode, the client may first return a locally mapped address to the app, then use the domain name to establish the real connection. In this case, the address shown by a command-line lookup may not be the website server’s address. Don’t switch to a random DNS service just because an address looks unusual. Check the client’s DNS mode first to avoid disrupting split tunneling.
App-by-app testing: a working browser doesn’t mean every app is covered
A system proxy usually provides settings only to apps that support it; it doesn’t force every program to use the proxy. A virtual network adapter or system VPN tunnel can route traffic at the system level, but exclusions, bypassed addresses, and protocol limitations may still apply. “Global mode” can mean different things, too. Some clients route all requests that reach their proxy core through the proxy, without capturing apps that bypass the core.
| App or tool | What to check | Common false assumption |
|---|---|---|
| Browser | Public IP, extensions, secure DNS, and which rule applies to requests | A browser extension uses a proxy, so the entire system must be covered |
| Desktop apps | The app’s proxy settings, client connection logs, and an actual task | The system proxy is on, so the app must be using it |
| Command-line tools | Proxy arguments, environment variables, and supported proxy types | The website works, so command-line tools must use the same route |
| Mobile apps | System VPN status, excluded apps, background operation, and network changes | The VPN icon is still visible, but the app being tested is excluded from the tunnel |
On Windows, macOS, and Linux, command-line tools may rely on their own options or proxy environment variables. Don’t assume they use the same route as your browser. Android clients may offer per-app proxy settings or exclusions. iOS clients usually work through a system network extension, but the coverage still depends on the configuration. Adjust your tests for the platform.
For a practical test, close the app, clear or mark the client’s current connection logs, then reopen the app and perform a specific action. Check whether the relevant domain, process, or connection appears, and whether it matched a direct, proxy, or reject policy. Some clients don’t show process names; you can use the request time and domain instead. Don’t mistake unrelated background traffic for your test.
Connected but not routing: troubleshoot in dependency order
Change one setting at a time and note its original value. Changing the node, DNS, client, and rules all at once makes it impossible to identify the cause. Work through the checks below instead of repeatedly importing the same subscription.
- Check the configuration source and compatibility. Get the current subscription from your dashboard and make sure your client supports its protocols and configuration format. Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC aren’t interchangeable. Importing a configuration successfully doesn’t mean the client’s core supports every option in it.
- Check local traffic capture. Make sure the system proxy or tunnel is actually enabled, the required system permissions are granted, and no browser extension or other network tool is overriding the settings.
- Check which rule applies. Review the target domain, app exclusion list, and final policy. A direct route may be intentional rather than a node failure. If the policy rejects the connection, first check where that rule came from.
- Check node reachability. Review the actual connection error and distinguish a DNS failure from a handshake failure or timeout. A client’s latency test often checks only a specific probe destination; it can’t prove that the target site is reachable.
- Check the target service. If the exit IP and route are as expected but the site still denies access, check account permissions, regional policies, service outages, or the reputation of the exit IP. Don’t assume the proxy is completely ineffective.
IEPL dedicated lines, relay routing, and direct connections describe how a route is organized; they don’t prove that a device is routing traffic through it. IEPL typically involves a dedicated transport segment, relay routing forwards traffic through an intermediate node, and a direct connection skips that kind of relay. Whatever the route, an excluded app or a direct-connection rule won’t change just because of the route’s name.
Retest notes and final conclusion
A test only reflects the network and configuration at that moment. Recheck important apps after switching nodes, resuming from sleep, changing networks, or upgrading the client. Record the client version, connection mode, node name, test domain, exit result, and any errors. There’s no need to keep full screenshots that contain access credentials.
After testing, restore the rules you need for everyday use. Switching everything to the proxy for a test doesn’t mean that mode is best for long-term use. Split tunneling should route the traffic you choose through the specified path while leaving permitted traffic on its usual route. Judge the setup by whether it follows your rules, not by whether every test page shows the same location.
Network testing and privacy policies are separate matters. An IP check can’t show whether a service logs activity, or remove app-level identifiers such as account sign-ins and browser fingerprints. VPNK9’s privacy policy is “no logs”; this is a service policy, not an anonymity guarantee that can be verified just by seeing your IP change.
Bottom line: Compare your public IP to confirm the request route, check DNS to verify name resolution, then test each app you need. If anything differs from what you expect, troubleshoot local traffic capture, rules, the node, and the target service in turn. Don’t rely on a “Connected” status alone.
If you haven’t set up a client yet, see the quick-start guide. VPNK9 doesn’t require an email address; use a username and password to get started, then retrieve your subscription after signing in. Download Windows, macOS, Android, and Linux clients from the downloads page after signing in. The iOS link requires an active plan. After importing your subscription, follow the steps in this guide to verify your connection.