Some users cannot access the site after enabling IPv6: Is it a DNS issue or a CDN node issue?

After a website enables IPv6, most users can access it normally, but reports keep coming in:

网站打不开
一直转圈
手机流量无法访问
Wi-Fi正常，移动网络失败
某些地区可以打开，某些地区超时

After IPv6 is disabled or the AAAA record is deleted, the problem seems to disappear immediately.

It is easy to dismiss this as “poor IPv6 connectivity,” but the actual fault may lie somewhere completely different:

• DNS returns an incorrect or stale AAAA record

• The user’s network has incomplete IPv6 connectivity

• The IPv6 node assigned by the CDN is unreachable

• The node can establish a TCP connection, but the HTTPS handshake fails

• The IPv6 path has an MTU or ICMPv6 issue

• The CDN edge node is working, but origin fetch over IPv6 fails

• The user’s device does not fall back from IPv6 to IPv4 in time

So when troubleshooting, do not start by deleting the AAAA record. First determine whether the failure occurs during DNS resolution, network connection, at the CDN edge, or on the origin fetch path.

First distinguish two things: users accessing the CDN over IPv6 does not mean the CDN accesses the origin over IPv6.

A website behind a CDN may use the following path:

用户 ──IPv6──> CDN节点 ──IPv4──> 源站

It may also be:

用户 ──IPv4──> CDN节点 ──IPv6──> 源站

Or both segments may use IPv6:

用户 ──IPv6──> CDN节点 ──IPv6──> 源站

These three scenarios are independent of one another.

Some site owners believe that if the origin does not have IPv6, the CDN cannot provide IPv6 access to users. In fact, many CDNs can accept users’ IPv6 requests at edge nodes and then access the origin over IPv4.

Conversely, even if users connect to the CDN over IPv4, as long as the origin is configured with an IPv6 address, the CDN may choose to fetch from the origin over IPv6.

Therefore, when a fault occurs, verify separately:

1. Whether the IPv6 connection from the user to the CDN node is working.

2. Whether the origin fetch connection from the CDN node to the origin is working.

Checking only whether the origin supports IPv6 is not enough to diagnose access issues on the user side.

Step 1: Check what DNS records the domain actually returns

IPv4 addresses are usually provided by A records, and IPv6 addresses by AAAA records. A and AAAA records map a domain name to IPv4 and IPv6 addresses, respectively.

First query the domain’s A record:

dig A www.example.com

Then query the AAAA record:

dig AAAA www.example.com

For a brief result only, use:

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

On Windows, use:

nslookup -type=A www.example.com
nslookup -type=AAAA www.example.com

If the domain uses a CDN CNAME, continue by checking the CNAME target:

dig CNAME www.example.com

You may see:

www.example.com.  CNAME  www.example.com.cdn-provider.net.

At this point, the IPv6 address the user ultimately receives may not be the address you manually entered in the DNS console, but an edge node address returned by the CDN via the CNAME.

When checking, watch for the following anomalies.

An unexpected AAAA record appears for the domain

Sometimes the site owner did not manually add an AAAA record, but after IPv6 is enabled on the CDN, it automatically returns IPv6 node addresses to users.

It may also be:

• An old AAAA record was not deleted

• AAAA records remain on other DNS lines

• The root domain andwwwdomain configuration are inconsistent

• The DNS platform automatically enabled IPv6 resolution

• The CNAME target returns an AAAA record

• Different authoritative DNS servers are in use, and some server configurations are not synchronized

Do not rely only on the DNS management console. Ultimately, the actual query results from the public internet are what matter.

The AAAA record points to the origin, while the A record points to the CDN

For example:

A      → CDN节点
AAAA   → 源站IPv6

As a result:

• IPv4 users go through the CDN

• IPv6 users bypass the CDN and access the origin directly

The result may be that IPv4 access works normally, while IPv6 users encounter certificate errors, firewall blocks, closed ports, or origin performance issues.

If you want both IPv4 and IPv6 traffic to go through the CDN, make sure both address types ultimately point to the service provided by the CDN, rather than letting the AAAA record accidentally expose the origin.

You can use CdnChart’sCDN check toolto check the domain’s CNAME and node identification results, then combine them with local A and AAAA queries to determine whether IPv4 and IPv6 use the same accelerated path.

