You’re paying somewhere between $3 and $13 a month for a VPN that promises bulletproof privacy. But here’s the uncomfortable truth: every major VPN — including the ones at the top of “best VPN” lists — has shipped builds that leaked your real IP, DNS queries, or location at some point in the last five years. PureVPN logged users despite a “no-logs” policy. Hola sold customer bandwidth as a botnet. Even ExpressVPN has had to patch DNS leaks in specific configurations.
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 in about 15 minutes 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 isn’t tunneled by default. Most VPNs were built for IPv4. Your ISP gives you both IPv4 and IPv6 addresses, but if the VPN only routes IPv4 through the encrypted tunnel, your IPv6 traffic flows in the clear — exposing your real IP to any website that supports IPv6 (which is most of them now).
2. WebRTC bypasses the VPN tunnel. WebRTC is a browser feature for real-time communication (used by Discord, Google Meet, anything that does peer-to-peer audio/video). It uses STUN servers to figure out your real IP — and it does this outside the VPN tunnel by design. Without explicit blocking, WebRTC will leak your real IP to any website that asks.
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.
Independent audits have repeatedly found leaks in 25–35% of consumer VPNs tested under default settings. That number doesn’t drop much for premium providers — what changes is the type of leak (premium VPNs are more likely to have edge-case leaks; cheap ones leak constantly).
Bottom line: don’t trust marketing. Test.
The 6-Test VPN Verification Checklist
Run these in order. Each one takes 1–3 minutes. 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 is one of the most common VPN failures because it depends on OS-level configuration that most users don’t touch.
How to test: connect to your VPN, then run a dedicated DNS leak checker. The test will issue DNS queries to dozens of randomly-named subdomains and record which DNS servers responded.
Pass criteria: all DNS servers shown should belong to the VPN provider’s network (or a privacy-respecting third party like Cloudflare 1.1.1.1 or Quad9, depending on the VPN’s configuration). 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 asks STUN servers for your real public and local IP addresses — and it does this outside the VPN tunnel.
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 four different STUN servers simultaneously 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)
- No private/local IP from your home network is exposed
- 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 browser blocks WebRTC by default; Chrome and Firefox don’t.
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). Most home internet connections in 2026 give you both. The problem: many VPNs only tunnel IPv4, leaving your IPv6 traffic completely 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 → ideal scenario. Few VPNs do this; if yours does, you’re in the top tier.
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.
The kill switch is the single most important VPN feature for anyone with a real privacy threat model — and it’s also the feature that’s most often broken or disabled by default.
How to test: use a kill switch monitor that polls your IP at short intervals while you intentionally disconnect the VPN. If the kill switch works, your IP should never change to your real one — connections should fail entirely, not silently re-route.
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 IP monitor either shows “no connection” (good — kill switch is blocking traffic) or stays on the VPN server’s IP for a few more seconds before failing (also good — VPN client crashed but firewall rules held).
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: kill switches on iOS are notoriously unreliable because Apple restricts what VPN apps can do. Consider using a router-level VPN for sensitive iOS use.
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):
- Download speed: less than 30% loss vs baseline is good; less than 50% is acceptable
- Upload speed: similar, though uploads are typically more affected
- Ping (latency): under 100ms for most use cases; under 50ms for gaming
- Jitter: under 30ms; high jitter ruins video calls
Common failures:
- >50% speed loss → try a different server (closer geographically), switch protocols (WireGuard usually beats OpenVPN for speed), or switch providers if it persists across servers.
- 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 what 95% of users need. 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. Checking your TLS configuration, HTTPS enforcement, and HSTS support tells you whether your overall posture is solid or whether you’re vulnerable to downgrade attacks.
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 the geolocation API leaks 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 dedicated VPN identity coherence test that scans eight separate signals for mismatches.
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 | VPN’s DNS only | Mixed (VPN + third-party) | ISP DNS visible |
| WebRTC | VPN IP only, no local IP | Local IP exposed | Real public IP exposed |
| IPv6 | None or VPN-tunneled | IPv6 blocked but present | Real IPv6 visible |
| Kill switch | No traffic when VPN drops | Brief leak (under 2 seconds) | Real IP exposed for any time |
| Speed | <30% loss | 30–50% loss | >50% loss or unusable |
If everything is “pass,” your VPN is doing what you paid for. If you see “warning” anywhere, the VPN works but isn’t optimally configured — 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). For a permanent fix, switch to Brave browser, which blocks WebRTC IP discovery by default. 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, kill switches are unreliable due to OS restrictions — consider a router-level VPN for sensitive use.
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: Wi-Fi adds 20–40% latency. Run the speed test at different times: peak hours (7–11pm local) are slower.
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 (Windows feature updates have repeatedly broken VPN DNS handling)
- 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 full sweep takes 10–15 minutes once you’ve done it a couple of times. The quick check is two minutes.
Frequently Asked Questions
How long does it take to test a VPN?
The full six-test verification takes 10–15 minutes the first time. Once you know your way around the tools, it drops to about 5 minutes for a complete sweep, or 1–2 minutes for a quick IP + DNS sanity check.
Can I trust online VPN test tools?
Most reputable test tools run entirely in your browser — they don’t send your data anywhere. Look for tools that are open about their methodology and don’t require account creation. Browser-based tools that work without registration are generally trustworthy because the test logic runs locally and only sends standard HTTP requests to compute results. Tools like VPNMeter publish their methodology and don’t log results, which is the standard you should look for.
Does a paid VPN guarantee no leaks?
No. Premium VPNs leak less often than free ones, but every major provider — including ExpressVPN, NordVPN, Surfshark, and Mullvad — has shipped leaks at some point. Some leaks are platform-specific (works on macOS, leaks on Windows). Some are configuration-specific (works with WireGuard, leaks with OpenVPN). The only way to know your VPN is leak-free for your setup is to test it yourself.
My speed dropped 50% — is my VPN broken?
Probably not “broken,” but suboptimal. 50% loss is high; the typical range is 10–30%. Try a closer server, switch from OpenVPN to WireGuard if available, and test on a wired connection rather than Wi-Fi. If you still see >50% loss across multiple servers and protocols, the provider has either an oversold network or poor peering — time to consider switching.
Should I test my VPN on my phone too?
Yes. Mobile VPNs behave differently than desktop versions, especially around the kill switch (iOS in particular is notorious for kill switch failures during network handoffs). 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 take 15 minutes total and 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.
Was this article helpful?
1 out of 1 found this helpful