You’re paying for a VPN that promises privacy. Whether it delivers on your device, with your operating system and browser, is a separate question - and one you can answer yourself.
The fix isn’t to stop using VPNs. The fix is to test them - yours, specifically, on the device you’re reading this on right now. By the end of this guide, you’ll have run six independent tests and you’ll know exactly whether your VPN is doing what you paid it to do.
Quick checklist if you want the TL;DR:
- Confirm your public IP changed
- Run a DNS leak test
- Run a WebRTC leak test
- Run an IPv6 leak test
- Test your kill switch
- Test your speed
If even one of those fails, your VPN isn’t protecting you - and you need to either fix the configuration or switch providers. Let’s go through them in order.
Why You Need to Test Your VPN (Even If You Trust Your Provider)
VPN marketing pages all sound the same: “military-grade encryption,” “zero-logs,” “kill switch protection.” That language is great copy and tells you almost nothing about whether the product actually works on your machine, with your operating system, on your network.
VPNs leak for four reasons that have nothing to do with whether the company is honest:
1. IPv6 may not be tunneled. Some VPNs carry only IPv4. If yours neither carries nor blocks IPv6, your IPv6 traffic goes around the tunnel - exposing your real address to any site you reach over IPv6.
2. WebRTC can expose an address the tunnel does not cover. WebRTC is a browser feature for real-time communication (used by Discord, Google Meet, anything that does peer-to-peer audio/video). It asks the operating system for every address the device can be reached on, and any website can read that list. If one belongs to a connection your VPN does not cover, a website learns your real IP.
3. DNS queries get hijacked by the OS. When you type a URL, your computer asks a DNS server for the matching IP address. The VPN is supposed to route those queries through its own DNS servers. But Windows, in particular, has a feature called “smart multi-homed name resolution” that sometimes uses your ISP’s DNS even when the VPN is active. Result: ISP sees every website you visit.
4. VPN connections drop. Wi-Fi flickers. You move between networks. The VPN client crashes. In any of those moments, if the kill switch isn’t enabled or doesn’t work, your real IP is exposed for seconds to minutes - long enough for any open browser tab to phone home with your real location.
We do not have a reliable figure for how often VPNs leak, and we publish none until our own results database has one. What we do know is that the four causes above have nothing to do with whether the provider is honest - which is why testing your own setup matters.
Bottom line: don’t trust marketing. Test.
The 6-Test VPN Verification Checklist
Run these in order. You don’t need a technical background - every test below uses a free browser-based tool, and we’ll explain exactly what to look for.
Test 1 - Confirm Your Public IP Has Changed
This is the basic sanity check. If your VPN is connected, the IP address that websites see should not be your real one - it should be the VPN server’s IP, somewhere in the country you chose.
How to test:
- With your VPN off, visit any free IP checker and write down: your IP, your ISP, and your detected country.
- Turn on your VPN, choose any server (try one in a different country for clarity).
- Refresh the IP checker page.
Pass criteria: the IP, ISP, and country should all be different. The ISP should now show as the VPN provider’s hosting company (e.g., “M247 Ltd,” “Quadranet,” “DataCamp Limited”) and the country should match the server you selected.
Common failures:
- IP didn’t change at all → the VPN client is running but not actually connected. Disconnect, reconnect, try a different server.
- Country is correct but ISP shows your real one → split tunneling is enabled and routing some traffic outside the VPN. Check VPN settings.
- Browser shows different IP than other apps → only browser traffic is going through the VPN (some VPN browser extensions only protect the browser, not the whole device).
For a deeper check that runs IP, DNS, WebRTC, and geolocation tests in one pass, use a comprehensive IP leak test - it’s the fastest way to spot multi-vector leaks.
Test 2 - DNS Leak Test
A DNS leak means your computer is sending DNS queries (the lookups for “what’s the IP of facebook.com?”) to your ISP’s DNS servers instead of through the VPN. Your real IP stays hidden, but your ISP - and anyone monitoring the network - sees a complete list of every domain you visit.
This failure is easy to miss because it depends on OS-level configuration most users don’t touch.
How to test: connect to your VPN, then run a dedicated DNS leak checker. The test resolves a few one-off hostnames under a zone its own nameserver answers, and records which DNS servers asked for them.
Pass criteria: every DNS server shown should belong to your VPN provider’s network. A public resolver such as Cloudflare 1.1.1.1 or Quad9 means your lookups leave the tunnel to that operator, and the test reports it as outside the tunnel. None should be your ISP.
Common failures:
- Windows smart multi-homed resolution. Affects Windows 10/11 by default. Fix: in your VPN client, enable “Force VPN DNS” or similar. Some clients ship with this off by default.
- IPv6 DNS leak. Your IPv4 DNS goes through the VPN, but Windows or macOS sends IPv6 DNS queries to the ISP. Fix: disable IPv6 at the OS level if your VPN doesn’t tunnel it (more on that in Test 4).
- Browser-level DNS over HTTPS (DoH). Chrome and Firefox can be configured to use their own DNS resolver, bypassing the VPN. Check your browser DNS settings.
Test 3 - WebRTC Leak Test
WebRTC is a browser feature that lets web apps make peer-to-peer audio/video calls without plugins. To do that, it collects every address your device can be reached on - from the operating system’s network interfaces and from STUN servers. If one interface is not covered by the VPN, its address is in that list.
The result: a website running JavaScript can know your real IP even with a VPN active. This is a critical leak and one that most users don’t realize exists until they test for it.
How to test: connect your VPN, then load this WebRTC leak test, which queries two STUN servers (Google’s and Cloudflare’s) and reports every IP it finds.
Pass criteria:
- The “public IP” the test reveals via WebRTC matches the VPN server IP (not your real one)
- A local address (192.168.x.x, 10.x.x.x) may appear: it is your own network and the test does not count it as a leak
- If you have IPv6 enabled, no IPv6 address from your real ISP appears
Common failures:
- WebRTC reveals your real public IP → your VPN doesn’t block WebRTC. Fix: install a WebRTC-blocking browser extension (uBlock Origin can do this, or use the dedicated “WebRTC Network Limiter” extension), or switch to a VPN that handles WebRTC at the network level.
- WebRTC reveals your local network IP (e.g., 192.168.x.x) → less critical, but still a fingerprinting signal. Block via the same extensions.
- Brave has the setting built in: Settings → Privacy and security → WebRTC IP handling policy → Disable non-proxied UDP.
Test 4 - IPv6 Leak Test
The internet is in the middle of a slow migration from IPv4 (limited to ~4 billion addresses) to IPv6 (effectively unlimited). Many connections now have both. The problem: a VPN that carries only IPv4 can leave IPv6 unprotected.
If a website supports IPv6 (Google, Facebook, Cloudflare-fronted sites, almost all major properties), your browser will prefer it - and that traffic flows in the clear.
How to test: use a dedicated IPv6 leak test tool that probes via both HTTP and WebRTC for IPv6 addresses.
Pass criteria: either the test reports no IPv6 connectivity at all (meaning IPv6 is disabled on your system or fully tunneled), or the IPv6 address shown belongs to the VPN provider - not your real ISP.
Common failures:
- VPN claims “IPv6 leak protection” but the test still finds a real IPv6 address → the VPN is dropping IPv6 traffic incompletely. Fix: disable IPv6 at the OS level (Windows: Network adapter properties → uncheck IPv6; macOS:
networksetup -setv6off Wi-Fi). - VPN actually tunnels IPv6 → the address shown belongs to the VPN and the test passes.
Test 5 - Kill Switch Test
A kill switch is a feature that blocks all internet traffic if the VPN connection drops. Without it, every reconnect, every Wi-Fi handoff, every brief network glitch exposes your real IP for seconds.
For anyone with a real privacy threat model the kill switch matters, and it is easy to have it switched off without knowing.
How to test: use a kill switch monitor that polls your IP at short intervals while you force-quit the VPN app (a normal Disconnect can turn a kill switch off on purpose). If the kill switch works, your IP never changes: connections fail until the VPN comes back.
Manual test version:
- Confirm VPN is connected; verify IP shows VPN server.
- Open the kill switch monitor in one tab; let it run.
- Force-quit the VPN client (Activity Monitor on Mac, Task Manager on Windows).
- Watch the monitor.
Pass criteria: after force-quitting the VPN, the monitor shows the connection blocked, and when you start the VPN again it comes back on the VPN’s address - with the address never changing in between. If the address changes at any check, even once, traffic went around the tunnel. If it never changes and nothing is blocked, the VPN did not actually drop and the kill switch was not tested. The monitor checks about every two seconds, so a pass means no leak was seen, not that none could happen.
Common failures:
- IP immediately changes to your real one → kill switch is off. Enable it in your VPN client settings.
- Kill switch is “on” but only blocks within the VPN client app, not at the OS firewall level → app-level kill switches are weaker. If your VPN supports a “system-level” or “firewall-level” kill switch, use that instead.
- iOS users: test on the phone itself - a pass on desktop says nothing about the mobile app.
Test 6 - Speed Test
A VPN that’s secure but unusable is a VPN you’ll eventually turn off - which means it’s not protecting you. Speed matters. Some encryption overhead is unavoidable, but excessive slowdown is a sign of either a bad server, a misconfigured client, or an overloaded provider.
How to test: measure baseline speed without VPN, then connect and measure again. Use a VPN speed test that captures download, upload, ping, and jitter - all four matter.
Pass criteria (rough guidelines):
- Compare your VPN-on run with the VPN-off one on the server you use; a loss that changes a lot between nearby servers points at the server, not your line.
Common failures:
- Much slower than your VPN-off run on every nearby server you try → switch protocols (WireGuard, if your app has it), test wired rather than on Wi-Fi, or try another provider if it persists across servers and protocols.
- High ping but normal speed → server is geographically far. Pick a closer one.
- Low speed and high ping → server is overloaded. Try another server in the same country.
Beyond the Basics: Advanced Tests for the Privacy-Paranoid
The six tests above cover the common failures. If you’re a journalist, activist, or anyone with a serious threat model, there are three more layers worth testing.
Browser fingerprinting. Even with a perfect VPN, your browser broadcasts a fingerprint - Canvas hash, WebGL renderer, installed fonts, screen resolution, timezone - that can identify you across sessions. A fingerprint is often more unique than an IP address. The fix is anti-fingerprinting browsers (Brave, Tor, Mullvad Browser) or extensions.
Encryption and TLS analysis. Your VPN uses encryption to tunnel traffic, but the websites you visit also rely on TLS for end-to-end protection. Our Encryption Check reads the TLS version and key exchange your browser negotiated with our site, whether the site name went out encrypted, and mixed content. It cannot see your VPN tunnel’s own cipher - no web page can.
VPN identity coherence. Your VPN says you’re in Switzerland. But your browser language is set to English, your timezone is America/New_York, and, if you have allowed a site your location, the geolocation API reports your real city. To a fingerprinting site, these inconsistencies scream “VPN user pretending to be Swiss” - they don’t anonymize you, they make you stand out.
The free privacy testing suite at VPNMeter includes browser fingerprint analysis, encryption checks, and a VPN identity test that checks whether your address is on datacenter or proxy lists, then which browser signals - timezone, WebRTC, the country Cloudflare places you in - contradict it.
Reading Your Results: What “Pass” and “Fail” Actually Mean
Here’s a quick reference table for interpreting your test results:
| Test | Pass | Warning | Fail |
|---|---|---|---|
| Public IP | VPN server IP, correct country | Wrong country (server choice issue) | Real IP visible |
| DNS | Resolvers in your VPN exit’s network only | No verdict (a resolver could not be placed) | Any resolver outside that network - ISP or public |
| WebRTC | VPN IP only (a local address is not counted) | Not compared (an address could not be checked) | Real public IP exposed |
| IPv6 | None or VPN-tunneled | Not compared (lookup did not answer) | Real IPv6 visible |
| Kill switch | Blocked when the VPN drops, back on the VPN’s address after | No verdict: the VPN never dropped, or the block was never followed by a reconnect | Address changed at any check, even if blocked afterwards |
| Speed | Fast enough for what you use it for | Much slower on one server than on nearby ones | Slow on every server and protocol you try |
If everything is “pass,” your VPN is doing what you paid for. If you see “warning” anywhere, a check could not be completed or the VPN works but isn’t optimally configured: run it again, then review the settings. If you see “fail” on any test, your privacy is compromised in that specific dimension and needs immediate attention.
My VPN Failed a Test - Now What?
Specific fixes by failure mode:
IP didn’t change. The VPN isn’t actually connected. Quit the client, restart it, and try a different server. If your firewall or antivirus is blocking the VPN protocol, allow the VPN application through. If you’re on a corporate network, certain VPN protocols may be blocked - try switching from WireGuard to OpenVPN over TCP port 443 (which mimics regular HTTPS traffic).
DNS leak. First, enable “force VPN DNS” or “use VPN’s DNS servers” in your VPN client settings. Second, on Windows, disable “smart multi-homed name resolution” via Group Policy or PowerShell (Set-DnsClientGlobalSetting -SmartMultiHomedNameResolution $false). Third, in your browser, disable any browser-level Secure DNS feature (Chrome: chrome://settings/security → turn off “Use secure DNS”; Firefox: about:preferences#privacy → “DNS over HTTPS” set to Off).
WebRTC leak. Install a WebRTC-blocking extension (uBlock Origin: enable “Prevent WebRTC from leaking local IP addresses” in advanced settings; or install “WebRTC Network Limiter” or “WebRTC Leak Prevent” from the Chrome Web Store). In Brave, the fix is built in: Settings → Privacy and security → WebRTC IP handling policy → Disable non-proxied UDP. Tor Browser also blocks it.
IPv6 leak. If your VPN doesn’t claim IPv6 support, disable IPv6 at the OS level. Windows: open Network Connections, right-click your active adapter, Properties, uncheck “Internet Protocol Version 6 (TCP/IPv6).” macOS: networksetup -setv6off "Wi-Fi". Linux: add net.ipv6.conf.all.disable_ipv6 = 1 to /etc/sysctl.conf. If your VPN does claim IPv6 protection but is leaking, that’s a provider problem - switch.
Kill switch failure. Enable the kill switch in your VPN client. If your VPN has both an “app-level” and “system-level” or “internet” kill switch, use the system-level one. On macOS, you may need to grant the VPN client elevated privileges. On iOS, test on the phone itself - a pass on desktop says nothing about the mobile app.
Slow speeds. Switch protocols: WireGuard is fastest, IKEv2 is good, OpenVPN is slowest. Switch servers: closer geographically beats farther. Change ports: some ISPs throttle UDP - try TCP. Test wired vs Wi-Fi. Run the speed test at different times of day.
If multiple tests fail and the fixes don’t help, the issue is the provider - not your configuration. Switch.
How Often Should You Retest Your VPN?
Once is not enough. VPN reliability changes constantly because:
- VPN clients push updates that change defaults
- OS updates change network stack behavior
- Browser updates change WebRTC handling
- VPN providers add and remove servers; the one you used last week may behave differently this week
A reasonable cadence:
- Monthly - full 6-test sweep
- After every VPN client update - quick IP, DNS, and WebRTC check
- After every OS major update - full sweep
- Whenever you change networks (new Wi-Fi, hotel, café) - quick IP + DNS check
- Whenever you switch VPN servers - quick IP + DNS check
The quick check is one run of the VPN Leak Test, which covers IP, DNS, WebRTC and IPv6 together; the full sweep adds the kill switch and speed tests.
Frequently Asked Questions
How long does it take to test a VPN?
Tests 1 to 4 are one run of the VPN Leak Test, which took about ten seconds when we ran it. The kill switch test runs while you disconnect and reconnect the VPN, so it takes as long as that does, and the speed test is a run of its own.
Can I trust online VPN test tools?
Look for tools that say exactly what they send where. No browser test can work entirely on its own: to tell whose network an address is on, or which resolver answered, something has to look it up. VPNMeter sends your addresses to its own server, which looks them up with ip-api.com and does not keep them, measures DNS against its own nameserver, and stores a result only if you tick the share box. Its privacy page lists every service each test contacts.
Does a paid VPN guarantee no leaks?
No. Whether a paid VPN leaks on your setup depends on your operating system, browser and settings as much as on the provider, and a VPN that is clean on one device can leak on another. The only way to know is to test it yourself.
My speed dropped 50% - is my VPN broken?
Not necessarily. How much a VPN costs depends on your line and the server: on the 2 Gbps datacentre line of our lab, both providers we measure lose most of it, while a slower home line can lose a smaller share. Compare a VPN-off and a VPN-on run on a nearby server, try two or three servers and WireGuard if available, and test wired rather than on Wi-Fi.
Should I test my VPN on my phone too?
Yes. Mobile VPNs behave differently than desktop versions, especially around the kill switch. The same browser-based tests work on mobile - just visit them in your phone’s browser with the VPN active. Pay extra attention to what happens when you switch from Wi-Fi to cellular and back.
What’s the worst VPN test failure?
The combination of a working IP change but a failing DNS leak test. It looks like the VPN is working - the IP a website sees is different - but every domain you visit is still being logged by your ISP via DNS queries. This is the leak that gives users false confidence. Always test DNS, not just IP.
Test Your VPN Now
Reading about VPN leaks is one thing; finding out your own VPN has been leaking for months is another. The six tests in this guide use only free, browser-based tools - no installs, no accounts.
If everything passes, you’ve earned peace of mind and a baseline for monthly retesting. If anything fails, you now know exactly what to fix or whether to switch providers - and you have specific evidence rather than vague suspicion.
Privacy that you haven’t verified isn’t privacy. It’s hope.