当你的 IPv4（互联网协议第四版）地址访问一切正常，却接到部分移动端用户”打不开站点”的反馈时，问题很可能出在 IPv6（互联网协议第六版）链路上。在国内，移动网络的相当一部分流量已经走 IPv6 出口；如果你的服务器只监听 IPv4，这批访客就要靠运营商网关做协议转换，速度和稳定性都会打折。本文以一次真实的双栈站点接入为例，讲清楚如何帮助一台云服务器从零完成 IPv6 开通与配置：地址从哪里来、系统层怎么配、DNS（域名解析系统）怎么写、Web 服务怎么监听、最后如何验证。整个过程不涉及重构业务，只需要按顺序处理五个环节，读完即可对照自己的服务器上手操作。
IPv6 地址从哪里来：先确认分配方式
动手改配置之前，第一步是搞清楚你的云服务器到底有没有 IPv6 地址、以什么方式分配。目前主流的分配方式有两种：SLAAC（无状态地址自动配置）和 DHCPv6（有状态地址分配）。前者由路由通告自动生成地址，常见于原生支持 IPv6 的网络环境；后者由 DHCP（动态主机配置协议）服务器统一下发地址和 DNS，便于管理固定地址。用下面这条命令可以快速判断当前状态：
ip -6 addr show scope global
如果输出为空，说明系统层还没有拿到全局 IPv6 地址，需要先在云控制台为实例申请或绑定 IPv6 地址。以我们这次接入的实例为例，控制台分配的是一个 /64 前缀的地址，形如 2408:xxxx:xxxx:xxxx::1——IPv6 不再是 IPv4 那种单个地址的概念，而是一次给你一整段前缀，具体用哪个主机位可以自己规划。地址绑定到网卡后，云平台通常还会提供一个 IPv6 网关地址，它负责本网段的路由，后续配置默认路由时会用到。
这里有一个实践中最容易踩的坑：控制台显示”已分配”不等于系统已生效。部分镜像默认没有开启 IPv6，需要检查 /etc/sysctl.conf 中 disable_ipv6 相关项是否为 0，并确认网卡配置文件里包含 IPV6INIT=yes。改完执行 sysctl -p 并重启网络服务，再跑一次 ip -6 addr，看到 scope global 的地址才算真的到位。如果你还不确定自己的服务器方案是否原生支持 IPv6，可以先对照独立服务器与云主机的网络能力差异做一次评估，再决定是在现有实例上加开，还是迁移到支持双栈的方案。
系统层配置：地址、路由与 DNS 三件事
系统层要处理的核心是三样东西：地址、默认路由和 DNS 解析。对照下面的清单逐项处理，可以避免来回排查：
- 地址生效：
ip -6 addr show scope global输出包含云控制台分配的地址，且网卡配置中IPV6INIT=yes - 默认路由：
ip -6 route show default能看到指向网关的默认路由，没有就用ip -6 route add default via <网关地址> dev eth0补上 - DNS 解析：
/etc/resolv.conf中至少有一个支持 IPv6 递归查询的 nameserver，例如240c::6666或2001:4860:4860::8888 - 出口连通：
ping6 -c 3 240c::6666有回包，说明本机 IPv6 链路已经通了
这四项全部通过后，你的服务器已经具备 IPv6 出站能力。也可以再找一个支持 IPv6 的站外探测服务做一次出站确认——注意这类第三方探测地址会随时间变动，执行前先用 ping6 确认可达，不要把具体地址写死在自动化脚本里。
配置过程中还要留意防火墙。许多云镜像默认携带 firewalld 或 ufw，它们的老版本规则集只针对 IPv4 编写，IPv6 流量可能被默认策略静默丢弃。用 ip6tables -L -n 或 firewall-cmd --list-all 检查规则，至少放行 80 和 443 端口的 IPv6 入站，否则后面的 Web 验证会一直超时，让人误以为是地址没配好。
DNS 双栈解析：A 与 AAAA 的分工
服务器侧就绪后，轮到 DNS（域名解析系统）。双栈站点的核心是在同一个域名下同时提供两类记录：A 记录指向 IPv4 地址，AAAA 记录指向 IPv6 地址。终端设备访问时会按自身网络能力选择：IPv6 优先的网络先取 AAAA，拿不到再回退 A。这次接入我们给主域添加的记录很简单：
example.com. IN A 203.0.113.10
example.com. IN AAAA 2408:xxxx:xxxx:xxxx::10
添加 AAAA 前有一个必须核对的细节：证书。如果你的 HTTPS（加密传输协议）证书是通过 HTTP-01 验证签发的，签发程序当时可能只走了 IPv4 链路；AAAA 生效后，验证流量会转而走 IPv6，一旦 80 端口的 IPv6 入站没放行，下次续期就会失败。建议 AAAA 记录生效当天就手动执行一次 certbot renew --dry-run，提前暴露这类问题，而不是等到证书到期前夜才发现。
关于解析策略，如果你担心 IPv6 链路质量不稳而不敢全量切换，可以先只给子域（例如 v6.example.com）添加 AAAA 记录做灰度观察，用真实流量确认服务稳定后再把主域补上。灰度期间通过分析访问日志里 IPv6 请求的占比和错误率，就能拿到是否全量开启的依据，这比拍脑袋决定可靠得多。如果你的站点跑的是 WordPress（全球使用最广的开源建站系统），还可以顺带参考 WordPress 站点的服务器优化思路，把双栈接入和应用层优化放在同一个窗口期完成。
Nginx 双栈监听：一行配置的差别
Web 服务层以 Nginx 为例。默认配置只监听 IPv4 的 listen 80;，要让 Nginx 同时接受 IPv6 请求，需要在 server 块中显式加入 IPv6 监听：
server {
listen 80;
listen [::]:80;
server_name example.com;
}
这一行配置表示监听所有 IPv6 地址的 80 端口。改成双栈后用 nginx -t 验证配置语法，再 systemctl reload nginx 平滑重载。验证 Nginx 是否真的在 IPv6 上服务，可以用：
curl -6 -I http://example.com/
返回 HTTP 头且状态码为 200，说明从 DNS 到 Nginx 的整条 IPv6 链路已经打通。若这一步卡住，建议按”本机直连 IPv6 地址 curl -6 → 带域名 curl -6 → 外部设备访问”的顺序缩小范围：本机直连地址通而域名不通，问题在 DNS；本机都不通，问题在 Nginx 监听或防火墙。
除了 Nginx 本身，也别忘了检查应用的真实 IP 获取。IPv6 访客经过 Nginx 反代后，日志里记录的来源地址会变成 ::1 或内网地址；如果你的应用有基于 IP 的风控、限流逻辑，需要把 real_ip_header 和 set_real_ip_from 的网段配置扩展到 IPv6 范围，否则所有 IPv6 用户会被识别成同一个来源，风控直接误伤。
上线后验证与常见问题排查
双栈全部配置完成后，上线验证建议固定一套动作，形成自己的检查习惯：
- 站外拨测：用支持 IPv6 的在线探测工具分别测 IPv4 与 IPv6 两条链路的可用性，两条都应返回 200
- 日志抽样：
grep -c 'IPv6地址前缀' /var/log/nginx/access.log统计 IPv6 流量占比，确认真实流量在走新链路 - 证书演练：
certbot renew --dry-run在双栈环境下通过，排除续期路径故障 - 回退预案：保留 DNS 控制台入口，出现异常时可临时删除 AAAA 记录，TTL（解析生效时间）建议先设 300 秒，方便快速回退
实际排查中，最常见的三类问题都有明确特征。第一类是”IPv4 通、IPv6 不通”，八成出在防火墙没放行 IPv6 的 80/443，或者云平台安全组只配了 IPv4 规则。第二类是”本机 curl 通、外部不通”，通常是安全组或运营商侧对 ICMPv6 做了限制，先检查云控制台的 IPv6 安全组条目。第三类是”时通时不通”，多见于 DNS 双栈策略下 AAAA 记录指向的地址与实际监听不一致，用 dig AAAA example.com +short 核对解析值是否与 ip -6 addr 的输出一致即可定位。更多服务器侧的网络与性能排查思路，可以延伸阅读我们整理的服务器运维栏目。
总结
这次双栈接入从申请地址到全链路验证，实际耗时不超过一个工作日，关键就在于按”地址 → 路由 → DNS → 监听 → 验证”的顺序推进，每个环节都有可执行的验证命令兜底。回到开篇的问题：部分移动端用户打不开站点，本质是站点缺了一条 IPv6 通路，补齐后这批访客的访问质量和 SEO（搜索引擎优化）抓取覆盖都会受益。如果你正在选型支持 IPv6 的云服务器（弹性可扩展的远程计算服务），Hostease 的 VPS（虚拟专用服务器）方案提供双栈网络支持，配合本文的配置步骤可以快速完成接入。建议先用子域灰度验证，再全量开启 AAAA 记录，平稳把站点带进双栈时代。