Check VPN Leak
Check VPN Leak: What the Test Does, How It Works, and How to Fix Every Leak Type in 2026
You connected your VPN. Your browser shows you’re in Amsterdam. You feel protected. But are you? A VPN leak test reveals what your VPN is silently exposing — your real IP address, your DNS queries, your browser’s hidden local IPs — without you ever knowing.
What is a VPN Leak?
A VPN — Virtual Private Network — is supposed to act as an encrypted tunnel between your device and the internet. All traffic enters that tunnel at your device and exits at a VPN server in another location. Websites see the VPN server’s IP address, not yours. Your ISP sees encrypted noise, not the sites you visit.
A VPN leak is any failure in that tunnel that causes identifying information — your real IP address, your DNS queries, your browser’s local network addresses, or your IPv6 address — to escape outside the encrypted path and reach the public internet in plaintext.
Leaks are not rare edge cases. They happen because of design flaws in VPN clients, browser features that deliberately bypass OS-level routing, operating system misconfigurations, and the fundamental mismatch between a world that has moved to IPv6 and VPN software that still primarily tunnels IPv4. A VPN that leaks your DNS queries is arguably worse than no VPN at all: it projects a false sense of security while your ISP observes exactly which domains you visit.
In many jurisdictions, ISPs are legally required to log and retain DNS query records. A DNS leak turns your VPN into a surveillance tool that benefits your ISP while costing you a monthly subscription fee.
The Four Types of VPN Leaks
Not all VPN leaks are the same. Each has a different cause, exposes different data, and requires a different fix. Understanding each one is essential before you can interpret a leak test result correctly.
IP Address Leak
Your real public IP address is visible instead of your VPN’s IP. Caused by tunnel drops, split tunnelling misconfiguration, or no kill switch.
DNS Leak
Domain name lookups route through your ISP’s resolvers instead of your VPN’s. Every site you visit is logged by your ISP, even with VPN active.
WebRTC Leak
Your browser exposes local and public IPs through its peer-to-peer API, bypassing VPN routing entirely at the browser level.
IPv6 Leak
Your device’s IPv6 address travels outside the VPN tunnel because most VPN clients only route IPv4 traffic through the encrypted channel.
IP Address Leaks
The most obvious leak type. Your public IP is the address ISPs and websites use to identify you and approximate your location. A VPN replaces your IP with one of its own. If a leak test shows an IP that resolves to your real city or your actual ISP, your VPN is not hiding you — it may have dropped the tunnel silently, or your traffic is being routed outside it entirely.
DNS Leaks — The Most Common and Dangerous
DNS (Domain Name System) is the internet’s phonebook. Every time you visit a website, your device asks a DNS resolver to convert the domain name (like example.com) into an IP address. That query reveals the domain name itself to whoever operates the resolver.
Under normal circumstances without a VPN, these queries go to your ISP’s resolvers. With a properly configured VPN, they should go exclusively to the VPN provider’s own resolvers — inside the encrypted tunnel. A DNS leak occurs when the OS routes DNS queries outside the VPN tunnel, directly to ISP resolvers, even while all other traffic travels through the VPN. The result: your ISP sees your entire browsing history by domain name, even though your actual HTTP/S traffic is encrypted.
WebRTC Leaks
WebRTC is a browser standard that enables video calls, voice chat, and peer-to-peer file sharing without plugins. As part of establishing a peer connection, the WebRTC API uses STUN (Session Traversal Utilities for NAT) servers to discover both the device’s local network IP and its public internet-facing IP. The problem: this IP discovery process happens at the browser level, using its own network stack, which bypasses the OS-level VPN routing entirely. Your browser can expose your real IP address through WebRTC even when your VPN is active and working correctly for all other traffic.
IPv6 Leaks
The internet is mid-transition from IPv4 (e.g. 192.168.1.1) to IPv6 (e.g. 2a00:1450:4009:823::200e). Most home broadband connections now have both an IPv4 and an IPv6 address. Most VPN clients tunnel only IPv4 traffic. If your system sends an IPv6 packet — which modern operating systems do automatically — it travels outside the VPN tunnel in plaintext, carrying your real IPv6 address to the destination server.
How the VPN Leak Checker Works, Technically
A good VPN leak test is not a single check — it is four separate technical probes running simultaneously, each targeting a different potential failure point in your VPN’s tunnel. Here is exactly what our VPN leak test tool does under the hood, step by step.
Step 1 — Public IP Address Detection
The tool makes an outbound HTTP request from your browser to a third-party IP geolocation API. The API receives the request, records the IP address it arrived from (which is whatever your device is currently using to reach the internet), and returns it along with associated data: country, city, region, ISP name, and organisation name.
The tool uses a cascade of CORS-compatible APIs — ipapi.co, ipwho.is, and freeipapi.com — in priority order, trying the next if the previous fails. This prevents a single API outage from causing the entire test to fail. The returned IP and ISP name are then compared against a database of known VPN providers, datacentres, and hosting organisations. If the ISP name contains terms like “NordVPN”, “Mullvad”, “DigitalOcean”, or “Hetzner”, the tool infers that VPN routing is active for your primary IPv4 traffic.
// Fetch public IP from geolocation API const res = await fetch('https://ipapi.co/json/'); const data = await res.json(); // data.ip → your current public IP address // data.org → ISP or organisation name // data.city → city attributed to that IP // data.country_name → country attributed to that IP // VPN detection heuristic: check ISP name const vpnKeywords = ['vpn', 'mullvad', 'nordvpn', 'digitalocean', ...]; const isVPN = vpnKeywords.some(k => data.org.toLowerCase().includes(k));
Step 2 — DNS Leak Detection
The DNS leak check uses DNS-over-HTTPS (DoH) with a clever technique: querying a special subdomain that Cloudflare’s infrastructure uses to reveal which resolver submitted the query. The tool sends a DoH query to cloudflare-dns.com asking for the TXT record of whoami.cloudflare. Cloudflare’s nameservers respond with a TXT record containing the IP address of the DNS resolver that made the request — not the IP of your browser, but the IP of whichever DNS server resolved the query on your behalf.
Simultaneously, the tool fetches Cloudflare’s /cdn-cgi/trace endpoint, which returns a plain-text block of connection metadata including the IP address Cloudflare sees for your connection. The resolver IP returned by the whoami.cloudflare query is then classified: if it belongs to a known private resolver (Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9 9.9.9.9, or a VPN provider’s own infrastructure), it is flagged as safe. If it resolves to a telecoms company or ISP, it is flagged as a DNS leak.
// Query whoami.cloudflare via DNS-over-HTTPS const res = await fetch( 'https://cloudflare-dns.com/dns-query?name=whoami.cloudflare&type=TXT', { headers: { 'accept': 'application/dns-json' } } ); const d = await res.json(); // The TXT answer contains the resolver's IP address // e.g. "1.1.1.1" → Cloudflare → safe // e.g. "41.80.x.x" → Kenyan ISP resolver → DNS leak! const resolverIP = d.Answer[0].data.replace(/"/g, '');
The DNS leak test cannot enumerate all DNS servers your device uses. It captures the resolver that handles the specific query sent during the test. If your system uses multiple resolvers (common on Windows with DNS suffix search lists), some may leak while others do not. Running the test multiple times improves confidence.
Step 3 — WebRTC Leak Detection
This is the most technically interesting check. The tool creates a real RTCPeerConnection — the same browser API used by video conferencing platforms — and initiates an ICE (Interactive Connectivity Establishment) candidate gathering process. ICE is the mechanism peer-to-peer connections use to discover all possible network paths between two devices.
To discover those paths, the browser contacts STUN servers (the tool uses Google’s public STUN servers at stun.l.google.com:19302). The STUN server reflects the browser’s external IP address back to it. The browser then generates ICE candidate strings, each containing an IP address — either a local network address (like 192.168.x.x) or a public address. The tool intercepts every ICE candidate via the onicecandidate event handler, extracts all IP addresses with a regex, and classifies them as local (private RFC1918 ranges) or public.
A public IP address appearing in WebRTC candidates that does not match your VPN’s IP is a WebRTC leak — your real address is exposed at the browser level regardless of what the VPN is doing at the OS level.
const pc = new RTCPeerConnection({ iceServers: [{ urls: 'stun:stun.l.google.com:19302' }] }); pc.createDataChannel(''); await pc.setLocalDescription(await pc.createOffer()); pc.onicecandidate = (event) => { if (!event.candidate) return; // candidate.candidate string contains exposed IP addresses // e.g. "candidate:... 192.168.1.5 ..." → local IP (expected) // e.g. "candidate:... 197.x.x.x ..." → public IP (potential leak!) const ips = event.candidate.candidate.match(/(\d{1,3}(?:\.\d{1,3}){3})/g); };
Step 4 — IPv6 Leak Detection
The tool makes a fetch request to api64.ipify.org — a dual-stack endpoint that returns whichever IP address (IPv4 or IPv6) your device uses to reach it. If your device has IPv6 connectivity, most operating systems will prefer IPv6 for outbound connections. If the returned address contains colons (:), it is an IPv6 address, and the tool flags it — because a VPN that is not tunnelling IPv6 would allow this address to travel to the internet in plaintext.
How to Read Your VPN Leak Test Results
Each check in the test produces one of four status labels. Here is what each means in practice.
| Status | Check | What It Means | Action |
|---|---|---|---|
| No Leak | Any | This data point is not exposing your real identity. | None required. |
| Leak Detected | IP / ISP | Your real IP or ISP is visible. VPN tunnel is broken or inactive. | Reconnect VPN, enable kill switch, or switch VPN provider. |
| Leak Detected | DNS | Your ISP’s DNS resolvers are handling queries outside the VPN tunnel. | Enable DNS leak protection in VPN settings. Set manual DNS to 1.1.1.1. |
| Leak Detected | WebRTC | Browser is exposing your real IP via STUN requests, bypassing VPN. | Disable WebRTC in browser or install a WebRTC blocking extension. |
| IPv6 Found | IPv6 | An IPv6 address was detected. May travel outside VPN tunnel. | Disable IPv6 at OS level or use a VPN that tunnels IPv6 explicitly. |
| VPN Detected | IP | The IP resolves to a VPN provider or datacenter. Good. | No action needed. |
| N/A | Any | Test could not complete (API timeout, no WebRTC support). | Refresh and run again. Persistent N/A may indicate browser restriction. |
Run the test twice — once without your VPN connected, to establish your baseline (real IP, real ISP, real DNS resolvers), then again with your VPN active. Comparing both sets of results tells you with certainty what your VPN is and is not hiding.
How to Fix a VPN DNS Leak in 2026
A DNS leak is the most common VPN failure mode, and also one of the most consequential. Your ISP can observe every domain name you look up, which for most people constitutes a near-complete record of their browsing activity. Here is how to fix it, in order of effectiveness.
Fix 1 — Enable DNS Leak Protection in Your VPN Client
Most premium VPN applications include a DNS leak protection setting — sometimes labelled “Prevent DNS leaks”, “DNS leak fix”, or “Use only VPN DNS”. This setting forces all DNS queries through the VPN’s own internal resolvers, preventing the OS from using system-configured DNS servers that exist outside the tunnel. Locate this setting in your VPN application’s Preferences or Connection settings and ensure it is toggled on.
Fix 2 — Manually Set Your DNS Servers
If your VPN client does not have a DNS leak protection option, or if the option is enabled but the leak persists, manually configure your operating system’s DNS servers to use a resolver that you control and that is not your ISP’s.
Windows 11
- Open Network SettingsSettings → Network & Internet → Wi-Fi (or Ethernet) → Click your connection name → DNS server assignment → Edit
- Switch to ManualSelect “Manual” from the dropdown, then toggle IPv4 on.
- Enter DNS ServersPreferred DNS:
1.1.1.1(Cloudflare) — Alternate DNS:1.0.0.1. For DNS-over-HTTPS, select “On (automatic template)” next to each entry. - Save and reconnect your VPNRun the leak test again to confirm the resolvers have changed.
macOS Ventura / Sonoma / Sequoia
- Open System SettingsSystem Settings → Network → Select your active interface → Details → DNS tab
- Remove existing DNS entriesClick the minus (−) button to remove all existing DNS server entries.
- Add private DNS serversClick plus (+) and add
1.1.1.1, then1.0.0.1. Click OK and Apply. - Reconnect your VPN and retestRun the leak test to verify the resolver IP has changed from your ISP’s to Cloudflare’s.
Ubuntu / Debian Linux
# Edit systemd-resolved config sudo nano /etc/systemd/resolved.conf # Add or update these lines: [Resolve] DNS=1.1.1.1 1.0.0.1 FallbackDNS=9.9.9.9 8.8.8.8 DNSOverTLS=yes # Restart the resolver service sudo systemctl restart systemd-resolved # Verify current DNS resolvectl status
Android 9 and above
Android 9 introduced Private DNS (DNS-over-TLS). Go to Settings → Network & Internet → Private DNS → Private DNS provider hostname → enter 1dot1dot1dot1.cloudflare-dns.com or your VPN provider’s DoT hostname. This forces all DNS queries through encrypted TLS, regardless of which app or network you use.
iOS / iPadOS
iOS does not allow system-wide manual DNS in the same way. The most reliable approach is to install a VPN application that handles DNS interception (like Mullvad or ProtonVPN for iOS), or install a DNS configuration profile from Cloudflare (1.1.1.1 app → WARP settings).
Fix 3 — Enable the Kill Switch
A VPN kill switch cuts off all internet traffic if the VPN tunnel drops — preventing a brief reconnection window from exposing your real IP and DNS. Without a kill switch, a VPN disconnect causes your device to revert to its default routing, which means ISP DNS resolvers and your real IP, for the duration of the reconnection. Enable the kill switch in every VPN client you use. It is often buried in Advanced or Connection settings.
Fix 4 — Use a VPN with Private DNS Infrastructure
The cleanest solution is a VPN that operates its own DNS resolvers on the same servers as the VPN endpoints, routes all DNS queries exclusively through the encrypted tunnel, and has independent audits confirming the implementation. Mullvad, ProtonVPN, and ExpressVPN all operate private DNS and have published results of third-party no-leak audits. If your current VPN is consistently leaking DNS despite client-side fixes, switch providers.
After applying any DNS fix, run the leak test again. The DNS resolver IP shown should be Cloudflare (1.1.1.1 / 1.0.0.1), your VPN provider’s resolver, or another private resolver you configured — never an address that belongs to your ISP. If you’re unsure who owns a resolver IP, paste it into ipapi.co/{resolver-ip}/json/ to see the org name.
How to Fix a WebRTC Leak
WebRTC leaks are browser-specific. The fix lives in the browser, not the VPN client, because the VPN cannot intercept browser-level STUN traffic.
Chrome / Chromium
Chrome does not offer a native WebRTC disable toggle. The most reliable approach is a browser extension. WebRTC Network Limiter (official Google extension) restricts IP exposure by forcing Chrome to use only the VPN interface for WebRTC. uBlock Origin also includes a WebRTC IP leak prevention option under its privacy settings — go to uBlock Origin dashboard → Settings → Privacy → Prevent WebRTC from leaking local IP addresses.
Firefox
Firefox allows WebRTC to be disabled entirely. Type about:config in the address bar, search for media.peerconnection.enabled, and double-click it to set it to false. This disables WebRTC entirely, which will break video conferencing in-browser but prevents all WebRTC IP leaks. A softer option: set media.peerconnection.ice.default_address_only to true — this allows WebRTC to function but restricts it to reporting only the default network interface (which should be the VPN interface).
# Disable WebRTC entirely (breaks video calls) media.peerconnection.enabled = false # OR: Restrict to VPN interface only (recommended) media.peerconnection.ice.default_address_only = true media.peerconnection.ice.no_host = true
Safari
Safari on macOS uses Apple’s WebKit engine and has stricter default IP handling than Chromium. In most configurations, Safari does not expose local IPs via WebRTC. Confirm by running the leak test in Safari specifically.
Brave
Brave includes built-in WebRTC leak protection. Go to Settings → Privacy and security → WebRTC IP handling policy → Select “Default public interface only” or “Disable non-proxied UDP” for maximum protection.
How to Fix an IPv6 Leak
IPv6 leaks occur because VPN tunnels typically carry only IPv4 traffic. If your internet connection has IPv6, those packets travel outside the tunnel by default. There are two approaches: force your VPN to tunnel IPv6 as well, or disable IPv6 at the OS level.
Option A — Use a VPN That Supports IPv6 Tunnelling
Mullvad, ProtonVPN, and NordVPN all offer full IPv6 support in their tunnels. With these VPNs, your IPv6 traffic is routed through the encrypted tunnel alongside IPv4, and the address visible to websites is the VPN server’s IPv6 address rather than yours. Check your VPN’s documentation under “IPv6 support” or “IPv6 leak protection”.
Option B — Disable IPv6 at the OS Level
Windows
# Disable IPv6 on all network adapters Disable-NetAdapterBinding -Name "*" -ComponentID ms_tcpip6 # Verify Get-NetAdapterBinding -ComponentID ms_tcpip6
macOS
# Replace "Wi-Fi" with your interface name if different networksetup -setv6off Wi-Fi networksetup -setv6off Ethernet # Re-enable later if needed networksetup -setv6automatic Wi-Fi
Linux
# Add to /etc/sysctl.conf net.ipv6.conf.all.disable_ipv6 = 1 net.ipv6.conf.default.disable_ipv6 = 1 net.ipv6.conf.lo.disable_ipv6 = 1 # Apply immediately sudo sysctl -p
Disabling IPv6 is effective but blunt. Some services perform better over IPv6, and disabling it can slow down certain connections as the OS falls back to IPv4. If your VPN supports IPv6 tunnelling, that is the cleaner solution. Re-enable IPv6 if you notice performance issues after disabling.
VPNs That Are Verified Not to Leak in 2026
The most reliable leak prevention is choosing a VPN that has been independently audited for leaks and has passed. Audits test for the specific failure modes described in this article — DNS leaks, WebRTC exposure, IPv6 tunnelling, and IP address binding at tunnel drop.
| VPN | DNS Leak Protection | IPv6 Support | Kill Switch | Audited |
|---|---|---|---|---|
| Mullvad | Yes | Full tunnel | Yes | Yes — Cure53 |
| ProtonVPN | Yes | Full tunnel | Yes | Yes — SEC Consult |
| ExpressVPN | Yes | Blocks IPv6 | Yes | Yes — KPMG |
| NordVPN | Yes | Full tunnel | Yes | Yes — Deloitte |
| Surfshark | Yes | Blocks IPv6 | Yes | Yes — Cure53 |
| Windscribe | Yes | Blocks IPv6 | Yes | Partial |
Note that “Blocks IPv6” is a valid leak-prevention strategy — the VPN prevents any IPv6 traffic from leaving the device while connected, which stops the leak even though it does not route IPv6 through the tunnel. “Full tunnel” means IPv6 is routed encrypted through the VPN server, giving you an anonymised IPv6 address.
Run the VPN Leak Test Now
Free, instant, no signup. See exactly what your VPN is — and is not — protecting.
Check for leaks →Frequently Asked Questions
How do I check if my VPN is leaking?
Connect your VPN, then visit a VPN leak test tool. The tool will automatically probe your public IP, DNS resolvers, WebRTC, and IPv6 address. If any of the results show an IP or organisation that belongs to your real ISP rather than your VPN provider, that category is leaking. For maximum accuracy, run the test once without your VPN to record your baseline data, then again with the VPN active to compare.
What is a DNS leak and why does it matter?
A DNS leak happens when your browser or OS sends domain name lookup queries to your ISP’s DNS servers instead of your VPN’s servers — even while the VPN tunnel is active. Since every DNS query contains the domain name you’re requesting, your ISP can see every website you intend to visit, even though the actual HTTP/S traffic is encrypted by the VPN. In countries where ISPs are required to retain DNS query logs, this effectively gives authorities a complete record of your browsing history despite your VPN subscription.
Can a VPN leak your real IP even when connected?
Yes, in three common scenarios. First, if the VPN tunnel drops and no kill switch is active, traffic briefly reverts to your real IP. Second, WebRTC in your browser can expose your real IP via STUN server requests that bypass VPN routing. Third, IPv6 traffic on VPNs that only tunnel IPv4 will carry your real IPv6 address outside the tunnel. Running a full leak test covers all three scenarios simultaneously.
Is a free VPN more likely to leak?
Yes, significantly. Free VPNs often lack DNS leak protection, kill switches, and IPv6 handling. Many free VPN providers generate revenue by logging and selling user data — including DNS query logs — which makes a DNS leak not just a technical failure but a deliberate business model. Free VPNs also rarely commission independent security audits. If privacy is genuinely your goal, a paid VPN with an audit trail is necessary.
Does a VPN leak test work on mobile?
The IP, ISP, location, and IPv6 checks work on any modern mobile browser. The WebRTC leak check works on Android Chrome and Firefox but may have limited functionality on iOS Safari due to Apple’s WebKit restrictions on the WebRTC API. The DNS leak check via DNS-over-HTTPS works on all modern mobile browsers. For the most complete results on iOS, use the Firefox browser rather than Safari.
How often should I run a VPN leak test?
Run one whenever you: install a new VPN client, update your VPN client to a new version, change VPN servers or protocols, experience a VPN connection drop and reconnect, or switch to a new device or operating system. Changes to any of these can alter DNS routing, WebRTC behaviour, or IPv6 handling — making a previously clean configuration suddenly leak.
My VPN says it has no-log and no-leak protection. Why did it fail the test?
Marketing claims and technical reality frequently diverge. “No-log” refers to server-side data retention policies and does not guarantee the client software correctly prevents leaks on your device. “Leak protection” is a feature claim that may be implemented incorrectly, disabled by default, or not applied to all traffic types. Independent audits by firms like Cure53 or KPMG test the actual implementation — if your VPN has not published audit results, its self-described protection should be treated with scepticism.
This tool and article are maintained by VirtualPrivateNetwork.io. The leak test runs entirely in your browser — no data is transmitted to or stored on our servers. All checks use client-side JavaScript and public CORS-enabled APIs.