Step 2: Force access over IPv4 and IPv6 separately

Simply refreshing the page in a browser makes it hard to know whether the current request is using IPv4 or IPv6.

Usecurlto force each protocol separately.

Test IPv4:

curl -4 -I https://www.example.com/

Test IPv6:

curl -6 -I https://www.example.com/

View the full connection process:

curl -4 -v https://www.example.com/ -o /dev/null

curl -6 -v https://www.example.com/ -o /dev/null

curlIn the official documentation,-4means to request only IPv4 addresses,-6means to request only IPv6 addresses.

For easier comparison, you can output the connection IP, status code, and elapsed time:

curl -4 -sS -o /dev/null \
  -w 'IP=%{remote_ip} Connect=%{time_connect}s TLS=%{time_appconnect}s TTFB=%{time_starttransfer}s Status=%{http_code}\n' \
  https://www.example.com/

curl -6 -sS -o /dev/null \
  -w 'IP=%{remote_ip} Connect=%{time_connect}s TLS=%{time_appconnect}s TTFB=%{time_starttransfer}s Status=%{http_code}\n' \
  https://www.example.com/

The results can be interpreted as follows:

Note that the test device runningcurl -6must itself have working IPv6 connectivity. If there is no local IPv6, a failed command does not prove that the website’s IPv6 service is faulty.

DNS working does not mean the IPv6 node is necessarily reachable

DNS returning an AAAA record only means the user knows which IPv6 address to connect to.

The following steps still need to succeed:

IPv6路由
TCP连接
TLS握手
HTTP请求
CDN回源

Any step can fail.

You can first test basic connectivity:

ping -6 www.example.com

On Linux, you can also use:

traceroute -6 www.example.com

Or:

mtr -6 www.example.com

However, you cannot judge whether a website is working based only on Ping results.

Many servers or networks restrict ICMP Echo, so a failed Ping does not necessarily mean HTTPS is unavailable. What really matters is whether a TCP connection can be established on port 443 and the TLS handshake can complete.

You can continue testing:

curl -6 -v --connect-timeout 10 \
  https://www.example.com/ \
  -o /dev/null

Focus on where it gets stuck:

Could not resolve host
Trying [IPv6地址]:443
Connection timed out
Connected to
TLS handshake
SSL certificate problem
HTTP/2 200

If it gets stuck atTrying [IPv6地址]:443, it is usually an IPv6 routing, port, or firewall issue.

If it already showsConnected toand then fails during the TLS phase, you should check the certificate, SNI, TLS protocol, or CDN node configuration.

Testing only the domain is not enough; test specific IPv6 nodes

CDNs usually return different nodes to different users based on region, ISP, and DNS resolution results.

For example:

北京联通 → 2001:db8:10::20
广州电信 → 2001:db8:20::30
海外用户 → 2001:db8:30::40

If only one of those nodes is faulty, the site owner may never be able to reproduce it from their region.

You can first obtain the AAAA addresses:

dig +short AAAA www.example.com

Then usecurl --resolveto specify a particular IPv6 address while retaining the correct domain name, Host, and TLS SNI:

curl -g -6 -v \
  --resolve 'www.example.com:443:[2001:db8:10::20]' \
  https://www.example.com/ \
  -o /dev/null

Test different IPv6 nodes one by one:

curl -g -6 -I \
  --resolve 'www.example.com:443:[2001:db8:20::30]' \
  https://www.example.com/

curl’s--resolvesupports mapping a specified domain and port to an IPv4 or IPv6 address, making it suitable for validating a specific node without modifying local DNS.

If a particular IPv6 address consistently fails while others work, submit the node IP, test time, and error information to the CDN provider, rather than simply saying that “some users cannot open the site.”

Why do browsers sometimes automatically fall back to IPv4?

When a domain has both A and AAAA records, the client may try IPv4 and IPv6 simultaneously and choose the path that establishes a connection faster.

This mechanism is commonly called Happy Eyeballs. Its purpose is to avoid users waiting a long time before switching to IPv4 when the IPv6 path is faulty. RFC 8305 describes how dual-stack clients process A and AAAA results simultaneously to reduce the visible latency caused by a single-path failure.

However, this does not mean publishing an incorrect AAAA record has no impact.

Different:

• Browsers

• Operating systems

