Common IPv6 Connectivity Issues I Have Actually Debugged (and How Monitoring Catches Them)

Last year, a client called me because they were losing about 15% of their traffic and could not figure out why. Analytics showed the drop. Server logs showed nothing unusual. The site loaded fine from every machine in their office. I asked one question: "Have you tried loading it over IPv6?" Silence on the other end.

Turns out they had migrated servers three months earlier. Somebody updated the A record. Nobody updated the AAAA record. For three months, every IPv6 user who tried to visit the site hit a dead address. No error page. No redirect. Just a connection timeout. The monitoring dashboard showed 100% uptime the entire time because it was only checking IPv4.

That is the thing about IPv6 problems. They are invisible if you are not looking. Google reports over 45% of connections to its services use IPv6. Mobile carriers in the US, India, and Brazil are IPv6-preferred. Your site might be down for nearly half your potential visitors and your monitoring will not tell you unless you have set up dual-stack monitoring that checks each protocol independently.

Here are the IPv6 issues I have debugged the most. Every single one of them was caught by monitoring eventually. The difference was whether "eventually" meant minutes or months.

1. AAAA Records Pointing Nowhere

This is the most common IPv6 failure and the simplest. The domain either has no AAAA record at all, or it has one that points to an address nobody is listening on. You can check in about two seconds:

dig AAAA example.com +short
2001:db8::1

If that comes back empty, there is no IPv6 address published for your domain. IPv6 users cannot find you. But an empty response is actually the best-case failure. At least it is obvious. The worse scenarios:

• Stale records after migration. You moved to a new server, updated the A record, and the AAAA record still points to the old box. That old box might be powered off. It might be reassigned to someone else. Either way, IPv6 traffic goes into a black hole.
• Typos in the address. IPv6 addresses are long. 2001:0db8:85a3::8a2e:0370:7334 has a lot of hex digits. Swap one group and traffic goes to a completely different host. I once spent two hours on a problem that turned out to be 7334 vs 7343.
• Private addresses published as public. Someone puts an fe80:: or fd00:: address in the public DNS. These are link-local and unique-local addresses. They are not routable on the public internet. No external client will ever reach them.
• Apex vs. subdomain mismatch. www.example.com has an AAAA record. example.com does not. Users who type the bare domain into their browser get nothing over IPv6.

UptyBots resolves DNS for every monitor on every check cycle. If the AAAA record is missing, points to an unreachable address, or changes unexpectedly, you get an alert within minutes. Not three months later when someone finally runs dig.

2. The ip6tables Problem

This one makes me want to put up a billboard. I have seen it dozens of times. A sysadmin sets up firewall rules. Opens port 80 and 443. Drops everything else. Tests it. Works fine. Ships it. Goes home.

The problem: they configured iptables. That is the IPv4 firewall. IPv6 has a completely separate firewall called ip6tables. It has its own rule set. And by default, it might block everything or allow everything, depending on the distro. Either way, it is not what you intended.

# This is your IPv4 firewall. Probably configured.
iptables -L -n

# This is your IPv6 firewall. Probably not.
ip6tables -L -n

The same thing happens in cloud environments, just with different names. AWS Security Groups have separate rules for IPv4 and IPv6 CIDR blocks. Adding 0.0.0.0/0 opens IPv4 traffic. It does nothing for IPv6. You need to add ::/0 separately. I have seen senior engineers miss this.

What it looks like when this happens

• Connection timeout: The most common symptom. The firewall silently drops IPv6 packets. The client sends SYN, never gets SYN-ACK, waits, times out. No error message. No indication of what went wrong.
• Connection refused: Some firewall configs actively reject with a TCP RST or ICMPv6 "administratively prohibited" message. This is actually better because at least the failure is fast.
• Intermittent failures under load: Stateful firewalls track connections. During traffic spikes, the state table fills up. New IPv6 connections get dropped even though IPv4 connections on the same machine work fine because the IPv4 state table has separate capacity.

With UptyBots running separate IPv4 and IPv6 checks, this pattern is obvious. Your IPv4 monitor is solid green. Your IPv6 monitor shows timeouts or connection refused errors. The divergence between protocols is the signature of a missing firewall rule. There is no easier diagnosis.

3. SSL Certificate Not Bound to the IPv6 Socket

Here is one that bites people during initial server setup and then again every time they add a new site. Your web server needs to be told explicitly to listen on both IPv4 and IPv6 for HTTPS. In Nginx, that means two listen directives:

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name example.com;
    ssl_certificate /etc/ssl/certs/example.com.pem;
    ssl_certificate_key /etc/ssl/private/example.com.key;
}

Miss that listen [::]:443 ssl; line and Nginx serves HTTPS on IPv4 only. An IPv6 client connecting to port 443 gets connection refused. Or worse, if some other service is listening on that port, they get a TLS handshake failure with the wrong certificate.

