Your device often has both an IPv4 and an IPv6 address. Here's how a website ends up seeing one or the other — and why it can differ visit to visit.
Run BrowserInsight's IP intelligence tool on a modern connection and you'll often see two addresses at once: an IPv4 address like 198.51.100.20 and an IPv6 address like 2001:db8:85a3::8a2e:370:7334. Sometimes they geolocate to the same city. Sometimes they don't. And if you check again tomorrow, a site that logged your IPv4 address today might log your IPv6 address instead — same device, same network, no setting changed. None of that is a bug. It's the visible result of two separate decisions your operating system and browser make every time you open a connection, and almost nobody sees either one happen.
Key Takeaways
- A large share of home and mobile connections today are dual-stack — your device holds a valid IPv4 address and a valid IPv6 address at the same time, and either one can end up being the address a website records.
- Two different mechanisms decide which address gets used, and they run at different layers: your OS picks a source address per destination (RFC 6724), while the browser's connection logic races both families and keeps whichever answers first — Happy Eyeballs v2 (RFC 8305).
- Which family "wins" is a property of that race on that attempt, not a preference you set — the same machine can show up as IPv4 on one visit and IPv6 on the next.
- Because commercial geo databases cover IPv6 space more thinly than IPv4, your two addresses can geolocate to different cities, or occasionally different countries.
- A VPN or proxy that only tunnels one family leaves the other to travel its normal, untunneled path — a real leak, not a cosmetic mismatch. See WebRTC leak protection and DNS leak prevention for the sibling leak paths that break the same way.
Why you have two addresses in the first place
IPv4 and IPv6 are two independent addressing systems running side by side, not a new version replacing an old one. IPv4's roughly 4.3 billion addresses ran out faster than anyone building the early internet expected, so IPv6 was designed with a vastly larger address space and rolled out gradually — which meant decades of both systems needing to coexist. Many home and mobile networks today are dual-stack: your router or carrier hands your device a usable address in both systems at once. Your device isn't choosing one over the other in the background; it genuinely has both, ready to use, all the time.
Not every network is there yet, though. IPv6 deployment is still uneven between countries and between ISPs, and a connection that hasn't been given IPv6 has exactly one public address to show. If a lookup tool reports only an IPv4 address for you, that's your ISP's rollout, not a fault in the tool — and everything below about which address a site sees simply doesn't apply to you until your provider turns IPv6 on.
That's the setup. What actually determines which one a given website sees comes down to two separate decisions, made by two different pieces of software, at two different moments.
Decision 1: the OS picks a source address per destination
Before any connection attempt happens, your operating system's networking stack has to decide which of your local addresses to use for a given destination — a single network interface commonly holds several IPv4 and IPv6 addresses at once. This is default address selection, standardized in RFC 6724, and it runs a fixed set of rules: prefer a matching scope, prefer the address whose prefix shares the most bits with the destination, prefer a temporary IPv6 address over a permanent one when both are candidates, and several more tie-breakers after that. None of these rules ask which protocol you'd rather use — they're purely about picking the most appropriate source address, given the destination and whatever addresses your interface currently holds.
Decision 2: the browser races both families and keeps the winner
Picking a source address doesn't decide which family — IPv4 or IPv6 — actually carries the connection to a dual-stack destination. That's a separate, later decision, made by the connection logic in the browser (or in the OS networking library it calls) once the resolver has returned both an IPv4 and an IPv6 address for the site's hostname. Older implementations tried one family, waited for it to fail or time out, and only then fell back to the other — which made broken or slow IPv6 paths a real cause of pages loading noticeably slower. The current fix is Happy Eyeballs v2, specified in RFC 8305: the browser starts a connection attempt to the IPv6 address, waits a short interval (RFC 8305 recommends around 250 milliseconds), and if IPv6 hasn't succeeded by then, fires off an IPv4 attempt too — running both in parallel and completing the connection over whichever one answers first. The loser is simply abandoned.
Put those two mechanisms together and the answer to "which address does a website see" is: whichever family won that specific race, carried by whichever source address the OS selected for it. Neither decision is something you set once. Both run again, independently, on every new connection.
There's no client-side way to watch this race happen, either. The browser's Network Information API (navigator.connection) reports your connection's general type and estimated speed to a page — it says nothing about which address family a request actually used. That information only exists on the receiving end, which is exactly why a tool like IP intelligence has to ask the server what it saw rather than reading it out of the browser.
Consequence 1: the same device can show up as IPv4 today, IPv6 tomorrow
Because the race is re-run per connection and its outcome depends on transient conditions — DNS response timing, network congestion, which resolver answered first — the exact same laptop on the exact same Wi-Fi network can be logged as an IPv4 visitor on one page load and an IPv6 visitor on the next. Be realistic about the frequency, though: on a healthy dual-stack connection IPv6 usually wins and keeps winning, so the flip is not something you'll see minute to minute. It tends to surface when something shifts underneath — a congested or degraded IPv6 path, a different resolver answering, a site that has IPv6 on some hostnames and not others, or you moving between networks. If you're trying to explain a login history, a rate limiter, or an allowlist rule that behaves inconsistently, "which family the race picked that time" is often the missing variable, not a sign that something is broken.
Consequence 2: your two addresses can geolocate differently
IPv4 address space has been allocated and mapped by commercial geolocation databases for decades; IPv6 space is comparatively new and far more sparsely covered, since huge blocks were only recently assigned and many providers route it through infrastructure the databases haven't fully mapped yet. The practical result is that your IPv4 and IPv6 addresses can resolve to different cities — sometimes different countries — even though both genuinely originate from the same connection. That's not a leak or an error on your side; it's a gap in how completely each address space has been mapped. IP geolocation accuracy covers the databases and signals behind that mapping in full; this is simply the specific case where the two lookups for one connection disagree.
Consequence 3: a tunnel that only covers one family leaks the other
This is the consequence worth actually checking. Some VPN clients and proxy configurations only intercept IPv4 traffic — either by design or because IPv6 support was added late or not at all. When that happens, your IPv4 traffic goes through the tunnel as intended, but your device's IPv6 address is still live and still wins the Happy Eyeballs race on any dual-stack site that supports it, sending that traffic out over your real, untunneled connection. The site sees your VPN's IPv4 exit address and your actual IPv6 address on the very same page load. That's a genuine IPv6 leak, not a cosmetic inconsistency, and it sits alongside the other leak paths that undermine a tunnel the same way: see WebRTC leak protection for how ICE candidate gathering does the same thing at the media-connection layer, and DNS leak prevention for how an unencrypted resolver query bypasses the tunnel entirely. A leak test that only checks whether your IPv4 address changed can miss this completely — it has to check both families.
Consequence 4: CGNAT is an IPv4-only problem
Carrier-Grade NAT — where an ISP shares one public IPv4 address across hundreds or thousands of subscribers — exists specifically to stretch a shrinking IPv4 supply. IPv6's address space is large enough that providers hand out dedicated blocks per customer instead, so your IPv6 address is typically not shared with anyone. That cuts both ways. On IPv4, sharing an address with strangers means a single bad actor on the same CGNAT pool can get the whole shared address flagged, which is exactly the mechanism behind flagged as a VPN when you aren't — your IPv6 address, being unshared, doesn't carry that specific risk. But it also means an unshared IPv6 address is a slightly more precise handle on you individually, with no other subscribers' traffic mixed in to blur the picture. (The lease/rotation mechanics behind why any address changes over time are covered in full in why your IP address keeps changing — this is only about the sharing difference between the two families.)
What you can check right now
Load IP intelligence and look at both addresses it reports for your connection:
- Do they geolocate to the same place? If not, that's IPv6's thinner database coverage at work, not an error — see IP geolocation accuracy for why.
- If you're running a VPN or proxy, does it show your tunnel's IPv4 exit and a non-tunnel IPv6 address? If your real IPv6 address is visible alongside a tunneled IPv4 one, your tunnel doesn't cover IPv6, and you're leaking through it on every dual-stack site.
- Reload a few times. On a working dual-stack connection this will usually stay put, because IPv6 keeps winning the race — a stable result is the normal outcome, not evidence that nothing is being raced. If it does change between loads with nothing else different, that's the race resolving differently as conditions shift, which is equally expected and not a fault.
Where this fits next to the site's other IP posts
It's easy to conflate this with three other mechanisms that live on adjacent pages here, so to be explicit about the boundary: IPv6 privacy extensions is about the rotating temporary suffix of your IPv6 address changing over time on the same network; why your IP address keeps changing is about DHCP leases and CGNAT reassigning your address over time; IP geolocation accuracy is about how any single address maps to a place. This post is about neither rotation nor mapping — it's about which of your two simultaneously valid addresses a given server observes on a given connection, and why that choice isn't yours to make.
Frequently Asked Questions
The tool only shows me one address. Is something broken?
Almost certainly not. The usual reason is that your ISP or mobile carrier hasn't deployed IPv6 on your connection, so there is genuinely only one public address to report — IPv6 rollout still varies a lot between countries and providers. The less common reverse case is an IPv6-only network reaching IPv4 sites through a translation gateway, where the IPv4 address a site logs belongs to your carrier rather than to you. Either way, a single address means there is no race to run.
Why does a website sometimes show my location as being in the wrong country?
If it's specifically your IPv6 address being geolocated, thinner database coverage of IPv6 address space is a common cause — see IP geolocation accuracy for the full picture, including the IPv4-side causes.
Can I force my browser to always use IPv4 or always use IPv6?
Most operating systems let you disable one protocol at the network-interface level, which removes it from the Happy Eyeballs race entirely. That's a blunt instrument, though — it affects every connection on that interface, not just the one you're troubleshooting, and disabling IPv6 doesn't make you more private, it just removes one of your two addresses from the picture.
Is having both an IPv4 and an IPv6 address a privacy risk?
Not inherently. It does mean there are two addresses worth checking instead of one, particularly when verifying that a VPN or proxy is fully covering your traffic — an IPv6 address left outside the tunnel is a real leak, as covered above.
Does Happy Eyeballs mean IPv6 is always tried first?
It's given a head start (RFC 8305 suggests roughly 250ms) before IPv4 is also attempted, and whichever completes the TCP handshake first wins — so IPv6 has priority when it's fast and working, but a slow or broken IPv6 path yields to IPv4 within that same connection attempt rather than failing outright.
Conclusion
Two addresses, two independent decisions: your OS picks which local address is appropriate for a destination, and your browser races both protocol families and keeps whichever one answers first. Neither decision is visible from inside the browser, and neither is something you configure per visit — which is exactly why the address a site sees can shift between page loads with nothing on your end having changed. The one place this stops being trivia and starts mattering is a tunnel: if you're relying on a VPN or proxy, checking that it covers both families is the difference between a private connection and one that's quietly leaking through the address you forgot you had.
Recommended Reading:
