IP Leak Test
Check whether your real IP address is leaking through HTTP, WebRTC, DNS, or IPv6 — simultaneously. One test, four sources, one verdict. Unlike testing each channel separately, this catches the partial-leak cases — a VPN that protects HTTP and WebRTC but forgets IPv6, for instance — that a single-source checker will miss entirely.
2 critical leaks
1 needs review
2 safe
Source
Address
ISP & location
Matches VPN
HTTP
--
--
WebRTC · local
--
--
WebRTC · public
--
--
DNS resolver
--
--
IPv6
--
--
Block WebRTC leaks
Turn off WebRTC in your browser settings, or enable your VPN's built-in leak protection.
Fix DNS leak
Point your system DNS at your VPN's resolver, not your ISP's default.
What this test checks — 4 leak sources
HTTP IP — your visible address
The IP seen by websites when you make an HTTP request. This is what a VPN replaces with its server IP. This check almost always passes when a VPN is active — the other sources are where leaks hide.
WebRTC — the most common leak
WebRTC is a browser API for real-time communication. It uses STUN servers to discover your IP and can expose your real public IP even through a VPN. Firefox and Chrome are both vulnerable if WebRTC is not blocked.
DNS resolver — who handles your queries
Checks whether DNS queries go through your VPN's private resolver or your ISP's server. A DNS leak means your ISP can see every domain you visit even when your traffic is encrypted by the VPN.
IPv6 — the invisible leak channel
If your device has an IPv6 address and your VPN doesn't tunnel or block it, every IPv6-capable website sees your real ISP address bypassing the VPN entirely. Many VPNs only protect IPv4 by default.
The three most common leak scenarios
Critical
WebRTC reveals your home IP
Even with a VPN active, Chrome and Firefox's WebRTC implementation contacts STUN servers and reveals your real public IP and local LAN IP. The VPN cannot intercept this — it requires browser-level blocking.
High
DNS queries go to your ISP
Your VPN encrypts traffic but forgets to redirect DNS queries through its private resolver. Every domain lookup goes to your ISP's DNS in cleartext, revealing your browsing history regardless of the VPN.
Medium
IPv6 bypasses the VPN tunnel
Your VPN only tunnels IPv4. Your ISP-assigned IPv6 address remains active and goes out unprotected. Any modern website that supports IPv6 receives your real address even if your HTTP IP shows the VPN server.
Why the four sources can disagree with each other
A "partial leak" — where one or two sources show your VPN correctly while another shows your real IP — confuses most users because it looks like a bug. It usually isn't. Here's what actually causes it, drawn from how browsers and VPN clients implement each channel differently.
Chrome hides your local IP — but not always your public one
Since Chrome 79, WebRTC candidates for your local network address are masked behind a random
.local mDNS hostname instead of a raw 192.168.x.x IP, per the RTCIceCandidate specification. This stops local-network fingerprinting, but it does nothing for the reflexive (STUN-discovered) candidate — that one still carries your real public IP in plain form. Seeing an mDNS-style hostname in one candidate slot and a real IP in another is expected behavior, not a partial fix.Split tunneling can leak DNS while HTTP stays clean
If your VPN app is configured to split-tunnel — routing only certain apps or domains through the tunnel — your browser's DNS queries can fall outside that scope even while its HTTP traffic goes through the VPN correctly. That produces exactly the pattern this test is built to catch: HTTP protected, DNS leaked. It is a configuration issue, not a broken VPN.
"Happy Eyeballs" can pick IPv6 over your VPN's IPv4 tunnel
RFC 8305's Happy Eyeballs algorithm makes browsers prefer IPv6 when both an IPv4 and IPv6 route are available, because IPv6 is usually faster. If your VPN only tunnels IPv4 and your ISP hands out a routable IPv6 address, the browser will silently prefer the untunneled IPv6 path for compatible sites — even though the VPN "looks" connected and your HTTP IP shows correctly.
A clean result right after connecting your VPN can be stale
Some browsers cache ICE candidates gathered before you connected the VPN. If you run this test in the same tab immediately after connecting, you may briefly see a cached pre-VPN candidate rather than a live one. Re-testing in a fresh tab (or using the Re-test button after a few seconds) avoids this false negative.
A "leaked" verdict on a private IP range isn't always dangerous
RFC 1918 ranges (
10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) aren't routable on the public internet, so a site that captures one can't use it alone to identify or geolocate you. It still matters — combined with your public IP it can fingerprint your specific device on a shared network — which is why this test flags it, but it's a lower-severity finding than a leaked public IPv4/IPv6 address.If your results don't match one of the patterns above and you're still unsure whether a finding is real, run the dedicated WebRTC leak test or DNS leak test — each isolates a single channel with more detail than the combined matrix above can show.
How to fix each type of leak
1
Fix WebRTC leaks — disable WebRTC in your browser
In Firefox: set
Fixes WebRTC leaks
media.peerconnection.enabled to false in about:config. In Chrome: install a WebRTC control extension. Most VPN browser extensions also include a WebRTC blocking option.2
Fix DNS leaks — use a VPN with private DNS
Switch to a VPN that forces all DNS queries through its own resolver. In settings, look for "DNS leak protection" or "private DNS." NordVPN, ExpressVPN, and Mullvad all enforce this by default.
Fixes DNS leaks
3
Fix IPv6 leaks — enable IPv6 protection in VPN
Check your VPN app's advanced settings for "IPv6 leak protection" or "block IPv6." If unavailable, disable IPv6 at OS level: Network Adapter settings → uncheck IPv6 (Windows) or use sysctl (Linux/macOS).
Fixes IPv6 leaks
4
Enable the VPN kill switch
A kill switch blocks all internet traffic if the VPN connection drops, preventing your real IP from being exposed during reconnection. Enable it in your VPN app settings — it is the most important safety net available.
Prevents all leak types
Frequently asked questions
“Why test four sources at once instead of running separate tests?”
Because a VPN can protect one channel and miss another simultaneously — a DNS leak with a clean WebRTC result is a completely different problem than a WebRTC leak with clean DNS, and each needs a different fix. Testing all four together also catches cases where a fix for one leak type inadvertently exposes another (for example, disabling WebRTC entirely to stop the leak, then forgetting DNS leak protection is still off).
“My WebRTC IP shows my real address even though my VPN is connected. Is my VPN broken?”
Not necessarily. WebRTC discovers your IP through STUN requests that bypass most VPN tunnels by design — this is a browser behavior, not a VPN failure. See the WebRTC leak test for the specific fix, or disable WebRTC entirely if you don't use browser-based video/voice calling.
“Does a private/incognito window stop these leaks?”
No. Private browsing modes clear cookies and local storage on close, but they don't change how WebRTC discovers your IP, how DNS queries are routed, or whether your OS has an active IPv6 address. All four leak channels behave identically in a private window.
“Can a leak in just one source (like IPv6) still identify me if the other three are protected?”
Yes. A single unprotected channel is enough — if a site can see your real IPv6 address, it doesn't matter that your HTTP, WebRTC, and DNS all show the VPN correctly. Full protection requires all four to pass, not just a majority.
“Why does my DNS resolver show a different ISP than my HTTP IP?”
This is actually a good sign when a VPN is active: it usually means your DNS queries are correctly routed through your VPN provider's private resolver (a different network operator than your ISP) while your HTTP IP shows the VPN's exit server. If you're not using a VPN and see this, your device may be configured to use a third-party DNS service like Cloudflare or Google DNS instead of your ISP's default.
“I ran the test twice and got different results. Why?”
VPN exit servers can change between connections, ICE candidates can be cached from before you connected (see the section above), and some VPNs rotate IP addresses periodically for load balancing. Use the Re-test button in a fresh state rather than comparing across page reloads if you need a consistent read.
“Does this test store or log my IP address?”
No. Every check in this tool — HTTP, WebRTC/STUN, DNS-over-HTTPS, and IPv6 — runs entirely in your browser via client-side JavaScript. Nothing is sent to PrivacyTestLab's servers; you can verify this yourself by opening your browser's Network tab and confirming no request to this domain contains your IP or test results. See our transparency page and privacy policy for the full data-handling policy.
“How often should I re-run an IP leak test?”
After any VPN configuration change, browser update, or OS network settings change, and periodically (monthly is reasonable) even without changes — VPN providers sometimes push server-side updates that affect DNS routing or IPv6 handling without any visible client-side change. Pair this with a full privacy scan if you want broader coverage beyond just IP leaks.
