网站刚加了 AAAA 记录或在 CDN 中开启 IPv6，IPv4 用户访问一切正常，部分手机网络、校园网或海外用户却打不开页面。遇到这类问题，先把 IPv4 和 IPv6 拆开测试。它通常不是“网站整体宕机”，而是某一条 IPv6 链路没有配完整。

本文适用于网站新增 IPv6、接入 CDN 后启用 IPv6，或源站改用 IPv6 地址后出现间歇性访问失败的场景。排查顺序是 DNS、访客到 CDN、CDN 到源站、Web 服务监听、防火墙和 TLS。

先确认是否只有 IPv6 失败

域名可以同时有 A 记录和 AAAA 记录。A 记录返回 IPv4 地址，AAAA 记录返回 IPv6 地址。具备 IPv6 网络的设备通常会尝试 IPv6；若 AAAA 指向的地址不可用，IPv6 用户就可能超时，IPv4 用户仍能正常打开。

dig +short A example.comdig +short AAAA example.comcurl -4 -I https://example.com/curl -6 -I https://example.com/

如果 curl -4 返回正常状态码，而 curl -6 超时或无法建立 TLS 连接，排查重点应放在 AAAA、IPv6 路由、边缘节点、端口监听和防火墙。请在具备真实 IPv6 出口的网络中复测；本机没有 IPv6 网络时，curl -6 失败不能单独证明站点故障。

AAAA 记录不能先上、服务后补

最常见的错误是先添加 AAAA 记录，再去配置源站。此时 DNS 已经把 IPv6 用户引导到一个没有绑定、没有路由，或没有开放 80/443 的地址。

• 未接入 CDN：AAAA 应指向对外提供 Web 服务的源站 IPv6 地址。

• CDN 托管 DNS：AAAA 可能指向 CDN 边缘节点，用户不会直接连接源站。

• CNAME 接入 CDN：保留平台要求的 CNAME；不要额外留下指向旧源站的 AAAA 记录。

如果 AAAA 是错误地址，优先删除或改正这条记录。DNS 修改不会让所有网络立即生效，仍需等待原有 TTL 到期。

CDN IPv6 与源站 IPv6 要分别检查

“CDN 支持 IPv6”只表示访客可以用 IPv6 连到边缘节点。它不等于 CDN 一定用 IPv6 回源，也不保证你的源站 IPv6 已正确配置。

1. 访客到 CDN：域名的 A、AAAA 或 CNAME 是否符合 CDN 接入方式，域名是否已开启 IPv6 边缘访问。

2. CDN 到源站：回源主机名解析到哪个地址，CDN 是否支持 IPv6 回源，源站是否允许这条回源连接。

如果 CDN 仍通过 IPv4 回源，源站保留 IPv4 并不影响访客使用 IPv6。反过来，源站改为 IPv6 而 CDN 未启用 IPv6 回源时，常见现象是缓存命中页面正常、缓存未命中请求失败。

curl -6 -I --resolve example.com:443:[2001:db8::10] https://example.com/

将示例地址替换为真实源站 IPv6；2001:db8::/32 仅用于文档示例，不能用于生产。

确认 Nginx 是否监听 IPv6 的 80 和 443

服务器有 IPv6 地址，不代表 Nginx、Apache 或应用进程已接收 IPv6 连接。先在源站查看监听状态：

sudo ss -lntp '( sport = :80 or sport = :443 )'

正常情况下，通常会看到 [::]:80、[::]:443，或由前置反向代理明确接收 IPv6 连接。如果只有 0.0.0.0:80、0.0.0.0:443，服务很可能只监听 IPv4。

server {    listen 80;    listen [::]:80;    server_name example.com;    return 301 https://$host$request_uri;}server {    listen 443 ssl http2;    listen [::]:443 ssl http2;    server_name example.com;    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;}

修改生产配置前备份实际生效的站点文件。完成后先检查语法，再重载服务：

sudo nginx -t && sudo systemctl reload nginx

IPv6 的安全组和防火墙通常是漏项

IPv4 已放行 80/443，并不表示 IPv6 规则也放开了。检查云安全组、主机防火墙、负载均衡或 WAF 的 IPv6 入站策略；如果源站只允许 CDN 回源 IP，还要确认维护了 CDN 的 IPv6 网段。

不要为排障关闭防火墙，也不要把所有 IPv6 端口暴露到公网。网站服务只需要按现有策略开放 TCP 80/443。使用 UFW 时，可先确认 IPv6 是否启用并查看现有规则：

sudo grep '^IPV6=' /etc/default/ufwsudo ufw status numbered

HTTPS 不通时分清 TCP、SNI 与证书

IPv6 下 HTTPS 失败不一定是证书本身的问题。TCP 超时优先检查 AAAA、路由、安全组和监听；TCP 已连接但 TLS 失败，则检查 SNI、证书链以及 IPv6 是否命中了错误的虚拟主机；握手正常但返回 4xx/5xx，才继续查看 Host、应用和回源日志。

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

如果 IPv4 命中正确站点、IPv6 却返回默认站点证书，检查对应 server 块的 listen [::]:443、server_name 与配置加载顺序。

修复后按四步验收

1. 用 dig 确认 A 与 AAAA 返回的地址符合预期。

2. 分别执行 curl -4 和 curl -6，检查状态码、跳转和响应头。

3. 用 openssl s_client 检查证书名称与握手结果。

4. 从另一个真实 IPv6 网络访问首页和一个未缓存 URL，同时检查 CDN 与源站日志。

添加 AAAA 记录前，必须让从 DNS 到服务端口的 IPv6 路径完整可用。接入 CDN 的站点还需要把访客到边缘、边缘到源站分开验证。把错误 AAAA、监听遗漏和 IPv6 防火墙规则补齐后，网站才不会只在部分网络中失效。

References

• RFC 3596: DNS Extensions to Support IP Version 6

• curl documentation: IPv4 and IPv6 address-family options

• NGINX documentation: listen directive