🔢 IPv6 Leak Test

Is Your IPv6 Address Leaking?

Most VPNs only tunnel IPv4 traffic. If your device has IPv6 connectivity, your real IPv6 address may be visible to every site you visit - completely bypassing your VPN.

🛡
Ready to test
Click “Test IPv6 Leak” to check your connection
-
Leak Score
🌐
IPv4 Address
Your visible IPv4 address - your VPN exit node or real IP
Pending
Run the test to detect your IPv4 address.
🔢
IPv6 Leak (HTTP)
Checks if your browser connects via IPv6, potentially bypassing your VPN tunnel
Pending
Run the test to check for IPv6 leaks via HTTP.
🎥
IPv6 Leak (WebRTC)
WebRTC can expose IPv6 addresses even when normal HTTP traffic is IPv4
Pending
Run the test to check for IPv6 leaks via WebRTC.
ℹ️
IPv6 Connectivity Status
Summary of whether your device has active IPv6 connectivity
Pending
Run the test to check your IPv6 connectivity status.
⚖️
Final Verdict
Overall assessment combining HTTP and WebRTC IPv6 leak results
Pending
Run the test to see the final verdict.

What Is an IPv6 Leak?

An IPv6 leak happens when your device sends traffic over the IPv6 protocol while your VPN only protects IPv4. The result is a connection that looks encrypted - your VPN client shows a green “connected” badge, and an ordinary IP checker reports the VPN server’s address - while any website that supports IPv6 quietly receives your real address, assigned by your own ISP.

This is the most under-tested VPN failure mode in existence. Most leak tests only look at your IPv4 address, so an IPv6 leak passes them without a warning. That is exactly why this page exists: it queries an IPv6-only endpoint directly, and separately probes WebRTC, so a leak has nowhere to hide.

Why Does IPv6 Leak in the First Place?

IPv6 is the successor to IPv4, created because the world ran out of 32-bit addresses. Most consumer ISPs now hand out an IPv6 prefix alongside the usual IPv4 address, and modern operating systems prefer IPv6 whenever it is available - that behaviour is defined in RFC 6724 and is on by default in Windows, macOS, Linux, iOS and Android.

The problem is that a large share of VPN clients were designed around IPv4. When such a client connects, it installs routes that capture IPv4 traffic and simply ignores the IPv6 stack. Your operating system, seeing a perfectly working IPv6 route that the VPN never touched, sends traffic straight out through your ISP - outside the tunnel, unencrypted, and stamped with an address that maps directly back to your household.

IPv6 addresses are also a worse privacy problem than IPv4 addresses. A typical home gets a persistent /64 or /56 prefix that changes rarely or never, and there is no carrier-grade NAT sharing it between hundreds of subscribers. An IPv4 address often identifies a neighbourhood; a leaked IPv6 prefix frequently identifies a single household, and often a single device.

How to Read Your Results

The test runs four independent checks. Here is what each outcome actually means for your privacy.

ResultWhat it meansAction needed
No IPv6 connectivity Your device has no working IPv6 route at all, so nothing can leak over it. None. This is the safest state.
IPv6 present, matches VPN You have IPv6, and it exits through your VPN provider’s network. Your provider tunnels IPv6 properly. None - this is the ideal outcome.
IPv6 leak via HTTP Ordinary web traffic is escaping the tunnel. Every IPv6-capable site you visit sees your real address. Fix immediately - see the steps below.
IPv6 leak via WebRTC Your page traffic is tunnelled, but WebRTC bypasses it. Any site can extract your real IPv6 with three lines of JavaScript. Block WebRTC or disable IPv6.

The two leak checks are deliberately separate, because they fail independently. It is entirely normal to pass the HTTP check and fail the WebRTC one - WebRTC asks the operating system for local interface addresses directly, sidestepping the routing table your VPN modified.

How to Fix an IPv6 Leak

There are two valid strategies: tunnel IPv6 properly, or switch it off so there is nothing to leak. Both work; the first is better if you need IPv6-only services.

1. Turn on your VPN’s IPv6 leak protection

Check your client’s settings for “IPv6 leak protection”, “Block IPv6” or “IPv6 tunnelling”. This is the one-click fix and it is the right place to start - a properly implemented client will either route IPv6 through the tunnel or firewall it off entirely.

2. Pick a provider that actually tunnels IPv6

Mullvad, ProtonVPN and IVPN route IPv6 through the tunnel or block it at the firewall level. WireGuard-based configurations generally handle IPv6 cleanly because the protocol was designed with dual-stack in mind. Re-run this test after switching - provider behaviour changes between client versions, so trust the measurement rather than the marketing page.

