How to check if your VPN is working: a beginner’s verification guide to exit IPs, DNS, and app-by-app testing
A connected status doesn’t guarantee your traffic is using the VPN. Check your public IP and DNS, test each app separately, and spot common connection issues.
First, decide which traffic to test
To check whether your VPN is working, look beyond the connection icon. Compare your public IP, DNS resolution, and the actual requests made by the app you want to test. Decide which traffic should use the VPN, then check whether the results match. A browser’s IP result doesn’t represent every app on your device.
VPN clients may route traffic through the system proxy or a virtual network adapter. A system proxy typically affects only apps that follow the system’s proxy settings. Virtual adapter mode often covers more traffic, but app-specific settings, routing exclusions, and IP version settings can still affect what gets routed. A “Connected” status usually means only that the connection is active or the local service has started.
Rule-based mode routes traffic according to domains, IP addresses, or apps, so local websites may connect directly by design. Global proxy mode also depends on whether it applies to the system proxy or a virtual adapter; the name alone doesn’t mean every app is covered. Before testing, note the current mode, selected route, and exclusions so you don’t mistake expected split tunneling for a fault.
Define what you want to verify as “this app uses the selected route when accessing this destination,” not simply “is the device connected?” The former gives you evidence you can check.
Public IP: record a baseline, then compare
Your public IP is the address a website sees as the source of your request. You can use our IP lookup page to check traffic from your browser. The lookup itself follows your client’s routing rules, so it shows the path taken by that browser request—not a definitive result for all traffic.
- If you can briefly disconnect safely, turn off the proxy connection, open the lookup page, and note your current public IP and network provider. If disconnecting isn’t an option, skip this step and note that you don’t have a direct-connection baseline.
- Connect your client and make sure the intended route is selected. Reload the lookup page to avoid relying on a cached result, then check whether your public IP has changed.
- Check the client’s connection log to see which rule matched the lookup domain and which route it used. If the domain is set to connect directly, an unchanged IP doesn’t prove the VPN isn’t working.
- To check whether switching routes took effect, select a different route and run a fresh lookup. Check the client log as well; don’t rely only on the location shown on the page.
A changed IP is strong evidence that this request took a different route. The displayed location is only a database estimate and may be out of date or inaccurate. Different routes may also share an exit IP, so seeing the same address after switching isn’t necessarily a problem. Conversely, a changed address could be caused by switching local networks, so try to keep the network environment the same during testing.
If a tool shows IPv4 and IPv6 separately, check both. Some configurations proxy only one, while the other continues to use your local network. Whether that’s an unexpected exposure depends on which address the test request used and which route you intended it to take. A result for one address type tells you nothing conclusive about the other.
DNS: check the resolution path, not just the location
DNS translates domain names into IP addresses. DNS lookups and subsequent website requests don’t necessarily take the same route. A website request might use the proxy while DNS is handled by your local network’s resolver. Your browser may also use secure DNS, which can differ from the system’s resolver. So a correct public IP doesn’t automatically mean DNS is configured as intended.
DNS leak test tools typically use temporary domains to see which recursive resolvers handle the lookups. The resolver IPs shown in the results are not your web traffic’s exit IP, and it’s common for them to differ. Public DNS providers may also use distributed infrastructure, so the reported location alone doesn’t prove a leak.
- Check whether your client offers remote DNS, proxy DNS, or related routing options, and make sure they apply in the current mode.
- Next, check your browser’s secure DNS settings. If the browser uses a separately configured resolver, find out how requests to that service are routed.
- Run a fresh DNS test and review the result alongside the client logs. Reloading a regular webpage may still use cached DNS data.
A DNS leak means domain lookups that should use a specified route are instead handled by an unexpected resolver. If you intentionally use local DNS for local domains, that’s usually part of your split-tunneling setup. If you expect a domain to be resolved remotely but keep seeing your local provider’s resolver, check the configuration rather than changing only your web traffic’s exit route.
Don’t change every DNS setting just to make a test page show the same location. Save your original settings and change one relevant option at a time; otherwise, it’s easy to confuse DNS resolution problems with routing issues.
Test each app: browser access doesn’t prove other apps are covered
Desktop apps may follow the system proxy, use their own networking components or proxy settings, or connect directly. Browser extensions typically affect only the browser they’re installed in. To test an office app, command-line tool, or desktop client, make a real request from that app, then check the corresponding entry in your network client’s logs.
| Scenario | What to check first | What this does not prove |
|---|---|---|
| Browser traffic | Lookup page exit IP, proxy extensions, secure DNS, matched rules | A webpage loading doesn’t mean other apps use the VPN |
| Desktop productivity apps | App proxy settings, per-app exclusions, connection logs | A successful login doesn’t prove file transfers use the same route |
| Command-line requests | The tool’s proxy options, environment variables, actual connection destination | Enabling the system proxy doesn’t mean command-line tools inherit it automatically |
| Mobile apps | System connection status, per-app settings, foreground request logs | A connection icon doesn’t mean excluded apps are covered |
On Windows and macOS, first check whether the client is using the system proxy or virtual adapter mode, and whether another network tool is changing the same settings. On Linux, distinguish desktop proxy settings from terminal environment variables: a proxy configured in one terminal may not be inherited by background services.
On Android, check the per-app proxy list and whether it includes or excludes the apps shown. On iOS, the client’s mode, rules, and app behavior can all affect routing, so don’t rely on the system status indicator alone. After changing settings, an app may keep an existing connection. If needed, close and reopen it before testing a new request.
If your client logs show domains, matched rules, and exit routes, use them to connect the evidence. If there’s no log entry, logging may be disabled, traffic may be reusing an existing connection, or the log may be incomplete. That alone doesn’t prove the app bypassed the proxy. Check what the logs can show before changing how traffic is routed.
Why traffic may not follow the expected route even when connected
The subscription updated, but the active configuration didn’t
A subscription link lets your client retrieve routes and related settings; it isn’t the connection itself. After updating the subscription, check which configuration is active and which route is selected. Clients support different formats and protocols, so a successful import only means the configuration was accepted—it doesn’t verify how real traffic is routed. For access and basic setup, see our Guides.
A rule sent traffic direct, or the app was excluded
A higher-priority rule may override the default route. If a website still shows your local IP, first check which rule matched its domain. If the site should use the VPN, adjust that rule and test again rather than treating all direct traffic as a problem.
The connection test passed, but the app uses a different type of traffic
A client’s built-in connectivity test often checks only a specific destination, so it can’t confirm that voice, video, or file transfers will all work. The app may use different domains or UDP traffic, and the result can depend on client support, routing rules, and network conditions. Test the specific feature that’s failing instead of treating a connectivity check as proof that the whole service works.
Multiple network tools are overriding each other’s settings
Browser extensions, system proxies, other virtual adapters, and in-app proxies can create overlapping routes. During troubleshooting, record your settings, pause unrelated tools, and keep the connection path easy to understand. Adding more clients usually makes it harder to identify where your exit IP and DNS results come from.
Turn your test results into a conclusion you can verify
After testing, keep track of how the network environment, client mode, target app, destination domain, matched rule, and exit result relate to one another. If you ask for help, describe what happened and the steps you took, but hide your full subscription link, account details, and any configuration containing credentials. Subscription links may contain access tokens and shouldn’t be posted in public discussions.
- ✅ Recorded a direct-connection baseline, or noted why one wasn’t available.
- ✅ Checked the target request’s exit route instead of relying only on the client’s connection icon.
- ✅ Checked DNS resolution separately from the web traffic exit, including the browser’s own settings.
- ✅ Made a new request in the app you actually use and checked its routing rules and exclusions.
- ❌ Don’t treat a matching location label, a webpage loading, or a single connectivity test as a complete verification.
Interpret WebRTC test results in context of the address type. A page listing local network addresses or privacy-masked localhost identifiers doesn’t mean your public IP is exposed. If you see an unexpected public IP from your local network, investigate the browser’s behavior and which traffic the client covers. Similarly, account region and platform risk checks alone can’t show whether the route is working.
What the results mean: You can conclude that a specific request followed the configured route only when its exit IP matches expectations, its DNS path makes sense, and the new request from the target app matched the correct rule. This doesn’t prove that every app is covered, that an account is anonymous, or that a service’s privacy policies are adequate.
If the problem persists, troubleshoot the smallest relevant part first: keep the network unchanged, adjust only the rule or client setting related to the issue, then repeat the same request. This gives you clearer evidence than repeatedly switching networks, routes, and DNS settings.