IPv6 Works for Some Users but Fails for Others: How to Diagnose It

Why IPv6 Breaks for Only Some Users

You enable IPv6 on your server, test it from your office, and everything looks great. Then users report the site is unreachable. The problem is that IPv6 adds three independent failure modes that IPv4 does not have: path MTU discovery black holes, broken tunnel brokers, and DNS resolver behavior differences per client network.

The first diagnostic step is checking what your users actually see. Use the OpsCheck IPv6 Tools to verify AAAA record resolution and connectivity from multiple vantage points. Then use OpsCheck DNS Lookup to confirm your AAAA record is served correctly.

Symptom 1: The Site Works on IPv4 but Times Out on IPv6

This is almost always a PMTUD black hole. IPv6 does not allow routers to fragment packets — the sender must discover the path MTU. If an intermediate router drops ICMPv6 Packet Too Big messages, the connection stalls on large packets.

# Test PMTUD by sending a large ping with the DF-equivalent behavior
ping6 -c 4 -s 1452 example.com

# Test with smaller payload to isolate MTU
ping6 -c 4 -s 1280 example.com

# Check your interface MTU
ip -6 link show eth0 | grep mtu

If small pings work but large ones fail, your MTU is being blocked somewhere. The fix is clamping the MTU on your server to 1280 (the IPv6 minimum) or working with your hosting provider to fix ICMPv6 filtering.

Symptom 2: AAAA Record Resolves but Connection Never Establishes

The DNS returns an AAAA record, but the TCP handshake never completes. This usually means the IPv6 address is reachable from some networks but not others — a routing or firewall asymmetry.

# Verify AAAA from different resolvers
dig example.com AAAA @8.8.8.8 +short
dig example.com AAAA @1.1.1.1 +short

# Test connectivity
curl -6 -v --connect-timeout 5 https://example.com/

# Check if the address is actually listening
ss -6tlnp | grep :443

A common mistake: adding an AAAA record pointing to a tunnel broker address that is only reachable while the tunnel is up. If the tunnel flaps, IPv6 connectivity disappears for everyone whose resolver returns that AAAA record.

Symptom 3: Happy Eyeballs Masks the Real Problem

Browsers use Happy Eyeballs — they race IPv4 and IPv6 connections and use whichever succeeds first. If IPv6 is slow but eventually works, users see no error, just a sluggish site. You only catch this by testing explicitly.

# Force IPv6 and measure time
curl -6 -w "time_total: %{time_total}\n" -o /dev/null -s https://example.com/

# Force IPv4 for comparison
curl -4 -w "time_total: %{time_total}\n" -o /dev/null -s https://example.com/

Real-World Scenario

A hosting customer enabled IPv6 on their VPS via a tunnel broker. The site worked from their office and from their phone on Wi-Fi. A week later, users in Germany reported the site was down. Investigation showed the tunnel broker had a peering issue with Deutsche Telekom — IPv6 packets were black-holed at the peering point. The AAAA record was still served, so German resolvers returned it, but the TCP handshake never completed. Happy Eyeballs saved some users (they fell back to IPv4 after 300ms), but users with aggressive IPv6 preference saw a timeout.

Diagnostic Checklist

• Verify AAAA resolution from multiple public resolvers — use OpsCheck DNS Lookup
• Test large-packet IPv6 connectivity from a known-working network
• Check if your IPv6 address is tunneled or native
• Confirm your firewall allows ICMPv6 (especially Packet Too Big)
• Verify your hosting provider has IPv6 peering to major transit providers
• Use OpsCheck IP Geolocation to check if your IPv6 block geolocation is correct