凌晨把站点迁到新 VPS，顺手在面板里打开「启用 IPv6」，又补了一条 AAAA 记录。半小时后客服炸了：办公室 Wi-Fi 打开秒开，家里移动网络一直转圈，部分安卓机直接提示「无法访问此网站」，最诡异的是客服自己电脑访问一切正常。多数人第一反应是「网站挂了」，去重启 Nginx、重启数据库，其实问题既不在应用层，也不在记录本身，而是卡在 地址分配、AAAA 解析、双栈回源 这三段链路中的某一段被人为切断了。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：vipserver（全球云服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
IPv6 异常的迷惑性在于它不是全有全无。有 IPv6 能力的客户端会按 RFC 6724 的策略优先尝试 IPv6，如果 IPv6 只是「半通」能建立 TCP 连接但握手后回源超时，或者路由不通直接丢包客户端可能等满一段回落超时才改用 IPv4，于是表现为「打开很慢」「偶发打不开」「刷新几次又好了」；而在只走 IPv4 的局域网、只解析 A 记录的老旧终端上，一切又完全正常。这种按网络环境分裂的现象，正是 IPv6 问题最典型的指纹。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：vipserver（全球云服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
第一段链路：IPv6 地址分配，网卡拿到地址不等于能出网
云主机控制台里分配一个 IPv6 地址，只是把一个前缀路由到了你这台机器，操作系统层面还需要三件事同时成立：网卡上配到地址、默认路由存在、出站防火墙允许。前两步最容易漏。
先看地址。登录服务器执行 ip -6 addr show，正常应当看到形如 2xxx:xxxx:xxxx:xxxx::10/64 的全局单播地址，以及 fe80:: 开头的链路本地地址。如果只看到 fe80::，说明云平台的 SLAAC 或 DHCPv6 前缀下发没有成功，或者系统侧的网卡配置文件没写进去。Debian/Ubuntu 上检查 /etc/network/interfaces 或 netplan 的 YAML，CentOS 系检查 /etc/sysconfig/network-scripts/，还要确认 systemd-networkd 与 NetworkManager 没有互相抢网卡。改完重启网络服务，重新核对 ip -6 addr 的输出。
再看路由。ip -6 route show 里必须有 default via fe80::xxxx dev eth0 proto ra 这样的默认路由，只有 ::/128 或者干脆没有 default 行，机器就出不了 IPv6。家用宽带和部分 VPS 网络环境下还需要 DNS64/NAT64（464XLAT）把 IPv6 客户端的访问转换回 IPv4，这时即使服务器没有公网 IPv6，客户端拿到的 AAAA 结果也可能是 64:ff9b::a.b.c.d 这类合成地址看到这种记录不要误判为「平台乱发地址」。
最后是防火墙，很多事故就卡在这里。ip6tables -L -n 或者 nft list ruleset 里，若 INPUT 的策略是 DROP，而规则集只写了 IPv4 段（0.0.0.0/0 或具体 IPv4 白名单），所有 IPv6 入站包都会被静默丢弃。UFW 用户尤其要留意 /etc/default/ufw 中的 IPV6=no，一旦设成 no，它只管理 IPv4 规则，IPv6 直接裸奔在默认策略之外。firewalld 则要确认所在 zone 同时启用了 ip6tables 后端。
连通性验证建议由近及远。先在本机 ping6 -c 4 2606:4700:4700::1111，确认默认路由和出口正常；再 ping6 你自己的公网 IPv6 地址；然后在外部机器上 ping6 该地址。中间任何一跳不通，DNS 层面就不用再查了。
第二段链路：AAAA 记录发布了，但递归缓存还在按老规矩回你
AAAA 记录的作用只有一个：告诉递归解析器「这个域名还有一个 IPv6 地址」。它本身不校验这个地址是否可用，所以在 IPv6 链路还差一口气时就发布 AAAA，等于把一部分用户推到了坏路上。
排查解析先看链路两端。本机 dig AAAA example.com，确认返回的地址与网卡上的地址一致；再分别 dig AAAA example.com @8.8.8.8 与 @223.5.5.5，对比不同递归节点的结果，如果某个节点返回空结果或 NXDOMAIN，说明该节点的 DNS 解析视图还没同步。dig +trace example.com 可以看清从根到权威服务器的完整路径。
缓存是第二个坑。递归节点对 AAAA 记录的 TTL 可能长达 300 到 3600 秒，客户端本地 DNS 也会缓存。你在面板上删掉 AAAA 后十分钟仍有用户报错，多半是缓存没过期。Windows 上执行 ipconfig /flushdns，macOS 上执行 sudo dscacheutil -flushcache，手机上切一次飞行模式，都能验证是不是缓存残留。
还有一个容易被忽略的点：反向解析。不少 CDN、WAF 和邮件网关会做 IPv6 的 PTR 检查，没有 PTR 记录、或者 PTR 与正向域名不匹配的地址，会被判为可疑来源，轻则降级拦截，重则整条请求被拒。用 dig -x 你的IPv6地址 反查，若返回的是云厂商默认的 generic host 一类字样，需要向服务商申请把 PTR 改成自己的域名。反过来，如果你已经切到 CDN，而 CDN 回源仍带着旧的源站 IPv6 地址，旧 IP 段的 PTR 未同步同样可能触发风控。
第三段链路：双栈回源，CDN 到源站的最后一公里
当 AAAA 记录指向的是 CDN 节点时，真正的判定发生在 CDN 到源站这一跳，这里有三个高频断点。
其一，源站监听配置。Nginx 的 listen 指令要同时写 listen 80 和 listen [::]:80 ssl 这类 双栈监听，并检查 net.ipv6.bindv6only 的取值：该值为 1 时，即使写了 [::] 也只接受 IPv6 连接，会把 IPv4 回源全部拒绝；为 0 才是 v4/v6 通吃。改完先执行 nginx -t 确认语法与路径无误，再 reload，避免 include 文件路径写错导致新配置根本没被加载。
其二，IPv6 连通性与白名单。CDN 节点的 IPv6 回源 IP 段与你原有的 IPv4 白名单往往不是同一批，安全组和 iptables 需要单独放行新增的 IPv6 段；同时确认 CDN 控制台里的「回源协议 / 回源地址族」是否真的允许 IPv6，有些面板只填了 IPv4 源站地址，IPv6 节点回源时找不到对应源站，直接返回 502 或超时。
其三，源站侧的 Host 匹配与 SNI。用 curl 在源站本机直接指定 IPv6 地址回源：curl -6 -I --resolve example.com:443:[你的IPv6] https://example.com/，返回 200 说明监听、TLS 证书、路由都通；再从外部机器执行同一条命令，仍返回 200，说明外部到源站的 IPv6 通路也通。这一步能把「CDN 的问题」和「源站的问题」干净地切开。
顺带提醒，本机 curl 通不代表对外通，因为流量根本没走公网；同样，浏览器访问慢也不一定是缓存问题，要分别看首字节时间和完整回源耗时。curl -6 -o /dev/null -s -w '%{time_connect} %{time_starttransfer}\n' 能给出精确数字：connect 就慢，断点在网络路由；connect 很快而 starttransfer 很慢，断点在 TLS 握手或后端处理。
收尾：一份可以照着敲的检查清单
按下面顺序走一遍，通常三分钟内就能定位断点：
- ip -6 addr show 是否存在 IPv6 地址配置的全局地址，而不是只有 fe80::；
- ip -6 route show 里有没有 default 路由；
- ping6 公网 IPv6、ping6 自己的地址，是否都有回应；
- ip6tables -L -n 或 nft list ruleset 中，IPv6 的入站策略与放行规则是否齐全；
- dig AAAA 域名 与 dig -x IPv6，确认 AAAA 记录与 反向解析都正确；
- 本机执行 curl -6 -I --resolve 域名:443:[IPv6] https://域名/ 是否返回 200；
- 外部机器重复同一条命令，判断是否属于 CDN 侧的 双栈回源能力或白名单问题；
- 清理本地与递归缓存后再复测，避免拿旧解析结果下结论。
用 ServLlama 这类服务器管理面板把网卡地址、默认路由、监听端口和防火墙规则摊在一屏里对照，比逐条敲命令省事得多。最后提醒一句：IPv6 出问题最稳的止血动作，是先把 AAAA 记录撤下来、或把 CDN 回源强制切回 IPv4，再按上面的清单逐层恢复。在链路完全打通之前，宁可让用户走 IPv4 慢一点，也不要让他们卡在「转圈十秒再回落」上。
喜欢 
顶
难过
囧
围观
无聊