3. Disable IPv6 at the operating-system level

  • Windows: Settings → Network & Internet → Change adapter options → right-click your adapter → Properties → uncheck Internet Protocol Version 6 (TCP/IPv6)
  • macOS: System Settings → Network → your interface → Details → TCP/IP → Configure IPv6 → Off. On older releases: networksetup -setv6off Wi-Fi
  • Linux: add net.ipv6.conf.all.disable_ipv6 = 1 and net.ipv6.conf.default.disable_ipv6 = 1 to /etc/sysctl.conf, then run sysctl -p
  • Router: most consumer routers expose an IPv6 toggle under WAN or Internet settings - disabling it there covers every device on the network at once

4. Deal with WebRTC separately

If only the WebRTC check fails, install a WebRTC-blocking extension or set media.peerconnection.enabled to false in Firefox’s about:config. Note that this breaks video calling in the browser - a browser profile dedicated to private browsing is usually the more practical arrangement. Our WebRTC leak test covers this failure mode in detail.

How This IPv6 Leak Test Works

The test runs entirely in your browser. No result is stored on our servers, and no account is required.

  • IPv4 baseline: we resolve your visible IPv4 address first, so leaked IPv6 results can be compared against the address your VPN is presenting.
  • IPv6-only endpoint: the browser is asked to fetch a host that publishes only an AAAA record. If the request succeeds, IPv6 connectivity is real and we capture the address that arrived.
  • WebRTC candidate harvesting: we open an RTCPeerConnection and read the ICE candidates the browser generates. These come from the OS network stack, not the routing table, which is why they can expose addresses that HTTP requests do not.
  • Correlation: the final verdict compares every address found against your VPN exit address and flags any that belong to a residential ISP prefix.

The full scoring rules are published on our methodology page.

IPv6 Leak Test - FAQ

Common questions about IPv6 leaks, how they happen, and what to do about them.

What is an IPv6 leak?

An IPv6 leak occurs when your device sends traffic over IPv6 while your VPN only protects IPv4. Your VPN client reports a successful connection and IPv4-based leak tests pass, but websites that support IPv6 receive your real address - the one your ISP assigned to your home connection. Because most leak tests only inspect IPv4, this failure can persist for years without the user ever noticing.

How do I know if my VPN leaks IPv6?

Run the test at the top of this page while your VPN is connected. If the IPv6 Leak (HTTP) or IPv6 Leak (WebRTC) row returns an address that does not belong to your VPN provider, you have a leak. A useful cross-check: run the test once with the VPN off and note the IPv6 address, then reconnect and run it again. If the same address appears both times, that traffic never entered the tunnel.

Is an IPv6 leak worse than an IPv4 leak?

In practice, yes. IPv4 addresses are frequently shared by hundreds of subscribers behind carrier-grade NAT, so they identify a region rather than a person. IPv6 prefixes are assigned per household - usually a persistent /64 or /56 - with no NAT in between. A leaked IPv6 address therefore tends to identify a specific home connection, and often a specific device, with far greater precision.

Should I just disable IPv6 completely?

For most people this is the simplest and most reliable fix, and the practical cost is close to zero - virtually every major service is still reachable over IPv4. Disabling IPv6 makes a leak structurally impossible rather than dependent on your VPN client behaving correctly. The exception is anyone who needs IPv6-only resources, such as certain corporate networks or self-hosted services; in that case, use a provider that tunnels IPv6 properly instead.

Which VPNs handle IPv6 correctly?

Mullvad, ProtonVPN and IVPN either route IPv6 through the tunnel or block it at the firewall, and WireGuard-based setups generally handle dual-stack cleanly. That said, behaviour changes between client releases and platforms - the same provider can be safe on desktop and leaky on mobile. Test your own configuration rather than relying on any provider list, including this one.

Why does the WebRTC check fail when the HTTP check passes?

They use different parts of the operating system. Normal web requests follow the routing table, which your VPN modifies on connect. WebRTC asks the OS for the addresses configured on your network interfaces directly, so it can report addresses that no longer have a usable route. The consequence is real: any website can run a few lines of JavaScript and read those addresses without asking permission.

Does my ISP see my traffic during an IPv6 leak?

Yes. Leaked IPv6 traffic never enters the encrypted tunnel - it travels over your ISP’s network in exactly the state it would be in with no VPN at all. Your ISP sees the destinations you connect to, and the destinations see your real address and approximate location. Encryption at the HTTPS layer still protects the contents of each page, but not who you are or what you are connecting to.

Do I need to re-test after updating my VPN app?

It is worth doing. IPv6 handling is one of the most common regressions in VPN clients, because it depends on routing and firewall rules that get rewritten during updates and on OS network-stack changes outside the provider’s control. Re-running this test after a client update, an operating-system upgrade, or a switch to a new server location takes a few seconds and catches the most consequential silent failure a VPN can have.