IPv6在国内的落地现状：你以为没用，其实已经悄悄来了

IPv6在国内的落地现状：你以为没用，其实已经悄悄来了

摘要：很多人觉得IPv6离自己很远。但从运营商到云厂商到主流APP，IPv6的推进速度比想象中快。本文从IDC从业者的体感出发，聊聊IPv6在国内的真实现状，以及开发者现在该做什么准备。

关键词：IPv6、双栈、互联网协议、IDC、网络架构

分类：网络 / 运维

你可能已经在用IPv6了

大部分人对IPv6的印象是"听说过，跟我没关系"。

你可以现在就检查一下。

手机连WiFi，打开设置看网络详情。如果你看到一个2400开头的地址，比如2400:3a1c:xxxx::1这种格式，那你已经在用IPv6了。

电脑上也行：

# Linux/Macip-6addr show|grep"inet6"|grep-v"fe80"# Windowsipconfig|findstr"IPv6"

2400开头的是公网IPv6地址。fe80开头的是链路本地地址，不算真正接入IPv6。::1是回环地址，也不算。

# 更直接的方法：看看能不能用IPv6访问外网curl-6https://ipv6.icanhazip.com

如果返回一个IPv6地址，说明你的网络有IPv6公网接入。如果报错或者超时，说明还没通。

运营商这边推得比你想的快

做IDC之后才对这个事情有了直接体感。

移动网络：三大运营商的4G/5G基本都默认开了IPv6。你用流量上网的时候，手机同时有IPv4和IPv6两个地址，双栈并行。用起来跟以前一模一样，完全无感知。

家庭宽带：新装的光猫基本都支持IPv6了。但有个坑——很多光猫虽然硬件支持，出厂默认没开。你得进光猫管理页面手动打开，或者打电话让运营商远程开。

# 家里电脑跑一下curl-6https://ipv6.icanhazip.com# 能返回地址 → 你家宽带已经支持IPv6# 超时报错 → 可能光猫没开IPv6，联系运营商

我去年帮几个朋友检查过家里的网络，5家里有3家的光猫支持IPv6但默认关闭。打电话给运营商说"帮我开一下IPv6"，5分钟就搞定了。

骨干网：三大运营商的骨干网和城域网全部完成了IPv6改造。不管你用哪家运营商，网络层面IPv6已经通了。问题往往出在最后一公里——光猫、路由器、或者企业网络设备。

大型APP和网站已经在跑了

很多主流APP的后端已经在走IPv6了，只是你感觉不到。

# 验证一个网站是否支持IPv6digAAAA www.baidu.com +shortdigAAAA www.taobao.com +shortdigAAAA www.bilibili.com +short

如果返回了IPv6地址（2400开头），说明这个域名支持IPv6。

在移动网络下，如果你的手机有IPv6地址、目标网站也支持IPv6，流量默认走IPv6。你打开APP用起来跟以前没区别，但底层已经在用新协议了。

我实际测了一下：

digAAAA www.baidu.com +short# 2400:da00:2::29digAAAA www.taobao.com +short# 返回IPv6地址digAAAA www.bilibili.com +short# 返回IPv6地址

大型互联网公司的网站基本都支持了。但中小企业的网站大部分还是纯IPv4。

IDC行业这边的情况

从卖服务器的角度看IPv6的落地，情况差异挺大的。

云服务器：主流云厂商都支持给实例分配IPv6地址。创建的时候勾选一下就行。

但有个坑我踩过：很多云服务器分配了IPv6地址，但安全组默认不放行IPv6流量。你拿到了地址，ping6能通（ICMP可能默认放了），但TCP端口访问不了。

# 测试IPv6端口是否可达nc-zv-62400:xxxx::180-w3# 如果超时，检查两个地方：# 1. 云平台安全组的IPv6规则# 2. 服务器的ip6tablesip6tables-L-n

物理服务器和托管：这块进度比云服务器慢不少。

一线城市主流机房基本都支持IPv6，可以单独申请IPv6地址段。但二三线城市的老机房，有些核心路由器还不支持IPv6，整个机房出口就没有IPv6路由。

我遇到过一个真实情况：客户的服务器在某三线城市机房，想加IPv6地址。跟机房沟通了一周，最后发现他们的核心交换机是十几年前的型号，固件不支持IPv6。要升级设备得整个机房的网络割接，机房不愿意动。

所以物理服务器要不要IPv6，很大程度取决于你的机房。

IPv4地址越来越贵

这是IPv6推进的一个现实驱动力。

IPv4地址全球已经分配完了。现在获取IPv4地址只能从存量市场购买，价格一直在涨。一个/24段（254个可用IP）的购买成本从几年前的几万涨到了十几万甚至更高，而且还在涨。

IPv6地址呢？申请一个/48段（包含2^{80个地址，约1.2×10}24个），基本免费或者成本极低。

2^80是什么概念？给地球上每粒沙子分一个地址都绰绰有余。

从成本角度来说，新业务用IPv6能省掉IPv4地址的采购成本。这个经济因素会持续推动IPv6的采用。

开发者现在该做什么

不用恐慌式地全面改造，但有些事情现在就该做。

新项目直接支持双栈

从开发阶段就考虑IPv6兼容，成本最低。等业务跑起来再改，各种历史代码和配置改起来很痛苦。

# Nginx同时监听IPv4和IPv6 server { listen 80; listen [::]:80; server_name api.example.com; } server { listen 443 ssl; listen [::]:443 ssl; server_name api.example.com; }

检查代码里的IPv4硬编码

