The "Works on My Machine" Syndrome
You deploy a new web application. You test it on your office Wi-Fi, it works. You test it on your home broadband, it works. But your analytics show a massive bounce rate for users on T-Mobile, Verizon, and Reliance Jio.
Support tickets roll in complaining that the site "just times out." You check your server logs, and there is no record of these users ever attempting to connect.
Welcome to the silent killer of modern web deployments: A broken IPv6 AAAA Record.
The Mobile Network Reality
In 2026, the global pool of IPv4 addresses is completely exhausted. Major mobile carriers (like T-Mobile in the US) operate IPv6-only networks for their cellular towers. When a mobile user tries to visit a site that only has an IPv4 A record, the carrier uses complex NAT64 translation to bridge the gap.
However, if your domain does have an IPv6 AAAA record, modern smartphones and browsers will aggressively prioritize it over IPv4.
The crisis occurs when a sysadmin adds an AAAA record to their DNS to "future-proof" the site, but fails to properly configure the origin server to accept IPv6 traffic.
The Misconfiguration: DNS Points to Nowhere
Here is the exact scenario that breaks your site:
- You add an
AAAArecord pointing to your server's IPv6 address (2001:db8::1). - A mobile user on an IPv6 network looks up your domain. Their phone prefers IPv6, sees the
AAAArecord, and attempts to connect to2001:db8::1. - Your Nginx/Apache server is only configured to listen on IPv4 (
listen 80;). It drops the IPv6 packets. - The user's phone sits there waiting for a response that will never come. The site times out.
Because the packets were dropped at the network interface layer, they never reached your web server logs. It looks like a ghost issue.
How to Audit Your IPv6 Stack
If you are going to publish an AAAA record, you must ensure the entire stack supports it.
1. Verify the Web Server Binding If using Nginx, your server block must explicitly listen on the IPv6 wildcard address:
server {
listen 80;
listen [::]:80; # This is required for IPv6
server_name example.com;
}
2. Verify the Firewall
Check ufw or your cloud Security Groups. You must allow traffic on TCP 443 for IPv6 rules, not just IPv4.
3. Use the Dual-Stack Test
Never assume IPv6 works just because IPv4 works. Use our DNS Lookup Tool to verify your AAAA record exists, and then explicitly test connecting to that specific IPv6 address using curl:
curl -6 -v https://example.com
If you don't have the time to properly configure and secure your server's IPv6 network stack, delete your AAAA record. It is vastly better to rely on carrier NAT64 translation (which works reliably) than to publish a broken AAAA record that sends 30% of your mobile users into a black hole.