IPv4 地址已经很紧张，不少家庭宽带和移动网络都在大规模部署 IPv6，有些终端甚至会优先走 IPv6 链路。如果业务入口只有 IPv4，访问路径可能要多过一层 NAT，延迟和稳定性都会受点影响。所以在云上提前开通阿里云 IPv6，既是为了接住用户侧的变化，也是给后面的地址规划留个余地。
下面不谈概念，直接用一个场景讲在阿里云 VPC 里怎么规划、配置和验证 IPv6。
先搞清楚三个词
动手前，有三个概念最好先分清。
- 双栈（Dual Stack）：实例同时拥有 IPv4 和 IPv6 地址，两套协议并行，客户端按自己的网络条件选择。存量业务迁移基本都从这里开始。
- IPv6 网关：负责 VPC 内实例的 IPv6 公网出入口。它决定了外部 IPv6 用户能不能直接访问到实例。
- 安全组：IPv6 流量同样受安全组约束。很多人只放行了 IPv4 端口，结果 IPv6 访问看着通，实际已经被拦住了。
案例：一家在线教育公司的改造过程
某在线教育公司的课程播放服务部署在华东地域的 VPC 里，前端走 CDN，后端是几台 ECS 加一个负载均衡实例。移动端用户里有相当一部分来自已开通 IPv6 的家庭宽带。运营同学发现，这部分用户首屏偶尔偏慢，部分网络下视频起播失败率也更高。
技术团队的做法大致如下。
- 先给 VPC 加上 IPv6 CIDR，再给交换机分配 IPv6 网段。这一步不影响已有 IPv4 业务，可以放心先做。
- 对外提供服务的 ECS 开通 IPv6 公网能力，安全组里补上 IPv6 入方向规则。端口只放行业务必需的那几个，别图省事全开。
- 负载均衡开启 IPv6 监听，前端流量可以直接以 IPv6 接入，再转发到后端实例的 IPv4 或 IPv6 地址。
- CDN 域名开启 IPv6 加速，添加 AAAA 记录。支持 IPv6 的客户端会自动优先走这条路。
- 先灰度 10% 的流量，对比两组用户的首屏耗时、起播成功率和错误日志。没问题再逐步放量。
上线后，支持 IPv6 的用户首屏耗时有了明显可感的下降，起播失败率也跟着回落。更让团队放心的是，IPv4 服务始终没有中断，出问题时随时能切回去。
最容易踩的几个坑
这个案例里暴露出的问题，基本是大多数团队都会遇到的，动手前最好逐条过一遍。
- 只改了 DNS，没改安全组：AAAA 记录一生效，用户就能解析到地址，但连接会被直接拒绝。这类问题看起来像服务挂了，排查很容易绕远路。
- 监听地址写死成 IPv4：服务绑定了 0.0.0.0，却没绑定 IPv6 的 ::。双栈环境下，它只会接收 IPv4 连接，IPv6 用户进来就是超时。
- 日志和风控只认 IPv4：访问日志、限流规则、白名单如果只按 IPv4 做，统计会漏掉一部分流量，严重时还会把正常用户当成异常请求拦下来。
- 计费和带宽没提前算：IPv6 公网流量的计费方式和带宽配置，以控制台和官方定价说明为准。上线前先估一下成本，别等账单出来才发现。
怎么验证改造结果
改造完成后，建议从三个层面各查一遍。先登录实例，用 ip addr 或 ifconfig 确认 IPv6 地址已经正确绑定到网卡上。接着从外部用支持 IPv6 的客户端或在线工具，分别测试 http 和 https 访问。还要检查 DNS 解析结果，确认 AAAA 记录指向的是预期地址。测试最好同时覆盖移动网络和家庭宽带，两者的 IPv6 支持情况并不完全一样，只测一种很容易漏问题。
小结
阿里云 IPv6 的开通步骤本身不算复杂，效果好不好主要取决于规划是否完整。建议先走双栈，保留 IPv4 作为兜底，再用灰度逐步放量，同时把安全组、监听、日志和监控一起纳入改造范围。这样 IPv6 用户能获得更好的访问体验，业务风险也能控制在可接受的范围内。
