About IPv4 & IPv6 Network Connectivity Check
IPv4 & IPv6 Network Connectivity Check tests each address family separately from the browser you are reading this in. It reports whether an IPv4 path, an IPv6 path, or both are usable right now, shows the public address each one presented, and summarises the result as dual-stack or not.
Dual stack means your connection can reach a destination over IPv4 and over IPv6, and the two paths are genuinely independent: different addresses, often different routes, sometimes different providers. Browsers hide that. With Happy Eyeballs a site races both families and quietly uses whichever answers first, so an IPv6 path that is broken but not dead — connecting slowly, dropping large packets, resolving to an unreachable address — never surfaces as an error, only as a page that feels sluggish. Testing each family on its own is the only way to see which half of the connection works.
How to use this developer tool
- Open the tool. Both probes start automatically and run in parallel, each with an eight-second timeout.
- Read the two cards independently: an available card shows the public address that family presented, plus its location, network prefix, and ASN.
- Read the header for the summary — whether this connection is a full dual stack or only one family is usable.
- Press Re-check after changing networks, connecting or disconnecting a VPN, switching a proxy profile, or toggling a browser privacy setting.
- If one family fails, compare the working family's address against your router's status page to locate the break at the router or upstream of it.
Worked example: an IPv4-only connection
A common outcome on consumer and office networks. The IPv4 probe completes and carries a full record; the IPv6 probe times out because nothing on the path can carry it.
Open the tool — both probes start automaticallyCurrent connection: not a full dual stack
IPv4 — available
203.0.113.45
Location Frankfurt · Hesse · Germany (DE)
Network 203.0.113.0/24 · AS64500 Example Transit AB
Time zone Europe/Berlin
IPv6 — unsupported
No public address returned within 8 secondsUnsupported means this browser did not complete the IPv6 probe — a statement about one request from one browser on one network at one moment, not a claim that the ISP has no IPv6 and not an error condition. An IPv4-only connection works perfectly well for the majority of the web.
What each field means and how far to trust it
Both cards show the same record for the address that family presented, and the fields do not carry equal weight.
| Field | Where it comes from | How far to trust it |
|---|---|---|
| Country | Registry allocation plus routing data | High. Wrong mainly for satellite links, anycast, and VPN exits — where it is still right about the exit. |
| Subdivision | Database inference | Moderate. Often right for fixed lines, often wrong for mobile and large hosting prefixes. |
| City | Database inference | Low. Read it together with the accuracy radius, which states how large the circle is. |
| Postal code | Database inference | Low. Present because the record has the field, not because it was measured. |
| Coordinates + radius | Centre of an estimated area | The radius is the honest part. Coordinates alone are never an address. |
| Network prefix | Routing table | High. The block your address sits in, and the field worth logging. |
| ASN | Registry assignment | High. The routing identity of the network announcing the prefix. |
| Organisation | Registered against the ASN | High for who routes the traffic, lower for who bills you. |
Troubleshooting
IPv6 reports unsupported, but the ISP advertises IPv6 and other devices have it.
Why it happens Any single hop can break it: the router is not requesting or delegating a prefix, IPv6 is disabled on this adapter, a VPN client captures IPv4 only and blackholes IPv6, or a corporate resolver returns no AAAA records.
Fix Re-check with the VPN off first, since that is the most common cause by a wide margin. If IPv6 returns, the VPN is the break; otherwise check the router's WAN status page for a delegated prefix before looking at the machine.
The two families report different countries or organisations.
Why it happens Normal and often expected. IPv6 delivered through a tunnel broker, a VPN carrying only one family, or a provider using separate transit per family all produce two genuinely different exit points.
Fix Compare the ASN organisation on each card. Two organisations means two paths, which is a finding rather than a fault — unless you expected both to go through the same VPN, in which case one family is leaking outside it.
Both families fail even though browsing works.
Why it happens A captive portal that has not been accepted, a TLS-intercepting corporate proxy rejecting unknown hostnames, a privacy extension blocking the probe hostnames, or a whitelist-only firewall.
Fix Open one detection endpoint directly in a new tab. A portal page, certificate warning, or block page identifies the cause immediately; a plain address in response means the extension in this tab is the problem.
The address shown here does not match what another site reports.
Why it happens Large networks egress through several public addresses and pick one per connection, and CGNAT pools rotate. The two sites were answered by different exits at different moments.
Fix Compare the network prefix and ASN rather than the exact address. If those match, it is the same egress network and the difference is expected pool behaviour.
When this tool is the right choice
- Establishing whether a connectivity complaint is IPv6-specific before digging into application logs.
- Confirming that a new IPv6 deployment actually reaches the browser, not just the router.
- Checking that a VPN carries both address families rather than leaving one outside the tunnel.
- Capturing the public address and ASN your current connection presents, without typing anything.
When to use something else
- Measuring speed, latency, or packet loss. This establishes whether a family can complete one request, and nothing about how fast.
- Looking up an address other than your own. IP Info accepts a typed address or a batch of up to 100 and performs that lookup on the server.
- Deciding whether a VPN hides you. A matching address proves nothing about WebRTC candidates or DNS resolvers — Browser Leak Check examines those paths.
Privacy and data handling
This check does not go through this site's lookup endpoint. Your browser connects directly to the configured IPv4 and IPv6 detection endpoints, which is what makes the test meaningful: each endpoint can only be reached over its own family and reports the address it saw your connection arrive from. Those endpoints therefore see your public address and request headers, as any server you connect to does. Results are shown for this session only, are not stored, and are not forwarded anywhere by this tool. Because the browser does the connecting, the result reflects the browser's own network view, including any VPN, system proxy, or extension that alters it.
Related developer tools
Frequently asked questions
Does IPv6 unsupported mean something is broken?
Usually not. Large parts of the internet still run IPv4-only, and a working IPv4 path gives normal access to almost everything. The result means only that this browser did not complete the IPv6 probe within eight seconds, on this network, at this moment.
Why do the two families show different locations?
Because they are different addresses on potentially different paths. A tunnel broker, a single-family VPN, or separate transit per family all produce distinct exits with distinct registry records. On a plain dual-stack line the two normally agree on country and often on ASN.
Is this a speed test?
No. Each probe makes one small request and reports whether an address came back. It measures nothing about bandwidth, jitter, or sustained throughput, and a fast result does not indicate a fast connection.
Does the tool send my address to this site?
Not through this site's lookup endpoint. The browser connects directly to the two detection endpoints, and each reports the address it observed. Every server you connect to sees your address; that is how the test works at all.
Why does the check run without my pressing anything?
Both probes are plain HTTP requests revealing only what any website already observes when you visit it, so running them on open saves a click. Re-check repeats them whenever you want a fresh reading.
Can I use this to prove my VPN is working?
Only partially. It shows the public address each family presented, so an unexpected home address is a real finding. It cannot see WebRTC candidates or DNS resolver behaviour, which are the paths that most often bypass a VPN — use Browser Leak Check for those.
Why does re-checking give a different IPv4 address?
Residential lines get a new address when the line reconnects, and carrier-grade NAT assigns from a shared pool that can rotate between connections. Compare the prefix and ASN: if they match, you are still leaving through the same network.