IPv6 and CDNs: Why Your Website Can Be Up on IPv4 but Down on IPv6

You deploy your site behind a CDN. The CDN promises global reach, edge caching, DDoS protection, and high availability. You assume this coverage extends equally to IPv4 and IPv6, because why would it not? The DNS records are in place. The dashboard shows green. Then your IPv6 users start reporting errors, and your monitoring (which only checks IPv4) has no idea anything is wrong.

This scenario is far more common than most teams realize. CDNs are complex distributed systems with separate infrastructure stacks for IPv4 and IPv6, and the two do not always behave identically. In this article, we break down exactly how and why CDN-related IPv6 failures happen, what they look like in practice, and how to detect them before your users do.

How CDNs Handle IPv4 and IPv6 Under the Hood

From the outside, a CDN appears to be a single, unified service. You point your DNS to the CDN, and it handles everything. In reality, the CDN operates two parallel networks:

Separate edge server pools

CDN providers maintain pools of edge servers across their points of presence (PoPs). While many modern edge servers are dual-stack (supporting both IPv4 and IPv6), this is not universal. Some providers have older PoPs in certain regions where IPv6 has not been enabled. Others use dedicated IPv6 edge servers that may have different configurations, different software versions, or different capacity than their IPv4 counterparts.

Independent DNS resolution

When a client resolves your domain, the CDN's authoritative DNS server returns different answers depending on the client's location and protocol. The A record points to an IPv4 edge server, and the AAAA record points to an IPv6 edge server. These may be the same physical machine, or they may be different machines in different locations. The CDN's GeoDNS logic for IPv6 may route clients to different PoPs than it would for IPv4.

Separate routing and peering

CDNs negotiate peering agreements with ISPs and transit providers independently for IPv4 and IPv6. A CDN might have excellent IPv4 peering with a major European ISP but limited IPv6 connectivity to the same ISP, causing IPv6 traffic to take a longer, less reliable path through different transit networks.

Independent WAF and security rules

Web Application Firewall (WAF) rules, rate limiting, and bot detection systems may be configured separately for IPv4 and IPv6 traffic. A rule that works correctly for IPv4 CIDR ranges might be missing or incorrectly applied to IPv6 prefixes, causing legitimate IPv6 traffic to be blocked.

Seven CDN + IPv6 Failure Scenarios You Should Know

Each of these scenarios produces the same frustrating result: your IPv4 users experience no issues while IPv6 users see errors, timeouts, or degraded performance.

1. IPv6 enabled in DNS but not at the CDN edge

This is the most basic failure. Your CDN configuration publishes an AAAA record, but the edge server assigned to serve that IPv6 address is not properly configured to handle requests for your domain. The DNS resolution succeeds, but the connection fails. Users see a timeout, connection refused, or a generic CDN error page.

This commonly happens when IPv6 is enabled at the CDN dashboard level but has not propagated to all edge nodes, or when the CDN requires a separate step to enable IPv6 for each individual domain.

2. SSL certificate deployed only on IPv4 edge servers

CDNs manage SSL certificates across potentially thousands of edge servers. Certificate deployment is typically automated, but the automation may process IPv4 and IPv6 edge pools separately. During a certificate renewal or rotation, the new certificate might reach the IPv4 servers first while IPv6 servers continue serving the old (possibly expired) certificate. The result is that IPv6 HTTPS connections fail with certificate errors while IPv4 works fine.

You can detect this by comparing certificates served over each protocol:

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

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

If the output differs, the CDN has a certificate synchronization issue. Learn more about protocol-specific SSL problems in our article on common IPv6 connectivity issues.

3. WAF or security rules blocking IPv6 traffic

CDN WAF rules often use IP reputation lists, geo-blocking, and rate limiting based on IP addresses. IPv6 introduces challenges:

• IPv6 threat intelligence databases are less mature, so the WAF may default to blocking unknown IPv6 ranges.
• Rate limiting by IP may not correctly account for the way IPv6 addresses are allocated (a single user may have an entire /64 prefix).
• Geo-IP databases for IPv6 are less accurate, potentially causing legitimate traffic from known countries to be misclassified and blocked.
• Custom WAF rules written with IPv4 CIDR notation (like 192.168.0.0/16) do not cover IPv6 traffic at all.

4. Origin server reachable only over IPv4

Some CDNs attempt to connect to your origin server using the same protocol that the client used. If a client connects to the CDN via IPv6, the CDN may try to fetch content from your origin via IPv6 as well. If your origin server only has an IPv4 address, this fetch fails, and the CDN returns a 502 or 504 error to the IPv6 client while IPv4 clients get the cached or correctly proxied response.

Not all CDNs behave this way (many always connect to the origin over IPv4 regardless of client protocol), but it is CDN-specific behavior that you need to verify with your provider.

5. Regional IPv6 edge outage

CDN infrastructure failures are rarely global. More commonly, a specific PoP or region experiences an issue. If the IPv6 edge servers in a particular region go down while IPv4 servers remain healthy, users in that region lose access via IPv6 while the rest of the world is fine. These regional failures are especially hard to detect from a single monitoring location.

This is exactly why multi-location monitoring is essential. A monitoring probe in Frankfurt might show IPv6 as healthy while a probe in Singapore detects a complete outage.

6. Cache inconsistency between IPv4 and IPv6 edge servers

CDNs cache content independently at each edge server. If IPv4 and IPv6 requests are served by different edge servers (or even different PoPs), the cached content may differ. One protocol might serve stale content while the other has the latest version. In extreme cases, a cache purge might propagate to IPv4 edges but not IPv6 edges, leaving IPv6 users seeing outdated content for the duration of the cache TTL.

