网站添加AAAA记录后，如果出现“有的人能打开，有的人一直转圈”，先分别验证IPv4和IPv6访问链路。IPv4页面正常，不代表IPv6入口也已就绪；域名能查到IPv6地址，也不代表该地址上的HTTPS服务可达。
排查时应把DNS解析、客户端网络、服务端监听和应用响应分开检查。下面采用Linux或macOS终端语法，仅测试自己管理或已获授权的网站。请把example.com替换为实际域名。命令输出需要在你的环境中获取，本文没有将示例包装成实测结果。
一、先查A和AAAA，确认用户被引向哪里
A记录提供IPv4地址，AAAA记录提供IPv6地址。先查询出现问题的完整主机名，例如www.example.com，而不是只检查不带www的根域名。
dig example.com A +noall +answer
dig example.com AAAA +noall +answer
重点看返回地址、CNAME链和TTL。若AAAA仍指向旧服务器，而A已指向新服务器，两类客户端可能访问到不同环境。一个名称返回多个地址时，也要逐个核对。
没有AAAA回答，不等于DNS查询一定成功：还要留意命令报错，必要时去掉“+noall +answer”查看状态。若权威解析与用户网络的递归解析结果不一致，应继续检查缓存和解析策略。
使用CDN代理时，外部查询到的地址可能属于边缘节点，不是你的云服务器。先确定域名是直连源站，还是经过CDN，再判断AAAA是否正确。[1][2]
二、分别测试IPv4和IPv6，避免自动回退掩盖故障
一些客户端会尝试不同地址族，在某条连接较慢或失败时使用另一条路径。这类Happy Eyeballs机制能改善体验，但不能据此认定IPv6没有问题，也不能假定所有客户端行为相同。[3]
在确认具有可用IPv6公网连接的网络上执行：
curl -4 --noproxy '*' --connect-timeout 5 --max-time 15 -sS -o /dev/null -w 'ip=%{remote_ip} code=%{http_code} total=%{time_total}\n' https://example.com/
curl -6 --noproxy '*' --connect-timeout 5 --max-time 15 -sS -o /dev/null -w 'ip=%{remote_ip} code=%{http_code} total=%{time_total}\n' https://example.com/
-4和-6分别限制地址族；–noproxy ‘*’让本次请求不经过curl配置的代理；连接阶段最多等待5秒，整次请求最多15秒。这些超时值是排查示例，不是性能合格线。命令发送GET请求但丢弃正文，避免只用HEAD测试时受到站点方法限制。[4]
需要依靠代理才能联网的环境不适合直接照搬，应换到获准直连目标网站的网络。本地没有IPv6路由时，-6失败不能证明网站有问题。
- IPv4成功、IPv6超时：检查IPv6地址、路由、安全规则和监听入口；超时本身不能定位到具体一层。
- IPv6提示无法解析：核对AAAA和DNS查询状态，并检查本机curl是否支持IPv6。
- IPv6报证书错误：核对该地址对应的证书和虚拟主机，不要加-k跳过验证后就认定修复。
- IPv6返回403、404或5xx：已收到HTTP响应，应检查访问规则、虚拟主机或后端应用，不能笼统归为“IPv6不通”。
输出code=000不是服务器返回的HTTP状态码，应结合curl报错判断失败阶段。若返回301或302，还要检查Location指向的域名。上述命令没有自动跟随跳转，首页能响应不等于最终页面能打开。[4]
三、指定某个IPv6地址测试，保留域名校验
AAAA有多个地址，或准备更换IPv6入口时，可以用–resolve单独检查端点，无须先改公共DNS：
curl --noproxy '*' --resolve 'example.com:443:[2001:db8::10]' --connect-timeout 5 --max-time 15 -v -o /dev/null https://example.com/
2001:db8::10是文档示例地址，不能作为真实公网目标。请替换为已获授权测试的实际IPv6地址。
–resolve指定本次请求的目标地址，URL仍使用域名，能保留Host、TLS SNI和证书域名校验。直接把HTTPS网址改成IP，可能引入证书不匹配或虚拟主机选择错误。[4]
如果一个地址正常、另一个失败，就检查失败端点的配置。使用CDN时，测试源站与测试边缘入口是两件事，源站可能只允许CDN回源。不要为方便测试向所有来源放开源站。分享-v输出前，检查是否包含内部地址、Cookie等敏感信息。
四、源站要检查地址、路由、监听和安全规则
对于直接对外提供服务的Linux源站，先做只读检查：
ip -6 addr show
ip -6 route show
ss -lnt
依次确认网卡是否持有预期IPv6地址、到测试客户端是否有可用路由，以及HTTPS服务是否监听IPv6地址。只有fe80::开头的链路本地地址，并不能说明已具备公网IPv6入口。[5][6]
看到0.0.0.0:443，只能说明有IPv4通配监听；看到[::]:443说明存在IPv6通配监听，但不能证明云平台路由、防火墙及公网访问正常。容器、负载均衡和反向代理部署还应逐层确认流量落到哪里。[7]
云平台侧也要核对IPv6地址关联、外网连接配置和安全组规则。允许IPv4来源的规则不能直接当作IPv6已放行的证据。只调整业务所需端口和来源范围，不要关闭全部防火墙或把管理端口向全网开放。
如果连接和TLS握手正常，但较大页面或下载持续卡住，还应考虑路径MTU问题。IPv6依赖必要的ICMPv6错误消息，不宜笼统拦截全部ICMPv6；具体规则应遵循服务商与网络设备文档。[8]
五、接了CDN，要分开检查用户入口和回源
“用户通过IPv6访问CDN”和“CDN通过IPv6访问源站”是不同的连接。用户入口支持IPv6，不要求每次回源都采用IPv6。
以Cloudflare官方说明为例，IPv6兼容性开启后会自动生成面向客户端的AAAA记录；对于同时配置IPv4和IPv6源站地址的代理记录，文档说明回源优先使用IPv4。这是该产品的行为，不能套用到所有CDN。[2]
应分别检查边缘IPv6入口是否可达、主机名是否被代理、回源地址与证书是否正确，以及日志中请求是否到达源站。不要因为公共AAAA与源站地址不同就删除它。
“关闭IPv6兼容性”也不是所有套餐都有的通用修复按钮，具体开关和可修改范围应以服务商当前文档及控制台为准。[2]
六、需要先恢复访问时，做有范围的回退
若已确认域名直连源站、IPv4访问正常，而某条AAAA对应的IPv6入口故障，可以在评估用户影响后，临时撤下这条故障AAAA。操作前记录原值、TTL和修改时间，确认修改的是实际故障主机名。
这会让该主机名暂时不再提供原生IPv6地址。对IPv6-only用户的影响取决于所在网络是否提供转换能力，不能承诺所有用户都能自动恢复。CDN代理域名应按服务商入口配置处理，不能照搬删除源站AAAA的方法。[2][3]
DNS修改不会立即清除所有客户端缓存。旧回答可能继续存在，临时调低TTL也不会让已经缓存的旧回答立刻失效。切换后应检查用户侧解析，而不是只看控制台提示保存成功。[1]
恢复IPv6前，先用–resolve验证修复后的端点，再恢复解析或入口配置。避免同时大幅修改DNS、安全组和Web服务，以免无法判断哪一步解决了问题。
七、修复后，按实际访问路径验收
- 在具备IPv6连接的网络上分别运行IPv4和IPv6请求，核对连接地址、证书和HTTP响应。
- 检查www与根域名间的跳转，以及登录、图片、静态资源使用的其他主机名。
- 从至少两个独立网络复查，重点覆盖曾发生故障的用户网络，不只在服务器本机测试。
- 对照CDN或源站日志确认请求到达位置，保留故障地址、修复步骤与回退记录。
- 为IPv4和IPv6分别设置监测。仅做允许自动回退的探测，可能长期漏掉其中一条故障链路。[3]
验收应落到实际访问结果上：解析正确、连接可达、证书有效，最终业务页面也能使用。只看到AAAA添加成功，还不足以证明网站已完成IPv6上线。
参考资料
资料核验日期：2026年9月10日。命令为排查示例，未在读者生产环境执行。