You enabled IPv6, added an AAAA record, and the site still works over IPv4. Yet some visitors cannot connect. The fastest way to isolate the fault is to test the address families separately, then trace DNS, the CDN edge, the origin, and the web server. An AAAA record alone does not make the entire path IPv6-ready.
Prove the failure is specific to IPv6
Query the hostname and force a request over each address family:
dig +short A example.com dig +short AAAA example.com curl -4 -I https://example.com/ curl -6 -I https://example.com/
If IPv4 succeeds but IPv6 times out, investigate the AAAA target, routing, edge availability, listening sockets, and IPv6 firewall rules. Test from a network with working IPv6: failure on an IPv4-only workstation does not prove the website is broken. A TLS or HTTP error means the request got further than a TCP timeout.
Check the AAAA target before changing the server
For a site served directly from its origin, AAAA should point to an assigned, routed IPv6 address serving the site. With a CDN, the public AAAA may point to an edge instead. Follow the CDN's prescribed DNS setup; a leftover AAAA pointing at an old origin can send users down a different route. Correct or remove a wrong record, then allow for its existing TTL to expire at resolvers.
Separate edge IPv6 from origin connectivity
IPv6 access to the CDN edge does not imply that the CDN connects to your origin over IPv6. Inspect both legs independently:
Visitor to edge: Confirm public DNS and IPv6 availability for this hostname.
Edge to origin: Check the configured origin hostname, the CDN's address-family behavior, and the origin firewall.
A CDN can serve IPv6 visitors while using an IPv4 origin. If an origin changes to IPv6 before the CDN's origin path is ready, cached pages may work while uncached requests fail. Check provider settings and logs instead of guessing from public DNS.
To bypass the CDN while preserving HTTP Host and TLS SNI, use an IPv6-capable client:
curl -6 -I --resolve example.com:443:[2001:db8::10] https://example.com/
Replace the address with the actual origin IPv6; 2001:db8::/32 is reserved for documentation.
Make sure Nginx listens on IPv6
An IPv6 address on the machine does not mean the web service accepts IPv6. Check active sockets:
sudo ss -lntp '( sport = :80 or sport = :443 )'
Look for [::]:80 and [::]:443, or verify that an upstream load balancer handles IPv6. A typical Nginx dual-stack configuration declares both families:
server {
listen 80;
listen [::]:80;
server_name example.com;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl;
listen [::]:443 ssl;
server_name example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
# Keep your existing location and proxy configuration.
}This example is not a replacement for a live virtual host. Back up the active configuration first. After a targeted edit, run sudo nginx -t, then reload Nginx only if the test passes; retain the previous file for rollback.
Check IPv6 firewall rules and HTTPS
Allowing TCP 80/443 over IPv4 does not necessarily allow those ports over IPv6. Check cloud security groups, the host firewall, a load balancer, and any CDN-origin allowlist. Do not disable the firewall or expose unrelated ports just to test. For UFW, inspect the current settings before changes:
sudo grep '^IPV6=' /etc/default/ufw sudo ufw status numbered
Preserve console access and existing rules before a remote firewall change. If TCP connects but TLS fails, inspect SNI, certificate chain, and the IPv6 virtual host. Probe the origin with the intended SNI hostname:
openssl s_client -connect '[2001:db8::10]:443' -servername example.com -brief
If IPv6 presents the default-site certificate while IPv4 presents the correct one, review listen [::]:443, server_name, and certificate selection. An HTTP 4xx or 5xx after a successful handshake calls for application and origin-log investigation instead.
Verify the repair
Confirm A and AAAA resolve to the intended addresses.
Repeat
curl -4andcurl -6; compare response codes and redirects.Check the TLS handshake and certificate hostname over IPv6.
Try a second real IPv6 network and an uncached URL while reviewing CDN and origin logs.
Make the full IPv6 route work before advertising it through DNS. For CDN-backed sites, validate the visitor-to-edge and edge-to-origin legs separately. If you must roll back a mistaken AAAA record, remember that old DNS answers can remain cached until their TTL expires.
