IPv4 works but IPv6 fails: a diagnostic checklist
Separate DNS publication, probe connectivity and the website’s IPv6 service.
check.uk.app technical team · Reviewed 26 September 2026
A browser can hide the failing path
AAAA records publish IPv6 addresses; they do not prove the web service works there. Clients using Happy Eyeballs can succeed through another address family while an IPv6 path is broken. Test IPv4 and IPv6 explicitly instead of treating a successful browser visit as proof of both.
Compare the same hostname and URL
Replace example.com with your site and run both commands from a host with working IPv6. In PowerShell use curl.exe. These bounded GET requests preserve hostname-based TLS verification and do not follow redirects. Compare status, selected IP and saved content; inspect a redirect destination separately.
curl -4 --silent --show-error --connect-timeout 5 --max-time 15 --output ipv4.html --write-out "HTTP %{http_code}; IP %{remote_ip}\n" https://example.com/
curl -6 --silent --show-error --connect-timeout 5 --max-time 15 --output ipv6.html --write-out "HTTP %{http_code}; IP %{remote_ip}\n" https://example.com/Check the probe before blaming the site
The check.uk.app IPv6 section tests the submitted URL from its probe. If the probe has no IPv6 route, the result is unavailable, not a website failure. A timeout from one location also cannot identify the responsible network by itself. Repeat from another known-working IPv6 connection.
Trace the failure by layer
Compare authoritative and recursive AAAA answers with your assigned addresses. Confirm the address is configured, routing works, and the web server or proxy listens on IPv6 at the expected port. Review IPv6 firewall rules independently of IPv4.
If connection succeeds but TLS fails, check hostname coverage, the certificate chain and the virtual host selected on the IPv6 listener. If HTTP differs, compare proxy backends and application routing. For transfers that stall after connecting, investigate the path MTU and required ICMPv6 handling; do not disable TLS checks to mask a failure.
Verify recovery without disrupting IPv4
Save DNS values, TTLs and server settings before a change. Change the identified layer, then repeat both requests and important user journeys. Confirm both families return the intended site with valid TLS. DNS caches may continue using the old AAAA until expiry.
The sample command options are tested on isolated IPv4 and IPv6 loopback listeners, including a closed-port failure. This validates the diagnostic procedure, not global IPv6 reachability. Publishing an AAAA record should follow successful external testing, not precede service setup.