IPv6 Readiness Check: Is Your Website Truly Accessible on Both Protocols?

Last year I got paged at 2:14 AM on a Tuesday. The alert said "IPv6 HTTP check failed" for a client's production site. I logged in, ran curl -4 https://example.com. Fast response. Clean HTML. Then curl -6 https://example.com. Connection timed out. The site had been unreachable over IPv6 for six days. Nobody noticed because the monitoring had been checking IPv4 only. A firewall rule change the previous week had added new rules to iptables but not ip6tables. That one missing line cost the client roughly 40% of their mobile traffic from Germany and India for nearly a week.

I've been running infrastructure for 18 years. I've seen this exact story play out dozens of times with different specifics but the same root cause: nobody was watching IPv6. This post is about how to actually check if your site works on both protocols, the specific commands to run, the config mistakes to look for, and how to set up monitoring so you never get that 2 AM page about a week-old outage.

Two Protocols, Two Separate Stacks

This is the thing most people miss. IPv4 and IPv6 are not the same system with longer addresses. They are two independent network stacks that happen to run on the same hardware. Different DNS records. Different firewall rule sets. Different routing tables. Different peering agreements between ISPs. When one breaks, the other keeps working. That's the problem.

DNS: A Records vs AAAA Records

IPv4 addresses live in A records. IPv6 addresses live in AAAA records. They're managed separately. You can update one without touching the other. This is exactly how stale AAAA records happen after a server migration.

Check yours right now:

dig A example.com +short
dig AAAA example.com +short

If the A record points to your current server and the AAAA record points to an IP you don't recognize, you have a problem. If there's no AAAA record at all, that's a different conversation (you might want one), but at least it's an intentional state rather than a broken one.

Firewalls: iptables vs ip6tables

This is the gotcha that bites ops teams the most. On Linux, iptables handles IPv4 traffic. ip6tables handles IPv6. They are completely independent rule sets. Adding -A INPUT -p tcp --dport 443 -j ACCEPT to iptables does nothing for IPv6 traffic. You need the same rule in ip6tables.

Quick audit:

iptables -L -n | grep 443
ip6tables -L -n | grep 443

If the first command shows an ACCEPT rule and the second shows nothing (or a default DROP policy with no exception), your IPv6 visitors are hitting a wall. I've seen this after every kind of firewall tooling change. Team switches from UFW to raw iptables, migrates the IPv4 rules, forgets IPv6 exists.

If you're on nftables, the situation is slightly better since you can define rules that apply to both ip and ip6 families in the inet table. But I've seen plenty of configs that only define the ip family. Check with:

nft list ruleset | grep -E "table (ip|ip6|inet)"

Web Server: Listen Directives

Nginx requires separate listen directives for each protocol. This is correct:

listen 443 ssl;
listen [::]:443 ssl;

This only serves IPv4:

listen 443 ssl;

No error. No warning in the logs. Nginx just silently doesn't bind to the IPv6 address. Apache has similar behavior with its Listen directive. I've seen configs that were correct for years, then someone "cleaned up" the vhost file and removed the [::] line because they thought it was a duplicate.

Verify what your server is actually listening on:

ss -tlnp | grep 443

You should see entries for both 0.0.0.0:443 (IPv4) and [::]:443 (IPv6). If you only see the first one, your web server isn't accepting IPv6 connections.

Routing: Separate Paths Through the Internet

IPv4 and IPv6 packets take different physical paths through the internet. Different backbone providers, different peering points, different cables. An ISP can have excellent IPv4 connectivity to your hosting provider and terrible IPv6 routing. I've personally traced a situation where IPv6 packets from a German ISP to a server in Frankfurt were routing through Amsterdam and London before coming back to Frankfurt, adding 60ms of latency. IPv4 went direct. Same ISP, same city, same server.

You can see this yourself:

traceroute -4 example.com
traceroute -6 example.com

Compare the hop counts and latencies. If the IPv6 path has 3-4 more hops and 50-100ms more latency, that's suboptimal routing. Your hosting provider may need to adjust their IPv6 peering.

The Diagnostic Checklist

Here's the sequence I run whenever I'm auditing a site's IPv6 readiness or diagnosing a dual-stack issue. Do this for every domain and subdomain you care about.

1. DNS Verification

# Check that both record types exist and point to current IPs
dig A example.com +short
dig AAAA example.com +short

# Check subdomains too
dig A api.example.com +short
dig AAAA api.example.com +short
dig A cdn.example.com +short
dig AAAA cdn.example.com +short

Every IP that comes back should be one you recognize and currently own. Stale AAAA records pointing to decommissioned servers are the number one cause of IPv6-only outages in my experience.

