How to check whether your VPN is actually working

The fastest useful test takes two observations on the same network. First, find the public address a website sees without the VPN. Then connect the VPN and repeat the request. Compare the two addresses to see whether this browser’s request reached the website by a different route. To check what happens to other apps or when Wi-Fi drops, you need a different test.

Start with a fair before-and-after test

1. Use your own Wi-Fi for the baseline, close sensitive sessions and disconnect your personal VPN. Leave employer-managed security in place. If your app deliberately blocks traffic without its tunnel, only change that setting on a trusted network if it is appropriate to do so.
2. Open What can they see? in the browser you normally use. Note the observed IP address, its family (IPv4 or IPv6) and the reported network. You can keep this comparison locally. There is no need to post your home IP address to a forum.
3. Stay on the same Wi-Fi, connect the VPN and select Run a fresh report. Compare the new reading with the exit address in your app if one is supplied. An app may display a tunnel or internal address as well, so read the label before comparing numbers.
4. Repeat with another browser if the first one has an extension, proxy or iCloud Private Relay active. Keep the observations in pairs. Swapping between 5G and Wi-Fi at the same time would change the public address even with the VPN disconnected.

If the tool reports an unavailable or private address, use a second reputable IP-checking service. A site behind a proxy can see its own intermediary. A location database can also assign a data-centre address to a neighbouring city. Place more weight on the before-and-after addresses than the pin on a map.

Make sense of an unexpected result

Check DNS and both address families

DNS resolves a name into an address. A DNS test asks your browser to look up new names and observes which resolver answers. Compare the result with the DNS service your VPN documents. An unfamiliar name can belong to a supplier, a custom resolver or your browser’s secure DNS service. Seeing a third-party resolver does not on its own reveal the route taken to reach it.

Mullvad’s connection check includes DNS and WebRTC checks. Its “using Mullvad” result is specific to its own service. If you use another provider, inspect the underlying addresses rather than treating that brand-specific verdict as a failure. If a browser exposes your usual public address alongside the VPN address, review its exclusions and the provider’s leak guidance before relying on that browser.

When a test offers separate IPv4 and IPv6 readings, check both. Some providers tunnel IPv6 and others deliberately block it. An unavailable IPv6 test is compatible with either blocking or simply having no IPv6 route. Your ordinary public IPv6 address appearing when it should be covered deserves investigation.

Recheck after a real interruption

On a phone, move from Wi-Fi to mobile data. On a laptop, wake it after sleep. Read the app status, request a fresh page and check its address again. A page already on screen can remain visible offline. A result taken after reconnection also cannot establish whether any packets escaped during the gap. Read the app’s kill-switch rules, including whether they cover an intentional disconnect as well as an unexpected failure.

If one app still behaves differently, inspect split tunnelling and profile settings. Use the Android setup guide or Windows 11 instructions for the controls on those devices. Before contacting support, write down which browser, connection and setting produced the difference.

Further reading

• MDN on website location requests and device permissions
• Cloudflare’s checks for its own DNS resolver