Website Works over IPv4 but Not IPv6: Look Beyond the AAAA Record

A website loads at home but hangs on a phone connection. Its A record looks correct and the server is running. One useful next check is the IPv6 path. Reaching the IPv4 address and reaching the IPv6 address are separate network tests.

An A record advertises an IPv4 address; an AAAA record advertises an IPv6 address. Publishing AAAA does not make HTTPS available on that address. The server needs the address, a working route and a web service accepting those connections. The DNS guide covers the record lookup behind this.

Try the same hostname through both address families

The commands below are for a Linux shell. Replace example.com with your domain. dig is a DNS query tool, available through your distribution's DNS utilities if it is not installed. The cURL options -4 and -6 select IPv4 and IPv6 respectively.

dig +short A example.com
dig +short AAAA example.com
curl --noproxy '*' -4 -I --connect-timeout 5 --max-time 15 https://example.com/
curl --noproxy '*' -6 -I --connect-timeout 5 --max-time 15 https://example.com/

--noproxy '*' bypasses environment proxy settings for this direct-path test. On a network that requires a proxy for internet access, a direct request may legitimately fail. -I requests HEAD rather than downloading the body. An HTTP 405 from an application that does not support HEAD still means a connection succeeded; it is not an IPv6 connection timeout. For a small GET instead, replace -I with -o /dev/null -D -.

If no AAAA record exists, failure to resolve an address for -6 is expected. An existing AAAA record also does not prove your test machine has IPv6 connectivity. Establish that the testing network has a working IPv6 path, or compare from another suitable network.

Check the listening address on the server

Compare the assigned server address with the published AAAA record. Then check where HTTPS is listening:

ip -6 address show
ip -6 route show
sudo ss -lntp '( sport = :443 )'

A listener on 0.0.0.0:443 is an IPv4 listener. [::]:443 indicates IPv6; whether that socket also accepts IPv4 depends on system and application settings. One listener line does not validate both paths. A service bound only to localhost is another reason an external connection cannot reach it.

When the listener is correct, examine the host firewall, provider network rules and routing independently. An IPv4 rule allowing port 443 does not necessarily allow IPv6. Rules that indiscriminately block ICMPv6 can also break IPv6 behavior, so opening a web port is not a complete network check. Find the missing route or rule rather than disabling IPv6 across the machine.

Test one destination without changing public DNS

With several AAAA addresses, only one destination may be failing. --resolve pins the hostname to one address for this request while preserving the hostname used for HTTPS and certificate verification. The address 2001:db8::10 below is reserved for documentation. Replace it with your real server's IPv6 address:

curl --noproxy '*' -6 -I --connect-timeout 5 --max-time 15 \
  --resolve 'example.com:443:[2001:db8::10]' https://example.com/

Putting an IP address directly in the URL is a different test because virtual-host and certificate selection can change. The cURL manual documents how --resolve preserves the requested host. If certificate validation fails, adding -k does not establish that the website is correctly configured. Fix the certificate presented for that hostname.

A CDN or reverse proxy changes where the public connection ends. The addresses in DNS may belong to that service rather than your origin server. Treat the client-to-CDN path and CDN-to-origin path separately. Knowing who operates the published address is part of understanding what your test actually reached.

Verify the ordinary DNS path after fixing it

Correct a stale AAAA record to the address that serves the site. If you do not provide IPv6 service, remove an obsolete record according to your DNS policy rather than leaving it pointing at an unrelated address. Cached answers still depend on DNS TTL behavior. Removing the record does not repair the IPv6 infrastructure itself.

For the final check, compare the expected HTTP response and the actual website over both families, not just whether a command returned. Test every published AAAA destination, then test again with ordinary DNS resolution. If it works locally but fails from another IPv6-capable network, investigate that path difference before blaming the browser cache.