I debugged a variant of this last year where an admin had copied a server block template that only had the IPv4 listen directive. Every new virtual host they added inherited the same bug. IPv4 users saw the correct certificate. IPv6 users got the default server's self-signed cert. Browsers showed a security warning. The admin had no idea because he tested everything over IPv4.

CDN certificates and IPv6

CDNs add another layer of fun. Some CDN providers deploy SSL certificates to their IPv4 edge nodes first and roll out to IPv6 edges on a different schedule. During the gap, IPv6 clients see an expired certificate, a certificate for the wrong domain, or no certificate at all. This is a documented CDN failure pattern that standard monitoring misses because standard monitoring does not check both protocols.

UptyBots's SSL monitoring checks certificate validity, expiry, and chain completeness independently for IPv4 and IPv6. If the IPv6 endpoint returns a bad certificate or fails the handshake, you get a specific alert naming the protocol and the exact error. No guessing.

4. MTU Black Holes

This is the one that makes people question their career choices. IPv4 lets routers fragment oversized packets. IPv6 does not. In IPv6, the sender is responsible for figuring out the right packet size. It does this through Path MTU Discovery (PMTUD): send a packet, and if it is too big for a link along the path, the router sends back an ICMPv6 "Packet Too Big" message telling you the maximum size.

The problem: firewalls love to block ICMPv6. Security teams see ICMP and think "ping, do not need that, block it." But ICMPv6 is not optional in IPv6 the way ICMP is in IPv4. Block ICMPv6 "Packet Too Big" messages and you break PMTUD. The sender never learns its packets are too large. The result:

• Small requests work fine. DNS queries, simple GETs that fit in the minimum IPv6 MTU of 1280 bytes. Everything seems normal.
• Larger responses vanish. Pages with images, API responses with big payloads, file downloads. The TLS handshake completes, the first few bytes arrive, and then the connection hangs. Eventually it times out.

This creates the worst kind of debugging experience. The site "loads" sometimes. Small pages work. Big pages do not. Refreshing occasionally works if the browser uses a cached smaller response. It looks intermittent. It looks like a backend issue. It is actually a network issue caused by a firewall rule someone set three years ago.

Detecting MTU issues with monitoring

In UptyBots, the signature is intermittent IPv6 timeouts while IPv4 checks are stable. Compare the response time graphs side by side. If IPv6 shows spikes and timeouts, especially on endpoints that return large responses, PMTUD is probably broken somewhere on the path.

You can confirm manually:

# Send a 1500-byte packet (default ethernet MTU)
ping6 -s 1452 example.com

# If that times out but smaller packets work, PMTUD is broken
ping6 -s 1200 example.com

If the big packet times out and the small one works, you found your problem. Now go find which firewall is eating ICMPv6 messages and have a conversation with whoever configured it.

5. DNS Propagation That Plays Favorites

DNS propagation is never instant. Everyone knows that. What people do not know is that A records and AAAA records can propagate at different speeds. I have seen situations where the new IPv4 address was live globally within 20 minutes while the AAAA record was still serving the old address 6 hours later. Three reasons this happens:

• Different TTL values. Some DNS management tools let you set TTLs per record type. If your AAAA record has a 24-hour TTL and your A record has a 5-minute TTL, guess which one updates faster.
• Resolver caching behavior. Some DNS resolvers prioritize IPv4 lookups and cache AAAA responses on a different schedule. This is not supposed to happen per the RFCs, but resolvers in the wild do all sorts of things.
• Regional DNS infrastructure. Some regions have fewer IPv6-capable authoritative nameservers. AAAA record updates propagate slower to those regions because there are fewer servers distributing the update.

During a server migration, this is dangerous. You move to the new server, update DNS, verify it resolves correctly from your machine, and decommission the old server. Meanwhile, 30% of your IPv6 users are still pointed at the old address for the next 12 hours.

UptyBots monitors from multiple global locations, each resolving DNS independently. You can see exactly which regions have picked up the new AAAA record and which ones are still resolving the old address. Real-time propagation tracking instead of crossed fingers.

6. Web Server Misconfiguration (The Listen Directive Problem)

Most web servers do not listen on IPv6 by default. You have to tell them. The syntax is different for every server, and getting it wrong is easy:

Nginx

# Correct: both protocols
listen 443 ssl;
listen [::]:443 ssl;

# Wrong: IPv4 only
listen 443 ssl;
# Forgot the [::] line entirely

Apache

# Correct: listens on all interfaces
<VirtualHost *:443>

# Wrong: IPv4 only
<VirtualHost 0.0.0.0:443>

# IPv6 only (rare, but I have seen it)
<VirtualHost [::]:443>

HAProxy

# Correct: both protocols
bind :443 ssl crt /etc/ssl/certs/example.com.pem
bind :::443 ssl crt /etc/ssl/certs/example.com.pem

