A VPN that leaks your real IP address is worse than no VPN. You believe you’re protected, your activity continues under that assumption, and your real identity is exposed the whole time.

IP leaks are more common than most users realize. Here’s how to check for them and fix them.

Types of VPN leaks

DNS leaks: When your device sends DNS queries (domain name lookups) outside the VPN tunnel, to your ISP’s DNS server instead of the VPN’s. Your ISP can see which websites you’re looking up even when you think you’re protected.

WebRTC leaks: WebRTC is a browser technology used for video calls and real-time communication. It can expose your real IP address directly through your browser, bypassing the VPN entirely. This affects Chrome, Firefox, and Edge by default.

IPv6 leaks: Most VPNs tunnel IPv4 traffic but may not handle IPv6. If you have an IPv6 connection and the VPN doesn’t block or tunnel it, your real IPv6 address leaks alongside the VPN’s IPv4 address.

Kill switch failures: If your VPN disconnects and the kill switch doesn’t activate, traffic reverts to your real connection.

How to test for leaks

Step 1: Disconnect your VPN. Go to ipleak.net or dnsleaktest.com. Note your real IP address and ISP name.

Step 2: Connect to your VPN. Run the test again on the same site.

Step 3: Check the results:

  • The IP address shown should be the VPN server’s IP, not your real one
  • The DNS servers shown should be the VPN provider’s servers, not your ISP’s
  • No IPv6 address should appear unless you’re connected to an IPv6-capable VPN server

If your real IP, your ISP’s DNS servers, or your real IPv6 address appears anywhere in the results, you have a leak.

How to fix DNS leaks

In your VPN app: Most reputable VPNs have a DNS leak protection setting. Enable it if it’s not on by default. NordVPN, Surfshark, and ProtonVPN all have this.

Manual fix: Change your DNS settings to use the VPN’s DNS servers or a privacy-focused DNS service (Cloudflare 1.1.1.1, Quad9 9.9.9.9) rather than your ISP’s default. This applies at the OS level: network settings on Windows, macOS, iOS, or Android.

How to fix WebRTC leaks

WebRTC leaks happen in the browser, not the VPN. Fix options:

Browser extension: Install uBlock Origin (Firefox, Chrome). In its settings, disable WebRTC. Or install a dedicated WebRTC leak blocker extension.

Firefox: Go to about:config in the address bar, search for media.peerconnection.enabled, and set it to false. This disables WebRTC entirely.

Chrome: WebRTC cannot be fully disabled in Chrome without an extension. Use Firefox or Brave instead if WebRTC leaks are a concern.

Brave: Go to Settings > Privacy and Security > WebRTC IP handling policy > Disable non-proxied UDP.

How to fix IPv6 leaks

In your VPN app: Enable IPv6 leak protection or IPv6 blocking. NordVPN blocks IPv6 by default. Most reputable providers have this option.

OS level (Windows): Control Panel > Network and Internet > Network Connections > right-click your adapter > Properties > uncheck Internet Protocol Version 6.

OS level (macOS): System Settings > Network > your connection > Details > TCP/IP > Configure IPv6 > Off.

VPNs that consistently pass leak tests

In our testing, NordVPN, ProtonVPN, and Mullvad consistently show no leaks on DNS, WebRTC, and IPv6 tests with their default settings. Surfshark passes with leak protection enabled (on by default).

Some cheaper and free VPNs fail on DNS leaks specifically, often because they don’t route DNS queries through their own servers.

Want to compare all VPNs side by side? Check our full VPN comparison table with scores across 18 criteria.

Bottom line

Run a leak test at ipleak.net right now. It takes two minutes and tells you if your VPN is actually working. DNS leaks are the most common issue: fix by enabling leak protection in your VPN app. WebRTC leaks are browser-specific: fix in browser settings or with uBlock Origin. A VPN that leaks any of these gives you false security.

Reading the results: what failure actually looks like

The tests return columns of addresses, and the reading rule is simple: every visible address should belong to your VPN provider’s server, none to your ISP. An IPv4 from the VPN plus an IPv6 from your ISP is a leak (the IPv6 case). DNS resolvers naming your ISP, or your country when you’re tunneled elsewhere, are a leak even when the IP column looks clean. WebRTC showing a local or residential address alongside the VPN’s is the browser leak. Screenshot the clean state once; future comparisons take five seconds against the reference.

False alarms exist too: DNS resolvers in odd cities but owned by the provider’s DNS partner are normal (anycast geography is weird), and IPv6 showing as simply absent is fine, since blocking it is a valid protection. The pattern that matters is ISP ownership of anything.

Fixing each leak type

DNS leaks: enable the provider’s own DNS in app settings (usually labeled as such), disable any custom DNS the OS carries, reconnect, retest. Windows users with stubborn leaks should look for the app’s “prevent DNS leaks” or firewall-integration toggle, which exists precisely for the OS’s enthusiasm for parallel resolution paths.

IPv6 leaks: prefer providers that tunnel IPv6 natively or block it cleanly (the big names do one or the other); otherwise disable IPv6 in the OS network adapter as the blunt fix. WebRTC: turn on the VPN browser extension’s WebRTC protection, or set the browser flag directly; testing afterward takes one reload. And the meta-fix for repeated failures on any axis: a provider whose apps handle all three by default, which is part of what the leak-protection column in our comparison scores. Leak-proofing by configuration archaeology is a 2018 hobby; current top-tier apps simply pass these tests out of the box.

How often to retest

Three triggers, not a schedule: after any VPN app update or protocol change, after OS upgrades (both Windows and macOS have shipped networking changes that resurrected old leak paths), and on any new network type you’ll use repeatedly (the new office, the semester’s dorm). Plus the once-a-quarter habit for anyone whose VPN use is privacy-motivated rather than streaming-motivated. The test costs ninety seconds; the silent failure it catches can run for months otherwise, which is the entire economics of the habit.

One closing habit separates the thorough from the theatrical: test under realistic failure, not just steady state. Toggle Wi-Fi mid-test, wake the laptop from sleep, switch networks while connected; leaks live in transitions, and a setup that stays clean through them (kill switch doing its work) is verified in the only sense that matters. Steady-state green checkmarks are where verification starts, not where it ends.

(Bookmark-worthy closing list: ipleak.net, browserleaks.com and dnsleaktest.com cover the full test surface between them; any one suffices for the quarterly habit, and all three agree when a setup is genuinely clean.)

If a retest ever fails after months of clean results, change the order of suspicion: app update first, OS update second, new network third, provider infrastructure last. Working through that order resolves the regression in minutes, and noticing it at all means the quarterly habit just paid for every boring rerun that preceded it.

Keep reading: What Is a VPN Kill Switch and Why You Need One and How to Verify a VPN’s No-Log Policy: What Actually Counts as Proof.