How it works
IPv6 Leaks and Why Leak Tests Disagree
A red IPv6 leak result usually means traffic left the tunnel — though some pages flag any IPv6 address, the tunnel's own included. A green one can mean at least three different things, only one of which is good, and the same page often gives both answers minutes apart on an unchanged machine. What decides the outcome is the routing policy your VPN client installed, and there are only three of those.
Dual stack means two independent default routes
A dual-stack machine does not have one route to the internet. It has two, maintained separately: an IPv4 default route from DHCP and an IPv6 default route from router advertisements. They can point at different interfaces, and neither knows about the other.
A VPN tunnel is an interface plus a set of routes. If the client installs only an IPv4 default route, the IPv6 one stays as it was — pointing at your ISP's router. The OS sees nothing wrong: both routes are valid, both get used, and nothing notices that some traffic now takes a different exit.
When reading addresses, ignore anything starting with fe80:. Link-local addresses exist on every IPv6-capable interface and never leave the local link. What matters is a global address from 2000::/3. Unique-local addresses (fc00::/7, in practice fd00::/8) are not internet-routable either.
Why the same test flips between red and green
When a hostname publishes both A and AAAA records, a browser does not choose one. It starts an IPv6 connection and, if that has not completed within a short delay — on the order of a quarter second, varying by browser and version — starts an IPv4 attempt alongside it and keeps whichever finishes first. This is Happy Eyeballs: broken IPv6 costs a fraction of a second, not a timeout.
So leakage is not a state but an outcome, per destination and per moment. Which family wins depends on latency, packet loss, and whether a connection to that host is already open. Implementations differ further: some race only the connection attempts, others also the A and AAAA lookups. An intermittent red result is an accurate report of an intermittent leak.
Three things a tunnel can do with IPv6
- Carry it. The tunnel gets its own IPv6 address and takes over the IPv6 default route — as
::/0, or as the::/1plus8000::/1pair some clients install to outrank the physical default. IPv6 works and exits where IPv4 exits. - Block it. The tunnel claims IPv6 and refuses it: OpenVPN's
--block-ipv6answers IPv6 packets with an ICMPv6 no-route error, Android's "Block connections without VPN" does the same at the OS level. Nothing leaks and nothing works over IPv6; how fast apps fall back to IPv4 depends on whether they get an error back or silence. - Ignore it. No IPv6 address, no route, no filter: the native route survives and anything with a AAAA record may go around the tunnel. This is the leak, and in IPv4-only setups it is the default.
What a green result actually proves
"No IPv6 detected" is the most misread line here. It is equally consistent with no IPv6 on the network, a tunnel that blocks IPv6, a tunnel that carries IPv6 the page failed to use, and the page's own AAAA lookup failing. A page reports only the families it can reach itself, so a sealed tunnel and a broken probe look identical. Trust only the positive result: an IPv6 address that belongs to the same operator as your IPv4 exit.
The DNS half of the problem
Resolution and routing are separate decisions and can fail in opposite directions at once. A tunnel can handle the resolver perfectly — queries go through the tunnel, nothing to see on a DNS leak test — and hand the system a AAAA record it then connects to over the native IPv6 path. The lookup was private; the connection was not. The inverse holds on mobile: DNS64 synthesizes AAAA records for IPv4-only destinations, so a AAAA proves nothing by itself.
Checking it yourself on a desktop
- 1List global IPv6 addresses with the tunnel up:
ip -6 addr show scope global,ifconfig,ipconfig /all. Skipfe80:lines. - 2Show the IPv6 default route:
ip -6 route show default,netstat -rn -f inet6, ornetsh interface ipv6 show route. - 3Ask the kernel which interface a real destination would use — this settles route precedence:
ip -6 route get 2606:4700:4700::1111on Linux,route -n get -inet6 2606:4700:4700::1111on macOS,Find-NetRoute -RemoteIPAddress 2606:4700:4700::1111in PowerShell. The interface in the answer is the verdict: a tunnel device (utun,wg0,tun0) or a physical one. - 4Read the policy off that, not off
::/0alone: a physical interface means ignore — you are leaking; a tunnel interface with connections failing instantly means block; one with working IPv6 means carry. - 5Repeat after sleep or a reconnect: some clients never reinstall routes.
Checking it on a phone
- Phones do not expose the route table without root, so read the interface addresses instead: on iOS, Settings, Wi-Fi, the (i) beside the network; on Android, the connected network's details under Wi-Fi settings, or About phone, Status. Neither offers a way to switch IPv6 off for Wi-Fi.
- The tunnel side is in the client. WireGuard-style apps show the tunnel's Addresses and Allowed IPs — that is its route table. An IPv6 address plus
::/0means carry; neither, while the phone holds a global IPv6, means ignore. - Android's "Block connections without VPN", with always-on, is the OS-level block policy. It covers ordinary app traffic rather than every packet: system connectivity checks are exempt.
Switching IPv6 off is a workaround, and it costs something
It does work: with no global IPv6 address there is nothing to leak and every test goes green. But the green comes from the removal, not from a fixed tunnel, and it will leak again on the next network with IPv6. On a fixed line the cost is modest — destinations reachable only over IPv6, more time behind carrier-grade NAT. On Windows, Microsoft's guidance is against unbinding IPv6 from an adapter and points at preferring IPv4 rather than removing it.
On mobile the cost is not modest. Many carriers run IPv6-only access with NAT64 and DNS64 in the network and a translator on the handset — the 464XLAT arrangement — so the IPv4 your apps see is synthesized locally on an IPv6-only path. Setting the APN protocol to IPv4 there asks for a service the carrier may not run: outcomes range from a slower legacy path to no mobile data, and the setting outlives the session that prompted it.
The repair belongs on the tunnel side: if the exit has IPv6, carry it; if not, block it explicitly.
/64 prefix, usually the one assigned to your line, so rotating the low 64 bits does not stop a leaked address from pointing at your connection.My VPN passes the IPv4 leak test but fails the IPv6 one. Is my traffic exposed?
Some of it, some of the time. Only destinations publishing AAAA records are candidates, and for each the browser races both address families and keeps the faster one — so the same site can go through the tunnel on one visit and around it on the next.
Should I disable IPv6 to fix the leak?
It stops the symptom and is defensible as a temporary desktop measure, but it is not a fix: the tunnel stays misconfigured. Microsoft advises against unbinding IPv6 on Windows. On mobile it can be actively harmful: many carriers run IPv6-only access with translation underneath, and there is no clean IPv4 network to fall back to.
The test says no IPv6 detected. Is that a clean pass?
No, it is ambiguous — equally consistent with having no IPv6 at all, with the tunnel blocking it, and with the page's own AAAA lookup failing. The trustworthy result is an IPv6 address belonging to the same operator as your IPv4 exit.
Does a clean DNS leak test mean IPv6 is fine?
No. A tunnel can carry your DNS queries correctly and still let the connection to the returned AAAA address take the native IPv6 route. Check the route table, which answers both questions at once.
Did this help?
Nothing follows from the answer; only we see it.