开启IPv6后部分用户访问失败，是DNS还是CDN节点问题？

网站开启IPv6以后，大部分用户访问正常，却不断有用户反馈：

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

关闭IPv6或者删除AAAA记录后，问题似乎马上消失。

这种情况很容易被简单归结为“IPv6网络不好”，但真正的故障位置可能完全不同：

• DNS返回了错误或已经失效的AAAA记录

• 用户所在网络的IPv6连接不完整

• CDN分配的IPv6节点不可达

• 节点能够建立TCP连接，但HTTPS握手失败

• IPv6链路存在MTU或ICMPv6问题

• CDN边缘节点正常，但使用IPv6回源时失败

• 用户设备没有及时从IPv6回退到IPv4

所以，排查时不要一上来就删除AAAA记录。先确认失败发生在DNS解析、网络连接、CDN边缘还是回源链路。

先分清两件事：用户通过IPv6访问CDN，不等于CDN通过IPv6访问源站

一个经过CDN的网站，可能使用下面的链路：

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

也可能是：

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

还可能两段都使用IPv6：

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

这三种情况是相互独立的。

有些站长认为源站没有IPv6，所以CDN不能为用户提供IPv6访问。实际上，很多CDN可以在边缘节点接收用户的IPv6请求，再通过IPv4访问源站。

反过来，即使用户通过IPv4连接CDN，只要源站配置了IPv6地址，CDN也可能选择IPv6回源。

因此，遇到故障时要分别确认：

1. 用户到CDN节点的IPv6连接是否正常。

2. CDN节点到源站的回源连接是否正常。

只检查源站是否支持IPv6，并不能判断用户侧的访问问题。

第一步：检查域名到底返回了什么DNS记录

IPv4地址通常由A记录提供，IPv6地址通常由AAAA记录提供。A和AAAA记录分别把域名映射到IPv4和IPv6地址。

先查询域名的A记录：

dig A www.example.com

再查询AAAA记录：

dig AAAA www.example.com

只看简短结果可以使用：

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

Windows可以使用：

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

如果域名使用了CDN的CNAME，还要继续检查CNAME目标：

dig CNAME www.example.com

可能看到：

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

此时用户最终获得的IPv6地址，可能不是你在DNS控制台手动填写的地址，而是CDN通过CNAME返回的边缘节点地址。

检查时要注意下面几种异常。

域名出现了意外的AAAA记录

有时站长并没有手动添加AAAA记录，但CDN开启IPv6以后，会自动向用户返回IPv6节点地址。

也可能是：

• 旧AAAA记录没有删除

• 其他DNS线路仍保留AAAA记录

• 根域名与www域名配置不一致

• DNS平台自动开启了IPv6解析

• CNAME目标返回了AAAA记录

• 使用了不同权威DNS，部分服务器配置没有同步

不要只看DNS管理后台。最终要以公共网络实际查询结果为准。

AAAA记录指向了源站，而A记录指向CDN

例如：

A      → CDN节点
AAAA   → 源站IPv6

这样一来：

• IPv4用户经过CDN

• IPv6用户绕过CDN直接访问源站

结果可能是IPv4访问正常，IPv6用户却遇到证书错误、防火墙拦截、端口未开放或者源站性能问题。

如果希望IPv4和IPv6都经过CDN，就要确认两类地址最终都指向CDN提供的服务，而不是让AAAA意外暴露源站。

可以使用CDNChart的CDN检测工具，检查域名的CNAME和节点识别结果，再结合本地的A、AAAA查询判断IPv4和IPv6是否走了相同的加速链路。

第二步：分别强制使用IPv4和IPv6访问

只在浏览器里刷新页面，很难知道当前请求到底用了IPv4还是IPv6。

使用curl可以分别强制两种协议。

测试IPv4：

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

测试IPv6：

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

查看完整连接过程：

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

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

curl官方文档中，-4表示只请求IPv4地址，-6表示只请求IPv6地址。

为了便于比较，可以输出连接IP、状态码和耗时：

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/

结果可以这样理解：

需要注意，执行curl -6的测试设备本身必须具备可用的IPv6连接。如果本地没有IPv6，命令失败并不能证明网站的IPv6服务有问题。

DNS正常，不代表IPv6节点一定能连接

DNS能够返回AAAA记录，只代表用户知道应该连接哪个IPv6地址。

接下来还要经过：

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

