How can you tell if your VPN is working? Compare your public IP first, then check DNS and test the apps you actually use. A client’s “Connected” status is only an indicator; it doesn’t prove that all traffic is routed through the VPN. Check whether the request follows the expected route and whether DNS resolution matches your settings.
Connection Status vs. Your Actual Exit IP
In many clients, “Connected” means the local proxy or system tunnel is active. Some clients establish a remote connection only when a request is made, so a normal-looking status doesn’t mean the site you want to visit is reachable. Importing a subscription, selecting a server, connecting to it, and getting an app to use the proxy are separate steps.
A system proxy is available to apps that follow the system proxy settings; a browser extension usually affects only that browser. TUN or system VPN mode can route more traffic, but split-tunneling rules, excluded apps, and routing settings can still affect what’s covered. Don’t rely on a desktop or status-bar icon to tell you which traffic is routed.
| Check | What it confirms | What it does not prove on its own |
|---|---|---|
| Client shows connected | The local service or tunnel is enabled | That every app uses the remote exit |
| Public IP changed | The current test request uses a different exit | That other apps or address families use the same route |
| DNS test | The recursive resolver shown for the test domain lookup | The full path for all DNS traffic from the device |
| Test the target app | Whether that app’s specific request follows the rules | How untested apps are routed |
Keep a brief record of the original exit, selected server, proxy mode, exit after connecting, and results from the target app. Change one setting at a time to distinguish a server issue from a local routing issue.
Public IP Check: Start with a Baseline
- Record your direct-connection results. Disconnect the client temporarily, open a reputable public IP lookup site, and note the address, network provider, and region. Don’t mistake the private address on your router’s admin page for your public IP.
- Connect to the intended server. Make sure the client isn’t set to “Direct” and check whether the IP lookup site is routed directly by your split-tunneling rules. The test page itself must follow the route you want to check.
- Make a fresh request. Refresh the lookup page, or use a new browser window if needed. Compare the IP address itself, not just the country label; geolocation databases may be out of date.
- Check the app you want to use. Open the actual site and review the client’s connection log for its domain, matching rule, and exit. If the client can show connections by process, note the app too.
If the exit changes, you can conclude that this lookup request used a different exit. That’s useful evidence, but it doesn’t prove the VPN is working for every app on the device. If the IP stays the same, the lookup site may simply be routed directly as intended; that doesn’t necessarily mean the VPN has failed.
Check IPv4 and IPv6 Separately
Your device may have both IPv4 and IPv6 connectivity. If the client routes only one address family, your browser may use the other route. A test page that checks both can help reveal a difference; networks without IPv6 won’t have an IPv6 result to check.
If the IPv6 exit doesn’t match your expectations, check the client’s IPv6 routing, tunnel support, and leak-protection settings first. Temporarily disabling IPv6 can help isolate the issue, but it isn’t a universal long-term fix.
DNS Leaks: Check the Resolution Path, Not Just the Country
DNS translates domain names into addresses your device can connect to. Routing a proxy request through a remote server doesn’t guarantee that DNS queries take the same route. A client may use local or remote resolution, encrypted DNS, or different resolution rules for different domains.
Many DNS leak tests ask your browser to visit a temporary domain, then show the recursive resolvers involved in the lookup. This provides clues about that test request, not a complete record of all DNS activity on your device. A resolver’s location label also doesn’t show where your traffic is actually routed.
How to Read the Results
- A local ISP resolver appears: If you expect all DNS queries to go through the tunnel, investigate further. If your rules intentionally send local sites directly and resolve them locally, its name alone doesn’t prove a leak.
- A public DNS service appears: This may be configured in the client or used by your browser’s Secure DNS. Check your settings; a resolver being in another country doesn’t automatically mean the connection is secure or problematic.
- Different resolvers appear: This may reflect different DNS settings in your browser, operating system, and client, or the DNS service’s forwarding architecture. Focus on whether an unexpected local route is being used.
Note your browser’s Secure DNS and the client’s DNS settings before comparing results with and without the connection. If you temporarily change one setting, test again and record the difference, then restore the configuration you want for everyday use. Don’t import a complete DNS configuration you found online without understanding where it came from.
Caching can affect what you see. A domain that has already been resolved may not trigger a new query, so a fresh domain generated by a test page can be more useful. Clearing the cache or restarting the app can help with retesting, but won’t replace checking the DNS resolution rules.
Verify Apps Individually: A Working Browser Doesn’t Prove Everything Works
If a site works in your browser but a desktop app fails, the apps may be routed differently. The browser might use a proxy extension while the desktop app ignores system proxy settings. Games and voice apps may also use different transport methods from websites. Check the client’s documentation for its actual coverage.
- ✅ Browser: Check whether an extension has its own proxy settings, compare extension behavior in regular and private windows, and review Secure DNS settings.
- ✅ Desktop apps: Check for built-in proxy settings, whether the app follows the system proxy, and whether the client log shows a new connection from the app.
- ✅ Mobile devices: Check system VPN permissions, per-app exclusions, and whether the tunnel still works after switching networks.
- ✅ Target site: Compare the matching rule and exit in the connection log to tell whether the request bypassed the VPN or reached the site through the VPN and was rejected by the platform.
Apps on Windows don’t necessarily use the same proxy settings, and the macOS system proxy doesn’t guarantee that every app is routed through it. Android clients may offer per-app routing; on iOS, coverage depends on the network extension and configuration used by the client. The platform alone doesn’t tell you whether all traffic is routed.
Interpret WebRTC tests carefully too. A browser may show private network candidates or a local hostname that has been masked for privacy; these don’t indicate a public IP leak. If the test reveals a real public IP that doesn’t match expectations, check your browser policies and tunnel routing.
What to Check When Connected but Traffic Bypasses the VPN
Check the Rules Before the Server
Find the request you just made in the client’s connection log. If it matched a “Direct” rule, check the domain rules, app exclusions, and rule order. Temporarily switching to the client’s global proxy mode can help with comparison, but whether “Global” covers every app still depends on how traffic is routed.
If the log shows that the request was sent through the proxy but access failed, check whether the server is available, the subscription is up to date, your account’s data status, and any local network restrictions. Don’t blame every error on DNS or change the server, DNS, and rules all at once—you won’t be able to tell what fixed the issue.
Check for Proxy Conflicts and Reused Connections
Browser extensions, other networking tools, and the system proxy can override one another. Save your current settings, temporarily disable unnecessary tools, and keep one clear routing path. After changing modes, existing long-lived connections may continue using the old route; close and reopen the app you’re testing.
If you imported a configuration manually, make sure the client supports the subscription’s protocols and transport settings. A subscription link is an entry point for configuration, not a VPN server address; importing it successfully doesn’t mean every server configuration will work with your client. Subscription links contain access credentials—don’t post them on public testing sites or forums.
Treat Platform Location Checks Separately
A platform may still show your old region after your exit IP changes. This can be related to your account region, login session, location permissions, content licensing, or IP classification. It’s a separate issue from whether your network request used the VPN. Verify the exit and connection logs first, then troubleshoot the platform message instead of repeatedly changing unrelated client settings.
Evidence That Your VPN Is Working—and Its Limits
For a more complete assessment of a particular use case, confirm that the test request uses the expected exit, DNS resolution follows your settings, and the target app’s log shows the correct route. Direct connections to local sites can be expected under split tunneling; don’t assume an untested app is covered.
Test results are a snapshot of your network and settings at that moment. If problems appear after updating the client, changing rules, or switching networks, repeat the checks in the same order. Encryption doesn’t replace verifying a website’s identity or securing your account, and a changed IP doesn’t make your activity impossible to associate with you.
With VPNMake, start with the client setup guide to check import and permission settings, then follow this guide to verify your connection. See the server locations page for route information. If you can’t explain a log result, send redacted details through support.