别再说 IPv6 只是“未来”了：我在生产环境踩过的那些坑

大家好，我是 Echo_Wish。

这几年，IPv6 从“政策推动”变成了“现实压力”。云厂商默认给 IPv6，运营商天然支持 IPv6，手机网络优先走 IPv6，甚至有些新业务直接要求“必须支持 IPv6”。

但说句实话——

IPv6 真正在生产环境跑起来，绝对不是把 AAAA 记录加上那么简单。

今天我就结合实战，聊聊 IPv6 在生产环境部署的经验和那些坑，尤其是 dual-stack（双栈）和迁移策略这两个核心问题。

一、先说一个扎心的事实：不要幻想“一步到位纯 IPv6”

很多团队一开始就想：

既然 IPv6 是未来，那我们直接 All in IPv6。

别冲动。

现实情况是：

• 你的上游依赖可能不支持 IPv6
• 第三方 API 可能只有 IPv4
• 内网某些老设备不支持 IPv6
• 防火墙策略没跟上
• 监控系统只认 IPv4

所以在生产环境，最稳的方式一定是 Dual-Stack（IPv4 + IPv6 共存）。

二、Dual-Stack 不是“开关一按”这么简单

我们来看一个最基础的服务器配置。

1️⃣ Linux 开启 IPv6

先确认内核支持：

sysctl net.ipv6.conf.all.disable_ipv6

如果返回 1，说明被禁用了：

sysctl -w net.ipv6.conf.all.disable_ipv6=0

配置网卡 IPv6 地址（示例）：

ip -6 addr add 2001:db8::10/64 dev eth0
ip -6 route add default via 2001:db8::1

你以为这就完了？

不。

三、第一个大坑：监听地址没改

很多服务默认只监听 IPv4。

比如 Nginx：

错误写法（只监听 IPv4）

server {
    listen 80;
    server_name example.com;
}

这在 IPv6 下是不够的。

正确写法（双栈）

server {
    listen 80;
    listen [::]:80;
    server_name example.com;
}

如果你漏了 [::]:80，那么：

• AAAA 记录解析正常
• 客户端能连上服务器
• 但端口没监听
• 结果就是超时

线上排查的时候你会怀疑人生。

四、DNS 层的坑：AAAA 加了不等于万事大吉

添加 AAAA 记录：

example.com.    IN  AAAA  2001:db8::10

很多人做完这一步就直接上线。

但你要考虑：

• 负载均衡是否支持 IPv6？
• CDN 是否支持 IPv6 回源？
• WAF 是否支持 IPv6？
• 健康检查是否支持 IPv6？

我见过一个真实事故：

AAAA 记录加了，但后端服务只监听 IPv4，导致移动端 IPv6 网络全部访问失败。

IPv6 优先级在很多移动网络里是更高的。

你不支持，就等于你主动把用户拒之门外。

五、第二个大坑：防火墙规则没同步

IPv4 和 IPv6 的防火墙是两套规则。

很多人只写了：

iptables -A INPUT -p tcp --dport 80 -j ACCEPT

但 IPv6 走的是：

ip6tables

你如果没放行：

ip6tables -A INPUT -p tcp --dport 80 -j ACCEPT

那 IPv6 访问直接被丢弃。

更现代的系统用 nftables：

nft add rule ip6 filter input tcp dport 80 accept

记住一句话：

IPv6 是平行宇宙，不是 IPv4 的附属品。

六、数据库与中间件支持情况要提前摸清

比如 MySQL：

默认是支持 IPv6 的，但你要确认 bind-address：

bind-address = ::

如果你写成：

bind-address = 0.0.0.0

那只会监听 IPv4。

再比如 Redis：

redis-server --bind :: 0.0.0.0

否则某些客户端可能解析到 IPv6 地址却连不上。

七、迁移策略：从“边缘”往“核心”推

我个人推荐的迁移顺序是：

1. CDN / LB 支持 IPv6
2. 外网入口支持 Dual-Stack
3. 内部服务逐步支持 IPv6
4. 监控与日志系统升级
5. 最后才考虑 IPv6-only

不要反着来。

否则你会发现：

外部是 IPv6，内部全是 IPv4 NAT，链路复杂度直接翻倍。

八、一个真实的迁移架构示意

典型架构：

用户（IPv6优先）
        ↓
CDN（Dual-Stack）
        ↓
负载均衡（Dual-Stack）
        ↓
应用服务器（Dual-Stack）
        ↓
数据库（IPv4 或 Dual）

逐层推进。

不要一口气全改。

九、运维视角最容易忽略的两个点

1️⃣ 监控系统是否支持 IPv6

比如 Prometheus 抓取：

- targets:
  - '[2001:db8::10]:9100'

如果你忘了加方括号，解析会出错。

2️⃣ 日志分析是否支持 IPv6 格式

IPv6 日志比 IPv4 长很多。

有些正则写死了：

\d+\.\d+\.\d+\.\d+

那 IPv6 直接匹配不到。

十、我的观点：IPv6 部署是“体系能力”的体现

说点真心话。

IPv6 本质不是技术问题。

是体系成熟度问题。

你要具备：

• 网络理解能力
• 服务监听意识
• 安全策略同步能力
• 依赖管理能力
• 监控可观测能力

很多团队 IPv6 推不动，不是因为难。

是因为：

架构本来就不清晰。

IPv6 只是把问题暴露得更彻底。

十一、什么时候可以考虑 IPv6-Only？

只有在这些条件满足时：

• 所有上游依赖支持 IPv6
• 所有监控系统支持 IPv6
• 安全设备支持 IPv6
• 已验证移动端全部可达

否则，别轻易上 IPv6-only。

Dual-Stack 是一个长期状态，不是过渡。

十二、总结一句话

IPv6 部署的核心不是“地址升级”。

而是：

让整个生产体系真正具备双协议运行能力。

别把它当任务。

把它当一次架构体检。

你会发现很多隐患。

我是 Echo_Wish。

写运维这么多年，我最大的感受是：

技术升级不可怕，
可怕的是体系没有准备好。