2. Connectivity Test

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

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

Both should return the same status code in similar time. If IPv4 returns 200 in 0.3s and IPv6 times out or returns a different code, you have a protocol-specific issue.

3. SSL Certificate Check

# Verify cert over IPv4
echo | openssl s_client -connect example.com:443 -4 2>/dev/null | openssl x509 -noout -subject -dates

# Verify cert over IPv6
echo | openssl s_client -connect example.com:443 -6 2>/dev/null | openssl x509 -noout -subject -dates

The certificate subject and expiry dates should be identical. If they differ, your IPv4 and IPv6 connections are terminating at different servers with different certificate configurations. This happens more often with CDN setups where IPv6 traffic hits a different edge pool.

4. Port Accessibility

# Check if port 443 is open on both protocols
nc -z -w5 -4 example.com 443 && echo "IPv4 port 443 open" || echo "IPv4 port 443 CLOSED"
nc -z -w5 -6 example.com 443 && echo "IPv6 port 443 open" || echo "IPv6 port 443 CLOSED"

This is the fastest way to check if a firewall is blocking one protocol. If IPv4 says open and IPv6 says closed, go look at your ip6tables/nftables rules.

Real Failures I've Investigated

Theory is nice. Here's what actually happens in production.

The Server Migration That Forgot AAAA

A client migrated from a dedicated server to a cloud VPS. The migration checklist said "update DNS." The engineer updated the A record. The site worked. Ticket closed. The AAAA record still pointed to the old dedicated server, which was wiped and re-provisioned for another customer three days later. For those three days, IPv6 users got the old site (stale cache, then eventually a parking page). After the wipe, they got connection timeouts.

Detection time without IPv6 monitoring: 11 days. A user in India on Jio (IPv6-first carrier) reported it.

Detection time with UptyBots IPv6 monitoring: would have been under 5 minutes.

The CDN That Broke IPv6 SSL

A team enabled a CDN on their primary domain. The CDN published AAAA records automatically, routing IPv6 traffic through CDN edge servers. Great. Except the SSL certificate at the CDN layer wasn't configured for the client's custom domain on IPv6 virtual hosts. IPv4 worked because it hit a different termination path. IPv6 connections got a certificate mismatch error. Desktop browsers silently fell back to IPv4 (Happy Eyeballs algorithm). Mobile apps using strict TLS validation failed hard on IPv6.

The client's own browser testing showed no problems because their browsers fell back silently. Only API clients and strict mobile apps broke. It took a week of user complaints before someone connected the dots.

The Firewall Flush

An ops engineer was debugging a network issue and ran ip6tables -F (flush all rules) to test something. The default policy was DROP. Every IPv6 connection to the server died instantly. The engineer's SSH session was over IPv4, so they didn't notice. The debugging session moved on to other things. The flushed rules were never restored. IPv6 was dead for four days until a monitoring check (that I had set up the month before, thankfully) caught it.

I always tell junior ops engineers: if you flush firewall rules to test something, set a cron job to restore them in 5 minutes. If you forget to remove the cron, the worst that happens is your rules get reloaded. If you forget to restore the rules, the worst that happens is an outage.

The ISP Routing Hole

A hosting provider changed their IPv6 upstream provider. The new provider had poor peering with a major German ISP. IPv4 traffic was unaffected. IPv6 latency from that ISP jumped from 15ms to 200ms, with 30% packet loss. Millions of users in Germany experienced the site as extremely slow or broken, but only when their connections preferred IPv6.

Multi-location monitoring caught this because the check node in Frankfurt showed degraded IPv6 while the node in the US showed everything normal.

IPv6 Adoption: The Numbers You Can't Ignore

If you're thinking "IPv6 is still niche, I can deal with this later," here are the actual numbers:

In India and the US, more than half of your visitors are likely connecting over IPv6. In India specifically, Reliance Jio runs an IPv6-only network. Those users literally cannot reach your site over IPv4 without carrier-grade NAT, which adds latency and can break certain connection patterns. If your IPv6 is broken, those users get a degraded or failed experience.

Setting Up Dual-Protocol Monitoring

Knowing the problem is step one. Here's how to make sure you catch it.

Step 1: Audit Every Domain and Subdomain

Run the DNS checks from the diagnostic section above for every domain you manage. Build a table: domain, A record IP, AAAA record IP, status (both current / stale AAAA / missing AAAA). This is your baseline. Takes 15 minutes and saves you from blind spots.

Step 2: Create Paired Monitoring Targets