• Apps

• Smart TVs

• IoT devices

• Enterprise proxies

• Embedded WebViews

may handle IPv6 failures and IPv4 fallback at different speeds.

Some devices fall back quickly, some may wait several seconds, and some apps may try only the first address returned by resolution. As a result, the same website can behave differently:

有的人完全正常
有的人第一次打开很慢
有的人一直打不开
换个浏览器又正常

So you cannot assume the AAAA configuration is fine just because your own browser can automatically fall back to IPv4.

If failures occur only on some ISPs, check DNS scheduling and IPv6 routing

If only IPv6 users in a certain region or on a certain ISP fail, focus on two areas.

DNS returns different nodes

The CDN may return different AAAA results for different recursive DNS servers.

You can query from different DNS servers:

dig AAAA www.example.com @1.1.1.1
dig AAAA www.example.com @8.8.8.8

If possible, also query from networks in the affected region, because public DNS results do not necessarily match local ISP DNS results.

Record:

查询时间
递归DNS
返回的CNAME
返回的AAAA地址
TTL
所在地区
网络运营商

If affected users consistently resolve to the same IPv6 node, the issue may lie in DNS scheduling or node health.

The AAAA record is correct, but routing to the node has problems

If the DNS results are reasonable but the IPv6 TCP connection times out, it is more likely to be:

• The ISP does not have a valid route to that IPv6 prefix

• The CDN node’s IPv6 route is not advertised correctly

• The node’s ingress firewall does not allow port 443

• An IPv6 interconnection issue between autonomous systems

• The user’s home router has obtained an IPv6 address but cannot actually access the public internet properly

• The enterprise network has only partial IPv6 capabilities deployed

In this case,traceroute -6ormtr -6is more valuable than repeatedly clearing the DNS cache.

Small files load but large pages stall, possibly due to an IPv6 MTU issue

IPv6 access faults do not necessarily manifest as a complete inability to connect.

Sometimes you may see:

TCP可以连接
TLS偶尔可以完成
小图片能打开
页面加载到一半卡住
大文件下载失败
POST请求发送后没有响应

This phenomenon may be related to path MTU discovery.

IPv6 networks rely on ICMPv6 to convey necessary information such as “Packet Too Big.” If an intermediate firewall incorrectly blocks the relevant ICMPv6 messages, a black hole can form:

• Small packets can pass

• Large packets cannot pass

• The sender does not know it should reduce the packet size

• The connection appears to be established successfully, but data transfer stalls

Therefore, do not simply block all ICMPv6 traffic as if it were ordinary Ping.

If you suspect an MTU issue, compare:

curl -6 -I https://www.example.com/small.txt
curl -6 -o /dev/null https://www.example.com/large-file.zip

If small responses are stable but large responses frequently stall, continue checking:

• Server NIC MTU

• Tunnel or cloud network MTU

• Firewall ICMPv6 policy

• The link between the CDN and the ISP

• VPN, PPPoE, or IPv6 tunnel environments

When HTTPS fails, continue checking the certificate and SNI

Being able to connect to an IPv6 node does not mean HTTPS is necessarily configured correctly.

You can use OpenSSL to test the TLS handshake for a specific IPv6 address:

openssl s_client \
  -connect '[2001:db8:10::20]:443' \
  -servername www.example.com

Focus on:

证书域名
证书链
证书有效期
TLS协议
握手错误
SNI对应的证书

If IPv4 and IPv6 are assigned to different service clusters, you may see:

IPv4节点已经部署新证书
IPv6节点仍使用旧证书

It may also be that the IPv6 address points to the wrong virtual host, causing the server to return the default certificate.

In browsers, this usually appears as a certificate error, an insecure connection, or a handshake failure, rather than an ordinary HTTP status code.

Even if the CDN edge is working, check IPv6 origin fetches

Another failure symptom is:

用户能连接IPv6 CDN节点
TLS握手正常
CDN返回502或504

This suggests that the IPv6 path from the user to the CDN may be fine, and the failure occurs when the CDN requests content from the origin.

In particular, check whether the origin has both A and AAAA records published.

Suppose the origin domain is:

origin.example.com

The query result is:

A       203.0.113.10
AAAA    2001:db8:100::10

If the CDN prefers to fetch from the origin over IPv6 (AAAA), but the origin’s IPv6 address has the following issues:

