Dual-stack exit test — are both your IPv4 and IPv6 exposed?

In a dual-stack environment, modern browsers don't pick a protocol at random; they follow RFC 8305 (Happy Eyeballs v2). After resolving both the AAAA (IPv6) and A (IPv4) records, the client sorts candidates per RFC 6724 and then leans slightly toward IPv6. The exact timing: if the A record arrives first, the client waits about 50ms for the AAAA (the Resolution Delay); once a connection is started, it only falls back to the other family if no handshake completes within ~250ms. In practice, as long as your machine has a working IPv6 exit, most requests go out over IPv6 first.

That sets a trap. Many proxy / VPN clients tunnel only IPv4 traffic and leave IPv6 going out over your native line. You think everything is routed through the proxy, but the destination site actually sees a connection from your real IPv6 address — the proxy's IPv4 is barely used. This kind of leak throws no error and shows no warning; the page loads normally and you never notice.

The reverse happens too: some proxy nodes have only an IPv6 exit, and when the site you visit resolves only an A record, traffic falls back to your native IPv4. The only reliable way to tell which stack is exposed is to force one connection over v4 and another over v6, then check whether both echoed exit IPs actually belong to the proxy. That's exactly what the tester below does: it connects to ip4.ipok.io (A record only) and ip6.ipok.io (AAAA only) and lays both real exits side by side for comparison.

To anti-fraud and risk engines, a leaked IPv6 is far more than 'one extra address.' The classic attack is correlation: when a proxy IPv4 and your real IPv6 both appear in the same browser session during one page load, the system binds the two addresses to a single entity. Next time you swap the proxy IPv4 but that real IPv6 (or its /64 prefix) hasn't changed, the account is recognized anyway — in that scenario the proxy is effectively useless.

IPv6's address structure makes correlation easier. ISPs typically hand each home subscriber an entire /64 (or even /56) prefix that stays stable for a long time. Even if you enable privacy extensions so the interface identifier (the lower 64 bits) rotates, the prefix half usually stays put — enough to group every device on that line together. Worse, some older CPE / ONT gear still uses Modified EUI-64, embedding your NIC's MAC directly into the address (inserting FF:FE), which writes a hardware fingerprint into the address that follows you across networks.

So 'I turned on my proxy' and 'I am anonymous' are two different things. What actually decides anonymity is whether any stack — any native local address — was handed to the destination site without your knowledge. Confirm whether you're leaking first; only then talk about hiding. Doing it in the wrong order is wasted effort.

Seeing 'IPv6 privacy extensions (RFC 4941 / RFC 8981),' many people assume turning them on makes IPv6 safe. That's a common myth. Privacy extensions address whether the same device can be tracked across different networks by a single interface identifier — they make the OS periodically generate a random temporary address (preferred for ~1 day, valid for ~2 days by default) for outbound connections, so your MAC isn't baked permanently into the address. They do nothing about the real problem here: your true IPv6 going out directly when it should have gone through the proxy.

Put differently, privacy extensions make your IPv6 address harder to profile over time, but as long as it's still the exit of your real line, the destination site gets your true geolocation, ISP, and /64 prefix right now, and can correlate it with the proxy's IPv4. Privacy extensions are like swapping license plates; a proxy leak is the car still rolling out of your own garage — the former can't stop the latter.

If you care about anonymity, the practical fix has two layers: (1) make your proxy / VPN tunnel both v4 and v6, or simply disable IPv6 at the OS / router level so the machine has only one controlled exit; (2) recheck with a tester afterward — if this page marks the IPv6 exit as 'unreachable,' that stack truly isn't leaking. Keep privacy extensions on if you like, but they are not the cure for a leak.

Open the tester below and it connects separately to ip4.ipok.io and ip6.ipok.io, echoing the real exit IP used on each stack. Reading it is straightforward: if you're on a proxy, both exits should belong to the proxy's range. If one stack shows an address that isn't the proxy's (most commonly the IPv6 line revealing your home broadband's v6), that stack is leaking. If a stack shows 'unreachable / no result,' you simply have no exit for that protocol right now — which is actually good news, since one fewer stack means one fewer leak surface.

Unlike tools that quietly harvest visitors, IPOK only echoes the IP actually used when connecting to its own endpoint: it never uses WebRTC to pierce the real identity behind your proxy, and the server keeps no log pairing your v4/v6. Built by an independent developer, the queries here are stateless — we check IPs, not you. So you can safely test your post-proxy dual-stack state here.

Once you have the result, it's worth also running this site's WebRTC-leak and DNS-leak tests. Dual-stack leaks, WebRTC leaks, and DNS leaks are the three most common side-channels for proxy users; running all three is the only way to truly confirm the anonymity of this particular connection.