# Wrong: only IPv4
bind :443 ssl crt /etc/ssl/certs/example.com.pem

There is a subtler version of this bug. Virtual hosts that match by IP address instead of hostname. If your vhost configuration says <VirtualHost 192.0.2.1:443>, requests arriving on the IPv6 address fall through to the default vhost. They get the wrong site, a 404, or a default "Welcome to Nginx" page. I have seen this serve a completely different customer's website to IPv6 visitors. That was a fun incident.

Load balancers make it worse. Cloud load balancers (AWS ALB, GCP) can handle IPv6 at the balancer level so your backends only need IPv4. But if the load balancer is not configured with IPv6 listeners, or if the health checks only test IPv4, IPv6 traffic silently fails even though the backend is healthy.

7. Routing and Transit Issues

IPv6 routing on the global internet is less mature than IPv4 routing. That is just a fact. Some transit providers have incomplete IPv6 peering. Traffic takes weird paths. The problems:

• Asymmetric routing: IPv6 packets take a completely different network path than IPv4 packets. That path might go through providers with less bandwidth, more congestion, or flakier hardware.
• Missing peering: Two networks that peer directly for IPv4 might not peer for IPv6. Traffic that takes one hop over IPv4 takes five hops over IPv6, through providers that may or may not be having a good day.
• BGP problems: Route leaks and hijacks happen in IPv6 just like IPv4. But the IPv6 routing table is smaller and gets less scrutiny. Problems take longer to notice and longer to fix.
• Tunnel overhead: Some networks still use 6-to-4 tunnels, Teredo, or other transition hacks. These add latency, introduce single points of failure, and break in creative ways.

These issues are often regional. A user in Brazil might have a perfect IPv6 path to your server. A user in Indonesia might route through three continents to get there. Single-location monitoring will never catch this. UptyBots's multi-location architecture exists precisely for this kind of problem.

8. Dual-Stack Application Bugs

The infrastructure can be perfect and the application code can still break IPv6. I see these regularly:

• Hardcoded IPv4 addresses. Config files that say 127.0.0.1 instead of localhost or ::1. Works on dual-stack machines. Breaks on IPv6-only hosts. I once tracked down a production outage to a database connection string that had 127.0.0.1 hardcoded. The new server was IPv6-only. The app could not connect to its own database.
• Broken IP validation. Regex patterns that only accept dotted-decimal format. 192.168.1.1 passes. 2001:db8::1 gets rejected. Your application tells legitimate IPv6 clients they entered an invalid IP address.
• Rate limiting by IP. Rate limiting logic that assumes IP addresses are 32 bits. IPv6 addresses are 128 bits. Some rate limiters truncate them, group them wrong, or just crash. I have seen rate limiters that applied per-address limits to IPv4 but per-/64 limits to IPv6, which meant IPv6 users got rate-limited 2^64 times more aggressively.
• IP whitelists. Allowlists that only contain IPv4 addresses. Your monitoring service connects over IPv6, hits the allowlist check, gets denied, and reports "down." The site is up. Your allowlist is just stuck in 2005.

9. How UptyBots Catches Each One

Here is the summary. Each issue has a specific monitoring signature:

The key principle: independent checks for each protocol. A single monitor that resolves to whichever IP version the OS prefers will mask partial outages. You need separate IPv4 and IPv6 monitors. Period. One green and one red is the clearest diagnostic signal you will ever get.

10. Your IPv6 Readiness Checklist

I run through this list every time I set up a new server or take over an existing one. Takes about 15 minutes. Saves you from the kind of ticket that starts with "15% of our traffic disappeared and we do not know why."

1. Run dig AAAA yourdomain.com +short. Confirm the address is correct, publicly routable, and points to your actual server.
2. Run ip6tables -L -n (or check your cloud security group). Confirm ports 80 and 443 are open for ::/0.
3. Check your web server config. Confirm it has both IPv4 and IPv6 listen directives for HTTP and HTTPS.
4. Connect over IPv6 and verify the SSL certificate. Check the subject, the chain, and the expiry. Confirm it matches what IPv4 clients see.
5. Confirm ICMPv6 is not blocked. Especially "Packet Too Big" (type 2). This is not optional.
6. Test AAAA record resolution from at least three different geographic locations.
7. Set up separate IPv4 and IPv6 monitors in UptyBots. Confirm both report UP.
8. Grep your application config for hardcoded 127.0.0.1 references. Replace with localhost or add ::1 equivalents.

IPv6 is not a future concern. It is a current reality for nearly half of internet traffic. The sites that monitor both protocols catch problems in minutes. The sites that do not lose traffic for months without knowing why. I have been on both sides. Trust me, you want to be on the monitoring side.

Read more about why separate IPv4 and IPv6 monitoring matters or learn how to diagnose IPv6 failures with manual tools alongside automated checks.

See setup tutorials or get started with UptyBots monitoring today.