云服务器 IPv6 配置与双栈接入指南：实测讨论需要验证哪些指标

上个月帮两个站长朋友排查同一个怪现象：IPv4 访问一切正常，移动端用户却间歇性打不开站点。定位下来都是同一个原因——服务器只跑了 IPv4，而国内移动网络相当一部分流量已经从 IPv6（互联网协议第六版）出口走。很多人以为在云控制台点了”开通 IPv6″就算完事，其实从地址分配到流量真正走通，中间至少有 6 类指标需要逐项验证。这篇文章以一次真实的双栈站点接入为例，教你按顺序验证每一项，帮助你在自己的云服务器（弹性可扩展的远程计算服务）上把问题在上线前拦住，而不是等用户投诉。

先搞清楚地址是怎么分配的

验证的第一项是地址本身。主流分配方式有两种：SLAAC（无状态地址自动配置）由路由通告自动生成地址，DHCPv6（有状态地址分配）则由服务器统一下发地址和 DNS（域名解析系统）。动手配置前，先跑这条命令确认当前状态：

ip -6 addr show scope global

输出为空说明系统层还没拿到全局地址，需要先在云控制台申请或绑定。在我的测试环境中，实例拿到的是一个 /64 前缀，形如 2408:xxxx:xxxx:xxxx::1——IPv6 一次给一整段前缀，主机位可以自己规划，这和 IPv4 单地址的思路完全不同。

这里有一个实测中最容易踩的坑：控制台显示”已分配”不等于系统已生效。部分镜像默认关闭了 IPv6，需要确认 /etc/sysctl.conf 里 disable_ipv6 相关项为 0，网卡配置包含 IPV6INIT=yes，改完执行 sysctl -p 并重启网络服务，重新看到 scope global 的地址才算数。

系统层四项连通指标

地址到位后，系统层要验证的是四项连通指标，任何一项不过关，后面的 Web 验证都会白做。第一项是默认路由：ip -6 route show default 必须能看到指向网关的默认路由，缺失时用 ip -6 route add default via <网关地址> dev eth0 补上。第二项是 DNS 解析：/etc/resolv.conf 中至少要有一个支持 IPv6 递归查询的 nameserver，例如 240c::6666。第三项是出口连通：ping6 -c 3 240c::6666 有回包，说明本机 IPv6 链路已通。第四项经常被忽略——防火墙。不少云镜像自带 firewalld 或 ufw，老规则集只针对 IPv4 编写，IPv6 流量会被默认策略静默丢弃，用 ip6tables -L -n 检查并放行 80/443 的 IPv6 入站，否则后面所有验证都会超时。

为什么要把防火墙单独列为一项指标？因为实测里”IPv4 通、IPv6 不通”的案例，八成出在这里，而不是地址配置本身。云平台的安全组同样只配了 IPv4 规则也会造成同样的假象，排查时要两层一起看。

DNS 双栈：AAAA 记录的三项核对

服务器侧就绪后，轮到 DNS。双栈站点的核心是在同一域名下同时提供 A 记录（指向 IPv4）和 AAAA 记录（指向 IPv6），终端设备按自身能力选择链路。添加 AAAA 前有三项必须核对：

• 证书链路：HTTPS（加密传输协议）证书若通过 HTTP-01 验证签发，AAAA 生效后验证流量会转走 IPv6，80 端口未放行会导致下次续期失败，建议生效当天跑一次 certbot renew –dry-run
• 解析一致性：dig AAAA example.com +short 的输出必须与 ip -6 addr 的实际地址一致，两者不一致是”时通时不通”的典型根因
• 灰度策略：担心链路不稳时，先只给 v6.example.com 这类子域加 AAAA，观察日志中 IPv6 请求占比和错误率，再决定是否全量切换

为什么建议灰度而不是一步到位？因为 AAAA 记录一旦生效，全网 IPv6 优先的客户端都会涌向新链路，回退成本高；子域灰度阶段出现问题，删一条记录就能恢复，TTL（解析生效时间）设 300 秒足以支撑快速回退。如果你想了解香港云服务器相比传统主机的网络优势，可以参考这篇分析：香港云服务器有哪些优势。

Nginx 双栈监听与真实 IP 指标

Web 服务层以 Nginx 为例，默认的 listen 80; 只监听 IPv4，要让 Nginx 接受 IPv6 请求，需在 server 块显式加入一行：

listen [::]:80;

改完用 nginx -t 验证语法，systemctl reload nginx 平滑重载，然后用 curl -6 -I http://example.com/ 验证。返回 200 说明从 DNS 到 Nginx 的整条 IPv6 链路已通。若卡住，按”本机直连 IPv6 地址 → 带域名 → 外部设备”的顺序缩小范围：本机直连通而域名不通是 DNS 问题，本机都不通是监听或防火墙问题。

还有一个容易被漏掉的指标是真实 IP 获取。IPv6 访客经 Nginx 反代后，日志来源会变成 ::1 或内网地址，应用若有基于 IP 的风控或限流，必须把 real_ip_header 和 set_real_ip_from 的网段扩展到 IPv6 范围，否则所有 IPv6 用户会被识别成同一来源，风控直接误伤。带宽层面也要留意：双栈意味着两条链路都可能承载流量，晚高峰时 IPv6 链路的带宽（单位时间内传输的数据量）表现要单独压测，不能默认与 IPv4 一致。

上线后的固定验证动作

双栈配置完成后，上线验证建议固定成一套动作，我自己的习惯是四步：先用支持 IPv6 的站外拨测工具分别测两条链路，都应返回 200；再从 Nginx 访问日志抽样统计 IPv6 流量占比，确认真实流量在走新链路；然后跑一次证书续期演练；最后确认回退预案——保留 DNS 控制台入口，异常时临时删除 AAAA 记录。四步都绿了，才敢说这次接入真正完成。

排查阶段最常见的三类故障各有明确特征：IPv4 通而 IPv6 不通，先查防火墙与安全组的 IPv6 条目；本机通而外部不通，多半是运营商侧对 ICMPv6 有限制；时通时不通，用 dig 核对 AAAA 解析值与实际地址是否一致。把这三类特征记熟，大部分双栈故障能在十分钟内定位。关于云服务器选型本身，如果还在犹豫什么配置适合双栈业务，可以看看这篇选型指南：中小企业如何选择合适的云服务器；部署前也可以先逛逛 Hostease 专区看看其他站长对双栈网络的实测反馈。

总结与行动建议

回到开篇的问题：移动端用户打不开站点，本质是站点缺了一条 IPv6 通路。整次双栈接入实际耗时不超过一个工作日，关键是按”地址 → 路由 → DNS → 监听 → 验证”的顺序推进，每个环节都有可执行的验证命令兜底。总结一下核心指标：地址 scope global 生效、默认路由存在、IPv6 DNS 可递归、防火墙放行 80/443、AAAA 与实际地址一致、curl -6 返回 200，这六项全部通过，双栈才算真正落地。

如果你需要一台原生支持双栈的服务器来做验证，Hostease 的 VPS（虚拟专用服务器）方案提供 IPv6 支持，配合本文步骤可以快速接入；建议先用子域灰度，确认日志指标平稳后再全量开启 AAAA 记录，也可以对照 VPS 主机栏目里的其他方案做横向比较：VPS主机。