How can you tell if your VPN is really working? Compare your public IP before and after connecting, check your DNS resolution path, then test the apps you actually use. A “Connected” status usually confirms only that a connection is up—not that your browser, games, and work apps are all using the expected route.
Start by defining what you expect: should specific international websites use the proxy, or should as much app traffic as possible enter the tunnel? With split tunneling, some sites staying on a direct connection can be normal. A test is useful only when you compare the expected route with the actual one.
First, distinguish connection, exit IP, and DNS resolution
Your public IP is the address websites see as the source of your connection. DNS translates domain names into IP addresses, while split-tunneling rules determine whether a connection goes direct or through a proxy. These are related, but they measure different things. A changed browser IP doesn’t mean every app on your device has the same exit IP. And using a public DNS resolver doesn’t automatically mean your website traffic is going through a proxy.
| Test | What it can tell you | What it can’t prove on its own |
|---|---|---|
| Client connection status | Whether the client reports an active route connection | Whether your actual app traffic is using that route |
| Website IP check | The public exit IP used to access that test page | Whether other apps or websites use the same exit IP |
| DNS test | The exit network of the recursive resolver observed by the test | The full path between your device and the resolver |
| Client connection logs | Which rules matched connections captured by the client | That traffic missing from the logs definitely doesn’t exist |
So don’t rely on a green icon alone. Stronger evidence comes from an expected exit IP, DNS behavior that matches your settings, and connection logs showing the target app using the expected route.
Compare your public IP before and after connecting
Use a reputable public IP lookup site; there’s no need to install a testing extension. Keep the same network connection throughout the test. Switching Wi-Fi or another internet connection between checks can change your public IP independently of the proxy.
- Record your baseline while disconnected. Check your public IP, network provider, and approximate location on a test site you can access. If available, note the IPv4 and IPv6 results separately.
- Connect and check the mode. See whether the client is using rule-based routing, global proxy mode, or a virtual network interface. Note the selected node so automatic switching doesn’t make the before-and-after results hard to compare.
- Run a fresh test. Close the old test page and reopen it, or use a new browser session to reduce interference from cached pages and reused connections. Make sure the test domain isn’t set to bypass the proxy in your rules.
- Check the connection logs too. See whether the test domain appears in the client logs, which rule it matched, and which outbound route it used. If needed, cross-check with another reputable test site.
If your public IP hasn’t changed, first check whether the test site is set to connect directly. If it should use the proxy, check the system proxy toggle, browser proxy extensions, and client listening settings. A changed IP is a useful clue, but confirm it changed because the route was enabled—not because you switched networks.
Geolocation databases can lag, and different databases may associate the same IP with different regions. A mismatch between the city shown and the node name doesn’t by itself mean the connection failed. Check the IP, network provider, and the client’s actual outbound connection first. If the location looks incorrect, verify it through a support ticket in the dashboard.
A proxy exit IP shown for IPv4 doesn’t mean IPv6 is using the same route. If your local network supports IPv6, check whether the client handles that traffic. And if an IPv6 test returns no result, that alone doesn’t prove IPv6 is being handled safely.
Check DNS: distinguish differences from leaks
A DNS leak usually means DNS requests bypass the intended tunnel or resolution policy and use an unexpected resolver path. The key question is whether the result differs from what you intended—not whether the test page lists a particular country, provider, or public DNS service.
Run a reputable DNS test before and after connecting. Note the recursive resolvers it detects and their network providers, then compare them with your client’s DNS settings. These sites typically use dedicated test domains to identify which resolvers make the queries. This can provide useful clues, but generally won’t reveal every part of the path between your device and the recursive resolver.
Secure DNS in your browser can affect the results
Your browser may use encrypted DNS, such as DNS over HTTPS. Its DNS policy may then differ from the operating system or client settings. Seeing a public resolver doesn’t necessarily mean there’s a leak; likewise, encrypted DNS doesn’t prove that the DNS queries are routed through the proxy.
When troubleshooting, first check your browser’s secure DNS provider and policy, then see whether the client handles the relevant connections. To compare results under controlled conditions, you can temporarily change the browser setting, run the test again, and note the change. Restore the setting you prefer afterward—there’s no need to change it just to make the test page turn green.
DNS resolver location and exit location don’t have to match
Public DNS services may use distributed infrastructure, so the location shown by a test page may not be the resolver’s actual location. Some proxy configurations also use remote DNS resolution or synthetic IP mapping, which can make browser behavior differ from system lookups. Interpret these results in light of your configuration rather than relying on a location match.
If you expect the client to handle all DNS requests but keep seeing resolvers from your local network, check DNS handling settings, split-tunneling rules, and any built-in DNS features in your apps. The system command nslookup can help check system DNS behavior, but it won’t test encrypted DNS inside your browser or prove that every app resolves names the same way.
Test apps individually—not just your browser
A system proxy doesn’t capture all traffic. It usually provides proxy settings to apps that follow the system configuration, but some apps may ignore them or use their own proxy settings. A virtual network interface can handle more connections at the network layer, but routing, exclusion rules, protocol support, and system permissions still matter.
- ✅ Browser: Check whether the system proxy, proxy extensions, and secure DNS settings conflict, then review the connection logs for the test domain.
- ✅ Desktop apps: Quit and relaunch the app to start a fresh connection. Check the target domain, matched rule, and outbound route—not just whether the home page loads.
- ✅ Command-line tools: Check the tool’s own proxy options and environment variables. Don’t assume it follows the system proxy used by graphical apps.
- ✅ Games and real-time communication: Check whether the client, node, and mode support the UDP traffic you need. A successful web test doesn’t verify this.
- ❌ Don’t treat a cached page, downloaded content, or an offline view as proof that the current connection is working.
On Windows and macOS, check the system proxy toggle and permissions for the virtual network interface. On Linux, desktop environments, terminal apps, and background services may read different settings. iOS and Android clients often use system network extensions or VPN interfaces to handle traffic, but the coverage depends on the app, system policy, and exclusion settings.
To test an app, first perform a new action that requires a network connection, then check the logs for that time. If the app’s traffic doesn’t appear, it may not be captured, it may be reusing an old connection, or logging may be disabled. Don’t assume it’s connecting directly. Restart the app, confirm what the logs capture, and investigate further.
Common reasons a VPN looks connected but isn’t working as expected
A rule sends the target site direct
In rule-based mode, domains, IP addresses, and other conditions determine the route. It can be normal for international sites to use the proxy while local services connect directly—even in the same browser. If the test site is set to connect directly, an unchanged exit IP is expected. Check the matched rule in the connection logs instead of switching to a mode that doesn’t fit your needs just to change the test result.
Global proxy mode doesn’t capture every app
“Global” in a client usually means connections handled by that client use a chosen proxy outbound route. It doesn’t guarantee that apps which bypass the client are captured too. If your browser works but other software doesn’t, check app proxy support, virtual network interface mode, and routing before repeatedly switching nodes.
The subscription updated, but the selected configuration didn’t
A subscription link retrieves nodes and related settings; it isn’t the connection itself. After updating, confirm that the active configuration comes from the expected subscription and that the chosen node is available and enabled. If the client still has an old configuration or selection, a successful download doesn’t mean your app traffic has switched routes. See the getting started guide for import and activation steps.
Proxy settings are interfering with one another
Browser extensions, the system proxy, other networking tools, and in-app settings may all be active at once. Keep the settings you intend to use and temporarily disable unnecessary proxy routes, then test again. Avoid changing everything at once; otherwise, even if access is restored, it’ll be hard to tell what fixed the issue.
Another common misconception is that a website refusing access means the proxy isn’t working. A platform may also consider your account region, session, payment details, or the reputation of your exit IP. If your exit IP has changed but the site still reports an error, check these app-level factors rather than judging the network route from the error page alone.
Keep records, then consider the privacy limits
If the issue persists, note your connection mode, operating system, client name, target app, test time, and what went wrong. A redacted comparison of exit IPs and matched-rule logs is more useful for troubleshooting than a screenshot that just says “Can’t connect.” Start with the troubleshooting guide, then submit the necessary details through a support ticket in the dashboard.
Subscription links may contain access credentials. Don’t paste them into public test sites or discussion forums. Before sharing logs, redact subscription URLs, tokens, and account details. If full diagnostic information is needed, submit it through a dashboard support ticket and follow the support team’s instructions.
Also distinguish “the network route matches expectations” from “your identity can’t be linked to you.” Even when your exit IP and DNS match your settings, websites may recognize a session through a signed-in account, cookies, or browser characteristics. HTTPS still protects data in transit at the application layer. Proxy tests don’t replace certificate checks, account security, or device maintenance.
Bottom line: Comparing public IPs checks the exit used by the test request, a DNS test checks resolution behavior, and app connection logs verify actual routing. When the results agree, you have good evidence that the target traffic is using the expected route. No single test can guarantee how all traffic is routed or protect every aspect of your privacy.