Check IPv4, IPv6 and browser HTTP latency

Check each address family separately

1. Open the IPv4 and IPv6 exit tool and start the check.
2. Record whether each row contains an address or an unknown result.
3. Note your network, browser and VPN state so a later comparison has context.

The browser makes two requests to ipify, one to its IPv4 endpoint and another to its IPv6 endpoint. Each successful result is the public source address that endpoint reports for that request, not a list of every interface on your device.

An IPv6 failure can mean usable IPv6 connectivity is unavailable. Browser restrictions, DNS trouble or endpoint availability can also prevent a response. The page therefore reports unknown rather than declaring that IPv6 is definitely disabled.

Compare the network context, not the strings

IPv4 and IPv6 use different formats and should not match as strings. Ask whether the observed exits fit your intended configuration. Look up each address to compare provider and ASN information; the IP and ASN guide explains those labels.

With a VPN active, an unexpected organization or country is a starting point for investigation. Check whether your configuration routes both address families. A location estimate alone cannot establish a routing failure, and matching location labels cannot prove every connection follows one path.

When comparing Wi-Fi and mobile data, wait for the switch to complete, rerun both checks and save the observations separately. Mixing results from different networks creates a misleading report.

Measure browser HTTPS requests

1. Pause large transfers if you want a quieter baseline, and keep the browser tab active.
2. Open the HTTP latency tool and start it once.
3. Wait for Google DNS and Cloudflare DNS results. Each endpoint receives three attempts, so failed requests can make the check take longer.
4. Read the successful response count alongside the time and keep both in your notes.

Timing runs from the browser request until its JSON response is read. Connection reuse, HTTPS work, endpoint processing, browser scheduling and response handling can affect the result. It is not ICMP ping, a download-speed test or a measurement from global probes.

These requests are not pinned separately to IPv4 and IPv6. Do not interpret the two endpoint timings as a direct speed comparison between address families.

Read the median and response count together

With three successful samples, IP Lens sorts the times and displays the middle value. For illustration only, 40, 55 and 170 milliseconds would display 55 milliseconds. This reduces the effect of one unusually slow attempt, but three observations are still a small sample.

Failed attempts are excluded from the displayed time and reduce the successful response count. In the current implementation, two successful samples display the higher value; one success displays that single time. With no successful samples, the result is unknown. A low time with 1/3 responses is not equivalent evidence to 3/3.

A small difference in one run cannot establish the fastest resolver for every task. This check covers particular HTTPS endpoints from this browser under current conditions.

Use observations to narrow the problem

1. If both exit checks fail, confirm that ordinary websites load. Keep the error and retry once the connection is stable.
2. If only IPv6 is unknown, inspect router, ISP or VPN documentation before changing settings.
3. For partial latency responses, repeat once after a short pause. Compare counts as well as times.
4. If only one endpoint stays unavailable, investigate filtering, extensions or provider status instead of assuming the entire connection is down.
5. For a symptom affecting one hostname, inspect A and AAAA records separately before drawing a routing conclusion.

For ongoing problems, provide support with the check time, network type, response counts and affected endpoint. Avoid sending a complete exported report unless needed: it may include addresses and unrelated checks from the same session. A small, reproducible observation is more actionable than a broad claim that the internet is slow.

Sources and further reading

See ipify's endpoint documentation, MDN's performance.now() reference for browser timing, and Google's DNS-over-HTTPS documentation. Sample collection and incomplete-result behavior here describe IP Lens itself.