If your VPN connects but doesn't seem to work, don't rely on the client's “Connected” status alone. It usually means the client has connected to the selected route; it doesn't guarantee that traffic from your browser, system, and every app is being routed as expected. A more reliable approach is to check your public IP, DNS query path, and the results in specific apps. Consider all three together: a site's reported location or whether one app opens can be misleading on its own.
Before you start, note the selected route's location and whether the client is set to global mode, rule-based split tunneling, or proxying selected apps only. First, record the results with the VPN disconnected, then connect to the same route and repeat the checks. Use the same device, network, and browser for both tests to avoid mistaking a network change for a routing effect.
Check your public IP: what websites can see
Visit a reputable IP lookup site and note the public IP and approximate location it reports. Check once with the VPN disconnected, then reconnect and refresh the page. If the public IP changes and its location roughly matches the selected route, the lookup site's request is using a different exit. That doesn't prove every app on your device is using the same route. IP geolocation databases can take time to update, so a city mismatch alone isn't enough to diagnose a problem.
If both checks show exactly the same result, first see whether split tunneling is enabled: a rule may send the IP lookup site over a direct connection, or the current mode may only handle selected apps. Check another ordinary website and review the client's current mode. Don't draw conclusions with other proxy extensions active in your browser; an extension may only affect browser traffic, making its results differ from those of other apps on your system.
Check DNS next: which route handles lookups?
DNS translates domain names into addresses your device can connect to. A DNS leak is a potential concern when web requests use the selected route but DNS queries take a different path. Use a test page that shows the DNS resolvers, record the results with the VPN disconnected and connected, and compare them with the public IP results. If the connected test still shows resolvers associated with your local network, investigate further; don't conclude there's a leak based on the location shown by the test alone.
One common complication: your browser's “Secure DNS” setting may send encrypted queries directly to a chosen resolver, bypassing the DNS settings in your operating system. A test page showing a third-party resolver doesn't automatically mean your request bypassed the VPN. Also check the browser request's exit IP and whether your connection method routes those encrypted queries. Conversely, correct-looking system DNS settings don't replace testing in the browser itself.
For a closer look, temporarily compare the DNS test with Secure DNS enabled and disabled, then check the DNS settings in your client and operating system. Restore your original security settings when you're done. A command-line DNS lookup usually reflects only the resolver path used by that command; it doesn't necessarily represent your browser, games, or other apps. Test each one separately if they handle DNS differently.
Test each app—don't assume the browser represents your whole device
Split-tunneling rules can route some destinations through the selected route and others directly. App-specific mode may handle only the programs you've selected. This isn't necessarily a problem; what matters is whether the results match your settings. Check the browser's exit IP, then make a real request in the target app—for example, refresh content, start a new session, or use the app's own connection diagnostics. An old page or offline cache doesn't prove that a new request used the route.
| What you see | Possible explanation | What to check next |
|---|---|---|
| Browser exit changes, but the target app behaves the same | A browser extension is proxying traffic on its own, or the target app isn't being routed | Check extensions, the selected-app list, and the app's own proxy settings |
| Some websites use a different exit, while others don't | Split-tunneling rules send different domains or addresses along different routes | Check the current mode and which rules matched; retest with another site |
| The exit changes, but the DNS test still shows the original resolver | The system or browser is sending DNS queries separately | Check system DNS, browser Secure DNS, and client settings separately |
| The exit and DNS look right, but a website still reports the wrong region | Account region, browser data, or the website's own regional rules may still apply | Start a fresh session and check the account and platform's regional requirements |
For desktop apps with their own proxy settings, check whether they're set to use the system proxy, a manual proxy, or no proxy. The system proxy generally affects only apps that follow that setting; it isn't the same as a connection method that routes device traffic. If an app doesn't follow the system proxy, it may connect directly even when the client says connected and browser tests look fine. Don't switch to global mode just to make test results match; first confirm which traffic should use the selected route.
Follow these steps to troubleshoot
- Disconnect and record the IP and DNS test results in the same browser. Also note how the target app behaves at this point.
- Connect to the selected route, confirm the route and mode shown in the client, then refresh the lookup page. Check whether the public IP changed instead of relying on the “Connected” status.
- Run the DNS test again. If the result isn't what you expected, check Secure DNS in your browser and your system's resolver settings first. Avoid changing several options at once.
- Fully quit and reopen the target app, then make a new request. Check the client's split-tunneling rules or app list to confirm which route that request should use.
- If the results still differ, change just one setting and test again—for example, temporarily try another suitable route or switch connection modes once you understand the impact. Record the results before and after so you can undo the change.
- ✅ You recorded the public IP before and after connecting, using the same device and browser.
- ✅ You considered the DNS test alongside your browser's Secure DNS settings instead of relying on the location alone.
- ✅ The target app made a new request rather than showing an old page or cached content.
- ❌ You assumed every app was using the route just because the client showed a connection icon.
- ❌ You changed the route, split-tunneling rules, and DNS settings all at once, making it impossible to tell which change mattered.
If you haven't configured a client yet, start at the download page to get one for your device, then follow the quick start guide to check the import and connection steps. If you've imported your subscription but the route list hasn't updated, refresh the subscription in the client and try again with an available route. The subscription link is for downloading your configuration; pasting it into your browser's address bar won't test your exit IP.
Other reasons it may seem not to work
The website still remembers your previous region
A website may use your account region, saved sign-in state, cached data, or its own content licensing rules to decide what you can access. A changed exit IP doesn't guarantee that the page will update right away. Try reloading the page, then sign out and back in to compare. For restrictions related to membership or account region, check the platform's own rules. Unchanged content doesn't necessarily mean the VPN isn't routing your traffic.
The app hasn't started a new connection
Some apps keep existing network sessions open. An app launched before connecting to the VPN may continue using its old session until it reconnects. For a clean test, fully close and restart the app, then confirm it makes a new request. If only one app has a problem, check its network settings and which split-tunneling rule matched before reinstalling the whole client.
IPv6 or another browser connection path may behave differently
Your device and a website may support both IPv4 and IPv6, and their routes may differ. If a test page shows public addresses for both, check each one instead of recording only one. A browser WebRTC test may also show local or candidate addresses; seeing a local address doesn't by itself mean public traffic is bypassing the VPN. Focus on whether the public exit visible to remote services conflicts with your expectations, and consider the actual request path too.
When you're done troubleshooting
Limit your conclusion to what you actually tested: if the browser's public IP matches expectations, you've checked the DNS query path, and new requests from the target app follow your split-tunneling settings, then those tested requests are behaving as expected. If only one result is off, investigate the settings related to it rather than blaming every issue on the route. Different websites and apps may handle location and proxies differently, so checking your real use cases periodically is more helpful than memorizing a test page's color.
To compare locations or route types, see VPNQN's routes page. If the issue still seems related to configuration, split tunneling, or DNS, continue with the troubleshooting guide. When reporting a problem, include your device's operating system, client mode, selected location, and which of these checks produced a different result. That's more useful for diagnosis than simply saying, “It connects but doesn't work.”