在阿里云上做 ipv6 改造，很多团队的起点都一样：公网 IPv4 地址越来越紧，买一个要花不少钱，NAT 网关后面的链路也越来越绕。业务一扩，这些问题会一起冒出来。下面结合阿里云现有的网络产品，讲讲开启 IPv6 时要过的几道关。
为什么现在值得动手
IPv6 地址是 128 位，IPv4 是 32 位，地址总量差得很远。放到云上，直接感受到的变化主要有三个。
- 公网地址数量不再卡着实例规模走，扩容时不用先去抢 IPv4。
- 端到端直连少了一层 NAT 转换，部分场景下时延会更稳定。
- 国内主流移动网络和家庭宽带已经大范围支持 IPv6，面向终端用户的服务会直接受益。
IPv6 一般不会让你立刻拆掉 IPv4。更常见的做法是双栈：同一套服务同时监听 IPv4 和 IPv6，客户端根据自己的网络环境选择。改动范围可控，出了问题也能较快退回去，适合边跑边验证。
阿里云上的 IPv6 基础配置
专有网络 VPC 可以分配 IPv6 网段。ECS 实例拿到 IPv6 地址后，如果要访问公网或被公网访问，还得配置 IPv6 网关，并在安全组里放行对应的 IPv6 规则。SLB 支持 IPv6 监听，可以把 IPv6 流量转发到后端的 IPv4 或双栈服务器上，这意味着后端不必全部先改。
地域支持范围、产品规格和计费方式会随版本调整。动手前去阿里云官网看最新文档，重点确认目标地域是否已经开放对应能力，别等配置做到一半才发现某个地域不支持。
一个在线教育团队的双栈改造过程
某在线直播课公司的业务部署在阿里云华东地域。学员增多后，他们碰到两个问题。
一是直播推流和播放接口都依赖 IPv4 公网地址，流量全部走 NAT 网关出口。高峰期 NAT 带宽经常打满，运维只能反复扩容。二是部分学员用的移动网络在 IPv4 出口上叠了运营商 NAT，偶发超时很难定位，客服投诉也多。
团队的做法分三步：
- 先梳理服务清单。无状态的 API 网关和静态资源服务优先改，有状态的数据库和内部服务暂时不动，免得一次改太多。
- 在 VPC 里开通 IPv6 网段，给应用服务器分配 IPv6 地址，配好 IPv6 网关和安全组，在测试环境把连通性验完。
- 把 SLB 监听器升级为双栈，对外同时提供 IPv4 和 IPv6 入口。先用灰度比例切一小部分流量到 IPv6，观察两周，再逐步放量。
上线一个月后，团队的反馈比较直接。支持 IPv6 的移动网络用户连接成功率明显提升，原有 NAT 网关的带宽压力也缓解了，部分出口流量分流到了 IPv6 路径上。在现有架构上做双栈，过程是可以平稳走完的。
上线前后容易漏掉的几处
安全组和防火墙要同步
很多团队迁移时只盯着连通性，安全组和防火墙规则还是按 IPv4 写的。IPv6 流量没有被显式放行，结果就是服务能访问，但行为不对。建议把 IPv6 和 IPv4 的规则放进同一份清单里逐条过一遍，别出现只开了一半的情况。
应用里的地址处理
代码里如果写死了 IPv4 格式的正则校验，或者日志、限流只按 IPv4 地址做索引，就可能出问题。IPv6 地址最长有 39 个字符，字段长度不够会被截断，校验也会误判。这类问题在测试里不一定暴露，需要专门检查相关字段和校验逻辑。
监控和回滚
双栈上线后，监控要把 IPv4 和 IPv6 的请求量、错误率、时延分开统计。某个协议栈一旦异常，要能快速把流量切回另一侧。能切回去，灰度才算有底。
双栈的节奏可以放慢一点。先从无状态服务和面向终端用户的入口开始，用小比例流量验证，确认没问题再扩大范围。