任何一步都可能失败。

可以先测试基本连通性：

ping -6 www.example.com

Linux上还可以使用：

traceroute -6 www.example.com

或者：

mtr -6 www.example.com

但不能只根据Ping结果判断网站是否正常。

很多服务器或网络会限制ICMP Echo，所以Ping不通，不代表HTTPS一定不通。真正重要的是443端口能否建立TCP连接并完成TLS握手。

可以继续测试：

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

重点观察卡在哪一步：

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

如果卡在Trying [IPv6地址]:443，通常是IPv6路由、端口或防火墙问题。

如果已经显示Connected to，随后在TLS阶段失败，则更应该检查证书、SNI、TLS协议或CDN节点配置。

只测试域名还不够，要测试具体IPv6节点

CDN通常会根据地区、运营商和DNS解析结果，为不同用户返回不同节点。

例如：

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

如果只有其中一个节点异常，站长所在地区可能始终无法复现。

可以先获取AAAA地址：

dig +short AAAA www.example.com

然后使用curl --resolve指定某一个IPv6地址，同时保留正确的域名、Host和TLS SNI：

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

逐个测试不同IPv6节点：

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

curl的--resolve支持把指定域名和端口映射到IPv4或IPv6地址，适合在不修改本地DNS的情况下验证具体节点。

如果某个IPv6地址持续失败，而其他地址正常，就可以把节点IP、测试时间和错误信息提交给CDN厂商，而不是只描述“部分用户打不开”。

为什么浏览器有时会自动切回IPv4？

当域名同时存在A和AAAA记录时，客户端可能同时尝试IPv4和IPv6，并选择更快建立连接的路径。

这种机制通常被称为Happy Eyeballs，目的是避免IPv6路径异常时，用户长时间等待后才改用IPv4。RFC 8305描述了双栈客户端同时处理A和AAAA结果、降低单一路径故障带来的可见延迟。

但这并不意味着发布错误的AAAA记录也不会有影响。

不同的：

• 浏览器

• 操作系统

• App

• 智能电视

• IoT设备

• 企业代理

• 内置WebView

对IPv6失败和IPv4回退的处理速度可能不同。

有的设备能快速回退，有的设备可能等待数秒，还有的应用可能只尝试解析到的第一个地址。于是同一个网站会出现：

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

所以，不能因为自己的浏览器可以自动切回IPv4，就认为AAAA配置没有问题。

部分运营商失败，要检查DNS调度和IPv6路由

如果只有某个地区或运营商的IPv6用户失败，重点检查两个方向。

DNS返回了不同的节点

CDN可能针对不同递归DNS返回不同的AAAA结果。

可以从不同DNS服务器查询：

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

如果条件允许，还要从实际故障地区的网络中查询，因为公共DNS的结果不一定等同于当地运营商DNS结果。

记录：

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

如果异常用户始终解析到同一个IPv6节点，问题可能在DNS调度或节点健康状态。

AAAA正确，但到节点的路由有问题

如果DNS结果合理，而IPv6 TCP连接超时，则更像是：

• 运营商没有到该IPv6前缀的有效路由

• CDN节点的IPv6路由没有正确发布

• 节点入口防火墙未放行443

• 某个自治系统之间的IPv6互联异常

• 用户家庭路由器获得了IPv6地址，但实际上不能正常访问公网

• 企业网络只部署了部分IPv6能力

这时，traceroute -6或mtr -6比反复清理DNS缓存更有价值。

小文件能打开，大页面却卡住，可能是IPv6 MTU问题

IPv6访问故障不一定表现为完全无法连接。

有时会出现：

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

这种现象可能与路径MTU发现有关。

IPv6网络依赖ICMPv6传递“数据包太大”等必要信息。如果中间防火墙错误地拦截相关ICMPv6消息，就可能形成黑洞：

• 小数据包可以通过

• 大数据包无法通过

• 发送端又不知道应该减小数据包

• 连接看起来建立成功，但数据传输会卡住

因此，不要把所有ICMPv6流量都当成普通Ping简单封禁。

如果怀疑MTU问题，可以对比：

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

如果小响应稳定、大响应频繁卡住，应继续检查：

• 服务器网卡MTU

• 隧道或云网络MTU

• 防火墙ICMPv6策略

• CDN与运营商之间的链路

• VPN、PPPoE或IPv6隧道环境

HTTPS失败时，要继续检查证书和SNI

