IPv4 works, IPv6 fails. How to detect a partial website outage

Check DNS and force each address family

Record both A and AAAA answers for the hostname. An AAAA record contains an IPv6 address, but the record alone does not confirm service availability at that address. With a CDN or external proxy, the public address may lead to its entry point. First identify which part of the path you are testing and compare it with the provider's configuration.

From a machine with verified IPv4 and IPv6 connectivity, use curl -4 --http1.1 and curl -6 --http1.1 for the same HTTPS URL. This separates the address families while keeping HTTP/1.1 for the comparison. Save the destination address, result and test time. Also check for a proxy in the test environment, as it can change the network path.

Do not let one client's success mislead you

Happy Eyeballs lets a client stagger connection attempts across available addresses and start another attempt while the previous one is still waiting. A successful IPv4 connection can therefore hide a broken IPv6 path. The result depends on the client and network. Success in your browser does not provide the same evidence as a separate IPv6 test.

RFC 8305 generally treats an attempt as successful when the TCP connection completes. Do not rely on Happy Eyeballs as a universal recovery mechanism for a later TLS or application error. When a visitor reports a failure, record the client, network, time and exact symptom. Distinguish name resolution errors, connection timeouts, TLS failures and unsuccessful HTTP responses.

Check the listener and the packet path

On the relevant Linux server or proxy, compare ss -lnt4 and ss -lnt6. These list listening TCP sockets by address family. A listener alone does not check routing or firewall rules at the provider and host. Inspect the layer reached by the public address. With a CDN, public IPv6 connections may terminate somewhere other than your origin server.

If a connection opens but a larger transfer stalls, also investigate MTU and ICMPv6 Packet Too Big. During Path MTU Discovery, these messages tell the sender to adjust packet size. Blocking ICMPv6 indiscriminately can therefore disrupt communication. This is one diagnostic possibility, not proof of the cause of every timeout. Review rules specifically for the network topology.

After the fix, check both paths and the actual operation

Keep the same hostname and certificate verification enabled during the comparison. Opening an IP address directly changes the test conditions; for HTTPS, curl also checks the certificate name against the name in the URL. Then verify the fix using the normal client protocol and the operation that failed. A forced HTTP/1.1 test is not a complete test of every protocol the service offers.

If you provide IPv6 publicly, configure separate checks for both address families in a tool that can force them. Record the address used, error and response time so automatic path selection does not hide a failure. After changing DNS, the network or a proxy, repeat the comparison from another suitable measurement location too.

• Record A and AAAA answers for the same hostname.
• Force IPv4 and IPv6 from a location with verified connectivity.
• Separate connection, TLS and HTTP issues; investigate MTU too.
• After the fix, monitor both paths and the original user operation.