这个是最常见的兼容性问题。很多代码里直接写死了IPv4地址：

// 这种写法不兼容IPv6StringserverIp="10.0.1.60";Socketsocket=newSocket(serverIp,8080);// 数据库连接也是StringjdbcUrl="jdbc:mysql://10.0.1.60:3306/mydb";

改成用域名：

// 用域名，DNS会根据客户端情况返回A或AAAA记录InetAddressaddr=InetAddress.getByName("api.example.com");Socketsocket=newSocket(addr,8080);StringjdbcUrl="jdbc:mysql://db.example.com:3306/mydb";

还有一种隐蔽的问题——IP地址格式校验：

// 很多人写的IP校验正则只支持IPv4Patternipv4Only=Pattern.compile("^\\d{1,3}\\.\\d{1,3}\\.\\d{1,3}\\.\\d{1,3}$");// 如果业务需要校验IP格式，要同时考虑IPv6// 或者直接用InetAddress做解析，比自己写正则靠谱try{InetAddressaddr=InetAddress.getByName(userInput);// 能解析就是合法的IP（v4或v6都行）}catch(UnknownHostExceptione){// 不合法}

数据库字段长度

这个坑很隐蔽：

-- IPv4最长15个字符：255.255.255.255-- IPv6最长45个字符（含前缀长度）：2001:0db8:0000:0000:0000:0000:0000:0001/128-- IPv6压缩格式最长39个字符：2001:db8::-- 如果ip字段是varchar(15)，IPv6地址存不进去ALTERTABLEyour_tableMODIFYCOLUMNipVARCHAR(45);

这种问题在上线IPv6之前不会暴露，一旦有IPv6用户访问，写入数据库的时候直接截断或者报错。

防火墙别忘了IPv6

# 很多运维只配了iptables，没配ip6tables# IPv6端口可能完全裸奔ip6tables-L-n# 如果输出是空的或者全部ACCEPT，意味着IPv6没有任何防火墙规则

# 基础的ip6tables配置ip6tables-AINPUT-ilo-jACCEPT ip6tables-AINPUT-mstate--stateESTABLISHED,RELATED-jACCEPT ip6tables-AINPUT-ptcp--dport22-jACCEPT ip6tables-AINPUT-ptcp--dport80-jACCEPT ip6tables-AINPUT-ptcp--dport443-jACCEPT ip6tables-AINPUT-pipv6-icmp-jACCEPT ip6tables-PINPUT DROP

DNS加上AAAA记录

# A记录：域名 → IPv4api.example.com. A1.2.3.4# AAAA记录：域名 → IPv6api.example.com. AAAA2400:xxxx::1

即使你的服务端还没完全支持IPv6，也应该先在DNS层面把AAAA记录配好。用了CDN的话，CDN节点本身就有IPv6地址，用户走IPv6到CDN、CDN回源走IPv4，对你的源站完全透明。

过渡方案：CDN帮你做IPv6转IPv6

如果你的源站暂时不想改IPv6，最简单的方案是让CDN来处理。

用户（IPv6）→ CDN（IPv6入口）→ 你的源站（IPv4）

主流CDN厂商的节点全部支持IPv6。你只需要在CDN控制台开启IPv6，用户的IPv6请求到CDN节点后，CDN用IPv4回源取数据。你的源站什么都不用改。

# 开启CDN的IPv6之后验证digAAAA cdn.example.com +short# 应该返回IPv6地址# 检查源站是否还需要IPv6digA origin.example.com +short# 只有A记录没有AAAA记录也行，CDN会做转换

这是目前最省事的过渡方案。覆盖了大部分"用户侧IPv6"的需求，源站可以继续用IPv4。

什么时候需要认真对待IPv6

不是所有业务都需要立刻上IPv6。以下几种情况值得认真考虑：

面向C端用户的APP或网站。移动端用户大部分已经是双栈了。如果APP后端不支持IPv6，这部分流量会回退到IPv4，多了一层NAT转换，增加延迟。影响可能不大，但能优化为什么不优化。

出海业务。海外的IPv6普及率比国内更高。特别是欧美市场，IPv6覆盖率已经很高。出海业务如果只支持IPv4，在某些地区可能影响用户体验。

需要大量公网IP的业务。IPv4地址越来越贵，如果业务需要大量公网IP（比如IoT、CDN节点、爬虫IP池），用IPv6能省掉不少IP采购成本。

政府和国企项目。国家对政府和国企网站的IPv6改造有明确的时间要求。如果是这类项目，IPv6是必选项不是可选项。

不需要着急的：纯内网服务、面向小范围用户的内部系统、IPv4够用且没有扩展需求的场景。

总结

IPv6在国内的真实现状是这样的：

运营商网络层面已经全面就绪，手机和新装宽带基本默认开启。主流APP和大型网站已经在跑IPv6。云厂商全面支持，开启成本很低。

但中小企业网站、老旧机房、很多开发者的代码里，IPv6还是一个盲区。

不用恐慌式改造，但有些事现在就该做：新项目用双栈、检查代码里的IPv4硬编码、数据库字段加长、防火墙加上ip6tables规则、DNS配好AAAA记录。

CDN可以帮你做IPv6转IPv4的过渡，源站不改也能让用户走IPv6。

等到哪天IPv6成为强制要求再改，各种历史代码和配置改起来成本会高很多。早准备没坏处。

这个话题平时关注度不高，但从IDC行业来看推进速度确实比很多人想象的快。写出来希望对做开发的同学有点参考价值。

有问题评论区聊。