7. DNS load balancing returning unhealthy IPv6 edges

CDN DNS uses health checks to route traffic away from unhealthy edge servers. If the health check system only monitors IPv4 health, it will not detect an IPv6-specific failure on an edge server. The CDN DNS will continue directing IPv6 traffic to the broken edge while correctly routing IPv4 traffic to healthy alternatives.

Why CDN IPv6 Downtime Is So Hard to Detect

Several factors conspire to make CDN-related IPv6 downtime nearly invisible to typical monitoring and testing:

• Office networks default to IPv4. When you load your site from your desk to check if it is working, your browser almost certainly connected via IPv4. You confirmed the site is up, but you only tested one protocol.
• Most monitoring tools use IPv4 by default. Unless you have explicitly configured separate IPv6 monitors, your uptime dashboard only reflects IPv4 health. It can show 100% uptime while IPv6 has been down for hours.
• CDN status pages report IPv4. CDN provider status pages typically report global availability based on their internal IPv4 health checks. An IPv6-specific issue may not appear on their status page at all.
• User complaints seem random. IPv6 users will report "site is down" while IPv4 users say "works fine for me." Without separate monitoring data, these conflicting reports look like user error or localized ISP issues rather than a systematic CDN problem.

The financial impact of this invisible downtime can be significant. Use our Downtime Cost Calculator to estimate what undetected IPv6 outages may be costing your business.

Real-World CDN IPv6 Failure Examples

Scenario: CDN certificate renewal breaks IPv6 HTTPS

A SaaS company uses a major CDN for their customer portal. The CDN automatically renews SSL certificates every 90 days. During one renewal cycle, the new certificate deploys to IPv4 edge servers within minutes, but the IPv6 edges receive the update 6 hours later due to a deployment pipeline issue. During this window, IPv6 users accessing the portal see "Your connection is not private" warnings in their browsers. The company's monitoring (IPv4 only) shows no issues. Customer support receives tickets from mobile users (who are more likely to be on IPv6) reporting security warnings, but the team cannot reproduce the issue from their office network.

Scenario: CDN WAF blocks IPv6 during a traffic spike

An e-commerce site runs a flash sale. The traffic spike triggers the CDN's rate limiting. The rate limiting rules are configured with IPv4 CIDR allow-lists for known partners and legitimate traffic sources, but the equivalent IPv6 allow-lists were never created. IPv6 traffic from legitimate customers gets rate-limited and returns 429 (Too Many Requests) errors, while IPv4 customers shop normally. The company loses sales from the growing mobile audience connecting via IPv6.

Scenario: Regional CDN PoP drops IPv6 after maintenance

A CDN provider performs maintenance on edge servers in their Tokyo PoP. After maintenance, the IPv4 services come back online automatically. The IPv6 services require a manual configuration step that the operations team misses. Japanese users on IPv6-preferred networks cannot access any site served by that PoP. Sites using the CDN see IPv6 errors only from Japan, and only if they have monitoring probes in the region.

How UptyBots Detects CDN IPv6 Issues

UptyBots is designed to catch exactly the kind of partial, protocol-specific outages that CDNs can cause:

• Independent IPv4 and IPv6 monitors: Each protocol is checked separately on its own schedule, so an IPv6 failure is immediately visible even when IPv4 is healthy.
• Multi-location probes: Checks run from multiple geographic regions, catching CDN edge failures that only affect specific PoPs. A failure visible only from Asia will be detected by the Asian probe even if European and American probes show the site as healthy.
• SSL monitoring per protocol: UptyBots validates SSL certificates independently for IPv4 and IPv6 connections, detecting mismatched certificates, expired certs on one protocol, and handshake failures that only occur on IPv6.
• Response time comparison: By comparing IPv4 and IPv6 response times over time, you can spot CDN routing changes that increase IPv6 latency or cache behavior that differs between protocols.
• Instant alerts: When the IPv6 monitor detects an issue, you receive an alert via email, Telegram, or webhook immediately, even if the IPv4 monitor remains green.

How to Verify Your CDN's IPv6 Configuration

Before setting up monitoring, verify that your CDN is correctly configured for IPv6:

1. Check DNS records. Run dig AAAA yourdomain.com and confirm the returned address belongs to your CDN's IPv6 range (check your CDN's documentation for their IPv6 prefixes).
2. Test HTTPS over IPv6. Run curl -6 -I https://yourdomain.com and verify you get a 200 response with the correct content.
3. Compare SSL certificates. Run openssl s_client over both -4 and -6 and confirm the same certificate is served.
4. Check from multiple locations. Use UptyBots's multi-location checks or online tools to verify IPv6 works from different regions, not just your own network.
5. Review CDN WAF rules. Ensure that any IP-based allow-lists, rate limits, or geo-blocking rules have corresponding IPv6 entries.
6. Check CDN origin settings. Verify how your CDN connects to your origin server. If it uses the client's protocol, ensure your origin supports IPv6 or configure the CDN to always use IPv4 for origin connections.

Best Practices for CDN + IPv6 Reliability

As global IPv6 traffic continues to grow, CDNs that once served primarily IPv4 are being tested on their IPv6 infrastructure in ways they may not be ready for. The businesses that catch these issues early are the ones that monitor both protocols independently, from multiple locations, continuously. The businesses that do not will continue to see "100% uptime" on their dashboards while a growing segment of their audience experiences something very different.

For a deeper look at why dual-stack monitoring is essential, read IPv4 vs IPv6 monitoring. To understand the broader picture of hidden downtime affecting IPv6-only users, see our dedicated guide.

See setup tutorials or get started with UptyBots monitoring today.