• Ports 80 or 443 are not listening on IPv6

• The cloud firewall does not allow IPv6

• The server has an address but no default IPv6 route

• The HTTPS certificate or SNI is misconfigured

• The IPv6 address has changed

• The web server is bound only to IPv4

• The origin’s IPv6 path is unstable

users may receive 502 or 504 errors.

Test the origin over IPv4 and IPv6 separately:

curl -4 -I https://origin.example.com/
curl -6 -I https://origin.example.com/

If the origin serves the website under a different Host, you can use--resolveto test while retaining the business domain:

curl -g -6 -I \
  --resolve 'www.example.com:443:[2001:db8:100::10]' \
  https://www.example.com/

If the IPv4 origin works and the IPv6 origin fails, and the CDN recently began preferring IPv6 origin fetches, fix the origin’s IPv6 or temporarily disable the AAAA record for the origin domain.

Why does the issue recover immediately after deleting the AAAA record?

After the AAAA record is deleted, clients can only access over IPv4, thereby bypassing the faulty IPv6 path.

This can quickly stop the damage, but it does not prove the fault is in DNS.

The AAAA record may simply direct users to an unavailable IPv6 address. The real problem may still be:

• The CDN node’s IPv6 port is not open

• The IPv6 route is not advertised

• The HTTPS configuration is incomplete

• The node firewall blocks traffic

• IPv6 origin fetch is faulty

• The user’s network has poor IPv6 quality

In addition, DNS records have TTLs and recursive caches. After you delete an AAAA record, different users may see the change at different times. When testing, confirm whether the old AAAA record still exists in local DNS, ISP DNS, or public recursive DNS caches.

What information should be saved when a fault occurs?

To enable the CDN or ISP to locate the issue, you should at least record:

发生时间和时区
用户所在地区
用户运营商
使用手机流量还是家庭宽带
域名的A和AAAA查询结果
实际连接的IPv6地址
curl -4结果
curl -6结果
IPv6 traceroute或mtr结果
TLS握手结果
HTTP状态码
CDN请求ID

“IPv6 is not working” is too broad.

If you can clearly specify:

2026-09-20 14:30 UTC
广州移动
AAAA解析到2001:db8:20::30
IPv4返回200
IPv6 TCP 443连接超时
其他IPv6节点正常

the CDN provider can directly check the specific node and route instead of guessing again from DNS, certificates, and the origin.

Frequently Asked Questions

Can IPv6 users access a website if there is no AAAA record?

Possibly. Some IPv6-only networks use DNS64 and NAT64 to access services that only offer IPv4, but you cannot assume all networks have this capability. If you want to officially support IPv6, you should still provide fully validated dual-stack access.

Does having an AAAA record for a domain mean the website supports IPv6?

No. An AAAA record only provides an IPv6 address. You also need to ensure that IPv6 routing, ports, firewalls, TLS certificates, the web server, and the CDN service are all working correctly.

If IPv6 Ping fails, does that mean the CDN node is faulty?

Not necessarily. A node may restrict ICMP Echo while HTTPS still works. You should continue usingcurl -6to test port 443 and the HTTP response.

Why does the site fail on mobile data but work on Wi-Fi?

Mobile networks and home broadband may use different IPv6 methods, DNS servers, and CDN nodes. The mobile network may prefer IPv6, while home broadband ultimately uses IPv4, so the two behave differently.

Why does it work in a browser but fail in an app?

Browsers usually implement more robust IPv4/IPv6 parallel connection and fallback mechanisms, while some apps, SDKs, or embedded WebViews handle IPv6 failures differently. Test the actual clients separately; do not rely only on desktop browsers.

After enabling IPv6 on the CDN, must the origin also support IPv6?

Not necessarily. A CDN can accept users’ IPv6 requests and then access the origin over IPv4. However, whether it supports this and how it selects the origin fetch protocol depend on the product configuration of the CDN you use.

Should I add the origin’s IPv6 address directly in DNS, or let the CDN return IPv6 nodes?

If the website already uses a CDN, you should generally configure CNAME or proxy records according to the CDN’s onboarding instructions. Do not add an origin AAAA record that bypasses the CDN yourself, or IPv6 users may lose caching, security protection, and origin hiding capabilities.