In UptyBots, create two targets for each domain that has both A and AAAA records: one forcing IPv4, one forcing IPv6. Same check type (HTTP, ping, TCP). Same interval. Same timeout threshold. Same alert configuration. You want an apples-to-apples comparison.

Step 3: Add Network-Level Checks

HTTP monitoring tells you the application layer works. ICMP ping monitoring tells you the network layer works. Add ping targets for both protocols. Ping checks are faster to execute and can detect network-level failures (routing issues, firewall blocks) before they manifest as HTTP timeouts.

Step 4: Add Port Checks

TCP port monitoring sits between ping and HTTP. It verifies that a specific port is accepting connections. This catches the scenario where the server is reachable (ping works) but the web server process crashed or a firewall rule blocks the port. Add TCP checks for port 443 (and any other ports you expose) on both IPv4 and IPv6.

Step 5: Monitor SSL on Both Protocols

SSL certificate issues can differ between IPv4 and IPv6 when traffic terminates at different servers or CDN edges. Add SSL monitoring to catch certificate expiry, hostname mismatches, and chain issues on both protocols. Our SSL Expiry Countdown tool gives you an instant check right now.

Step 6: Configure Alerts That Distinguish Protocol

Name your targets so you can instantly see which protocol failed. Something like "example.com (IPv4)" and "example.com (IPv6)". When that 2 AM alert fires, you don't want to spend the first five minutes figuring out which protocol is affected. Set up alerts like:

• Both protocols down: Full outage. Telegram alert plus webhook to your incident system. All hands.
• IPv6 only down: Partial outage. Telegram alert. Needs prompt action but you have time to diagnose before escalating.
• IPv4 only down: Same severity as IPv6-only. Don't treat one protocol as less important.
• Latency spike on one protocol: Email alert. Investigate during business hours. Usually a routing change or peering issue.

Comparing IPv4 vs IPv6 Metrics

Once both protocols are monitored, the comparison data tells you things that individual checks cannot. Here's what to look for:

Common Dual-Stack Monitoring Mistakes

Even teams that know they should monitor both protocols make implementation errors. I see these repeatedly.

• Single check, hoping it covers both. A standard monitoring check resolves your domain via DNS and connects to whatever address the resolver returns first. On most systems, that's the IPv4 address. You're not monitoring IPv6 at all. You need explicit, protocol-forced checks.
• Monitoring the CDN but not the origin. Your CDN handles IPv6 automatically. But your origin server (used for API calls, admin panels, CDN cache misses, webhook callbacks) might not. If the CDN cache expires and the origin is IPv6-broken, that subset of requests fails.
• Ignoring subdomains. The main domain is dual-stack and monitored. But api.example.com, staging.example.com, mail.example.com each have their own DNS and their own potential for IPv6 misconfiguration. Monitor each one independently.
• Different alert thresholds per protocol. If IPv4 alerts after 2 failures and IPv6 alerts after 5 failures, you're implicitly saying IPv6 users matter less. Keep thresholds identical.
• Setting it up and never reviewing. Dual-protocol monitoring is not a one-time task. Infrastructure changes constantly. Review your IPv4 vs IPv6 comparison metrics monthly. A gradual divergence in latency or uptime tells you something changed in routing or configuration.

Why It Matters for the Business

I deal in infrastructure, not business cases. But I've learned enough from incident post-mortems to know the business impact:

• Audience coverage. If more than half your visitors are on IPv6 (and in many markets they are), an IPv6 outage is a majority-user outage. Not an edge case.
• Honest uptime numbers. If your SLA dashboard says 99.99% uptime but only measures IPv4, that number is wrong. It doesn't reflect the experience of IPv6 users who saw timeouts for a week.
• Search engine visibility. Google crawls over both protocols. An IPv6 outage can affect crawl quality and, over time, indexing. Your SEO team won't know why organic traffic dropped, and your ops team won't know IPv6 was broken, unless you're monitoring both.
• Faster incident response. When the alert says "IPv6 down, IPv4 fine," the troubleshooting path is immediately narrow: DNS AAAA record, ip6tables, or web server listen directive. Versus "site is down for some users" which could be anything.
• Future traffic. IPv6 adoption goes in one direction. What's 50% today will be 65% in two years. The monitoring you set up now means you're ready, not scrambling after a major outage.

For a deeper look at the hidden impact on IPv6-only users, read the hidden downtime you might miss from IPv6-only users. For hands-on testing steps, see how to test IPv6 connectivity manually. And for the full argument on separate tracking, read IPv4 vs IPv6 monitoring: why you should track both separately.

See setup tutorials or get started with UptyBots monitoring today.