IPv6节点能够连接，不代表HTTPS一定配置正确。

可以使用OpenSSL测试某个IPv6地址的TLS握手：

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

重点查看：

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

如果IPv4和IPv6被分配到不同的服务集群，可能出现：

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

也可能是IPv6地址指向了错误的虚拟主机，导致服务器返回默认证书。

这种问题在浏览器中通常表现为证书错误、连接不安全或者握手失败，而不是普通的HTTP状态码。

CDN边缘正常，还要检查IPv6回源

还有一种故障表现是：

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

这说明用户到CDN的IPv6链路可能没有问题，故障发生在CDN向源站请求内容的阶段。

尤其要检查源站是否同时发布了A和AAAA记录。

假设源站域名是：

origin.example.com

查询结果为：

A       203.0.113.10
AAAA    2001:db8:100::10

如果CDN优先使用AAAA回源，但源站的IPv6地址存在以下问题：

• 80或443端口没有监听IPv6

• 云防火墙没有放行IPv6

• 服务器只有地址，没有默认IPv6路由

• HTTPS证书或SNI配置错误

• IPv6地址已经更换

• Web服务器只绑定了IPv4

• 源站IPv6链路不稳定

用户就可能收到502或504。

分别测试源站IPv4和IPv6：

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

如果源站使用不同Host提供网站，可以通过--resolve测试，并保留业务域名：

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

如果IPv4源站正常、IPv6源站失败，而CDN最近开始优先使用IPv6回源，就要修复源站IPv6，或者临时关闭源站域名的AAAA记录。

为什么删除AAAA以后马上恢复？

删除AAAA后，客户端只能通过IPv4访问，因此绕开了异常IPv6路径。

这能快速止损，但还不能说明故障一定在DNS。

AAAA记录可能只是把用户引导到了一个不可用的IPv6地址。真正的问题仍可能是：

• CDN节点IPv6端口没有开放

• IPv6路由没有发布

• HTTPS配置不完整

• 节点防火墙拦截

• 源站IPv6回源异常

• 用户网络IPv6质量差

另外，DNS记录存在TTL和递归缓存。删除AAAA后，不同用户看到变化的时间可能不同。测试时要确认旧AAAA是否仍存在于本地DNS、运营商DNS或公共递归DNS缓存中。

出现故障时应该保存哪些信息？

为了让CDN或运营商能够定位，至少需要记录：

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

“IPv6打不开”范围太大。

如果能明确说明：

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

CDN厂商就能直接检查具体节点和路由，不必从DNS、证书、源站一路重新猜测。

常见问题

没有AAAA记录，IPv6用户还能访问网站吗？

有可能。部分IPv6-only网络会通过DNS64和NAT64访问仅提供IPv4的服务，但不能假设所有网络都具备这种能力。如果希望正式支持IPv6，仍应提供经过完整验证的双栈访问。

域名有AAAA记录，就代表网站支持IPv6吗？

不代表。AAAA只提供IPv6地址。还需要确保IPv6路由、端口、防火墙、TLS证书、Web服务器和CDN服务全部正常。

IPv6 Ping不通，就说明CDN节点故障吗？

不一定。节点可能限制ICMP Echo，但HTTPS仍然正常。应继续使用curl -6测试443端口和HTTP响应。

为什么手机流量打不开，Wi-Fi却正常？

手机网络和家庭宽带可能使用不同的IPv6方式、DNS服务器和CDN节点。手机网络可能优先IPv6，而家庭宽带最终使用IPv4，所以两边表现不同。

为什么浏览器正常，App却打不开？

浏览器通常实现了较完善的IPv4/IPv6并行连接和回退机制，而某些App、SDK或嵌入式WebView处理IPv6失败的方式不同。应分别测试实际客户端，不能只以桌面浏览器为准。

开启CDN IPv6后，源站也必须支持IPv6吗？

不一定。CDN可以接收用户的IPv6请求，再通过IPv4访问源站。但具体是否支持以及如何选择回源协议，需要查看所使用CDN的产品配置。

应该在DNS里直接添加源站IPv6，还是让CDN返回IPv6节点？

如果网站已经使用CDN，一般应按照CDN提供的接入方式配置CNAME或代理记录。不要自行添加一个绕过CDN的源站AAAA记录，否则IPv6用户可能失去缓存、安全防护和隐藏源站等能力。