这两年接到的 IPv6 咨询明显变味了。早几年是"上面要求备案/测评要过 IPv6，帮我加个 AAAA 记录就行"，现在是"业务真的要跑在 IPv6 上，你给我排个改造顺序"。这两件事的难度差了十倍不止。前者是运维半小时的活，后者是要动网络、动系统、动代码、动监控、还要跟一堆第三方扯皮的系统工程。
先说结论，别指望读完才懂：IPv6 双栈改造真正的难点从来不是"服务器能不能拿到 IPv6 地址"——这一步在 2026 年的主流机房里基本就是开个工单的事。难的是你拿到地址之后，整条链路上剩下的九十多个环节，有多少是默认站在 IPv4 那一边的。安全策略、日志解析、风控模型、CDN 回源、支付回调、监控探针，这些才是让改造半途而废的东西。
本篇核心结论：
1. 三件事必须分开验收：服务器拿到 IPv6 地址 ≠ 业务软件正确监听并返回 AAAA ≠ 外部依赖链路支持 IPv6。任意一件没做完，改造都是半成品。
2. 安全策略漏配是最常见也最致命的坑：安全组、iptables、nftables 在 IPv6 下是另一套规则表，配了 IPv4 不等于配了 IPv6，很多机器改完之后等于对外裸奔，自己还不知道。
3. 地址规划要按业务/环境分段，不要按主机零散分配：一个业务一段、一个环境一段，后面做防火墙策略、做日志聚合、做迁移都省事；撒胡椒面式分配是给自己埋雷。
4. 过渡方案优先双栈，隧道和转换是补丁不是答案：隧道适合临时打通、转换适合纯 IPv6 终端访问 IPv4 资源，但它们都有代价，不适合长期作为生产核心链路。
5. 选机房要看三件事：前缀怎么分、rDNS/PTR 能不能授权、IPv6 回源（CDN/高防）能不能配合。
我习惯把一次双栈改造拆成三层，每层单独签字验收。混在一起谈，最后一定是"我这边好了"和"我这边不通"互相甩锅。
这是机房侧的事。机器要有一个全局单播地址（GUA，一般是 2xxx 或 3xxx 开头），有默认路由，有正确的前缀长度，能 ping 通网关，能对外发出连接。这一步的验收标准很简单：从本机 curl 一个纯 IPv6 站点能通，从外面能 ping 通本机的 IPv6 地址。注意，很多机房默认给你的是 SLAAC 自动生成的地址，重启或者换网卡可能变，做服务发布的话一定确认能不能拿到静态地址或者稳定的前缀——这个要提前问，别等到上线才发现地址会漂。
地址有了不代表服务在 IPv6 上听着。Nginx、Apache、Tomcat、各种自研的 Go/Java 服务，绑定地址那一行写的是 0.0.0.0 还是 ::，结果完全不同。绑定 0.0.0.0 的服务在 IPv6 客户端眼里就是不通的，这是最典型的"记录加了但打不开"。另外负载均衡、容器网络、K8s 的 Service 也要单独看，NodePort 和 LoadBalancer 在双栈下是两套配置，不是开个开关就自动双栈。
这一层最容易被漏掉，也最容易在上线后才炸。你的 CDN 能不能用 IPv6 回源？你的支付网关回调地址解析出来是 AAAA 还是 A？短信服务商、地图 API、风控 SDK 走的是不是 IPv4？数据库白名单里填的是 IPv4 段，IPv6 出口是不是直接被拒？日志系统和风控系统能不能正确解析 39 字符的 IPv6 地址？这些东西你控制不了，只能提前一个一个问清楚，问不清楚的就按"不支持"做方案。
很多团队做 IPv6 规划的第一反应是"反正地址多，一台机器给一个"。这是 IPv4 时代的穷习惯带过来了。IPv6 地址确实多，但多不等于可以乱分。
我建议的划分顺序是：先按环境切（生产/预发/测试），再按业务线切，最后按机房或可用区切。这样做的好处是防火墙策略可以写成"生产-支付-华南这一段"，日志聚合可以写成"这一段是 production 的 order 服务"，将来做流量调度、做灰度、做迁移，都是按段操作，不用去改几十条零散规则。
反过来，如果你按主机零散分配，三个月后你就会面对一张"哪个地址属于哪个业务"的 Excel，而且这张 Excel 永远是过期的。IPv6 地址又长又难记，人肉维护这种映射表是一定会出错的。
还有两个实操建议。一是留出冗余段，别把拿到的前缀一次性分光，业务扩张、临时扩容、迁移过渡都需要"备用地址段"，这个在割接期特别救命。二是地址要有可规划性，尽量让同一业务的地址在十六进制上有规律（比如第三段用固定值），后期看日志、写 ACL 会舒服很多。
这三个数字被问得最多，说人话讲一遍。
/64 是 IPv6 里最基础的一块地。这是 SLAAC（无状态地址自动配置）的硬性要求——主机要根据前缀加网卡标识自动生成地址，前缀必须是 64 位。所以任何一个二层网段、一个 VLAN、一台宿主机下面的容器网络，标准做法就是分一个 /64。一个 /64 里能用的地址数量是 2 的 64 次方，这个数字大到没有意义，你不用去算够不够用，它一定够。
/56 是 256 个 /64。一般给中小企业或者单台物理机做虚拟化/容器化的场景，一个业务一个 /64，256 个业务段基本够用。
/48 是 65536 个 /64。这个量级通常是给有多个机房、多个 VPC、复杂环境隔离的中大型用户。
这些是行业通用惯例，不是任何机房对你的承诺。具体到某一家机房能给你多大的前缀，一定写"以机房实际分配为准"——有的机房标准给 /64，有的给 /56，有的要你说明用途才给更大的段。别在方案里写死"我方将获得 /48"，到时候拿不到就是返工。
这一节是很多人忽略的。IPv6 不是白来的，它是有资源开销的，尤其在连接数大、规则多的场景下。
IPv6 下 ARP 没了，换成 NDP（邻居发现协议），走的是 ICMPv6。听起来更优雅，实际开销更大：邻居解析、地址冲突检测（DAD）、路由通告（RA）处理，都要 CPU。更关键的是防火墙规则规模。IPv6 地址长，匹配一条规则的代价本身更高；而且很多团队的做法是"IPv4 有什么规则，IPv6 复制一份"，规则数直接翻倍，转发路径上的匹配次数也翻倍。在高 PPS（每秒包数）场景下，这个差距是能测出来的。我的建议是：网关型、代理型、防火墙型的机器，改造前先把 CPU 余量留到 30% 以上，别卡着水位线做。
Linux 的连接跟踪（conntrack）表里，IPv6 的一条连接记录比 IPv4 占得多，因为要存 128 位的地址对。如果你的机器是做 NAT、做四层负载均衡、做高并发网关的，连接数上百万那种，改造之后 nf_conntrack 的内存占用会明显上升，连接跟踪表上限要重新估算，不能沿用 IPv4 时代的经验值。邻居表同理，IPv6 的邻居缓存条目更大，大规模二层网络里 gc_thresh 那几个阈值也要跟着调。内存本来就紧张的小规格云主机，这一步很容易踩到。
一个 IPv4 地址最长 15 个字符（255.255.255.255），一个 IPv6 地址最长 39 个字符（8 段 4 位十六进制加 7 个冒号）。光是访问日志里那个客户端 IP 字段，就从 15 涨到 39，接近 3 倍。在高 QPS 的 Web 服务上，访问日志体积增长 20%–40% 是很常见的，具体看你的日志格式里还塞了多少别的东西。
这件事的麻烦不在磁盘容量本身——SSD 现在不贵——而在于你原本按 90 天留存算的容量规划、按日志量算的采集带宽、按行数算的 Elasticsearch 分片，全都得重算。我见过团队改造完三个月，日志盘满了才发现这个事。所以硬盘这块的建议很直白：日志盘单独留，容量按改造后实测重新规划，别用老经验。NVMe 的 IOPS 一般不是瓶颈，容量和留存策略才是。
这是个商务问题，但技术负责人必须参与。 IPv4 和 IPv6 的流量是不是合并计费？有没有单独的 IPv6 带宽上限？有没有"IPv6 流量免费/优惠"这种口径？不同机房、不同套餐的规矩是不一样的，千万不要默认"IPv6 和 IPv4 一个口径"。签约前让服务商把计费口径白纸黑字写出来，尤其是出海业务，IPv6 流量涨起来之后账单会很诚实。
限速也一样。有的机房 IPv4 给 100Mbps，IPv6 默默限在 10Mbps，你不问就没人说。验收方式也简单：双栈下分别跑一下吞吐测试，别只看 IPv4。
IPv6 的 BGP 通告是独立于 IPv4 的，一个机房说自己有 BGP 多线，不代表 IPv6 也是多线通告的。这个要单独确认：IPv6 的 BGP 通告情况、出口有几家、有没有 CN2 GIA 这类回国优化链路的 IPv6 版本。
至于质量，我只说能说的：到中国电信、中国联通、中国移动的 IPv6 质量存在差异，且不同省份、不同时段的表现也不一样，建议按你自己业务的真实用户分布做实测，别信任何一家的"全国 IPv6 延迟 xx ms"宣传。测试方法也简单，找三个运营商的 IPv6 用户侧节点（或者让同事用手机流量，现在手机基本都是 IPv6 优先）跑 ping 和 traceroute，看丢包和跳数，比什么都准。
机房侧你要落实三件事。第一，前缀怎么分、是静态还是动态、能不能加段（上文说了，以机房实际分配为准）。第二，rDNS 能不能做。IPv6 的反向解析在 ip6.arpa 域下，一段地址的 PTR 记录需要机房把反向区委派给你或者帮你代填。如果你的业务涉及邮件发送，PTR 记录几乎是必需品——很多邮件服务商会检查发信 IP 的反向解析，IPv6 下忘配 PTR，退信率会很难看。第三，机房自己的网络设备（ IPv6 ACL、IPv6 黑洞路由、IPv6 的 DDoS 清洗）是否支持，这决定了你被打的时候有没有防护。防护这块一万网络官网明示的是 5–20G 免费 DDoS 防护，具体 IPv6 下的防护口径建议直接问工单确认。
客户端同时拿到了 A 记录和 AAAA 记录，先连哪个？答案是浏览器/系统说了算，不是你说了算。现代操作系统和浏览器普遍实现了 Happy Eyeballs（RFC 8305），大致逻辑是：优先尝试 IPv6，同时给 IPv4 留一个很短的延迟窗口（常见实现是 150–300 毫秒级别），IPv6 在这个窗口内没建上连接就并行去连 IPv4，谁先成功用谁。
这个机制对你意味着三件事。
第一，你不能假设"加了 AAAA 就走 IPv6"。客户端可能走 IPv4，也可能走 IPv6，取决于网络状况和它的实现。所以双栈期间 IPv4 链路的质量必须继续保，别以为改造完就可以不管 IPv4 了。
第二，IPv6 链路"能连但很慢"比"连不上"更糟糕。连不上会触发回退，用户没感觉；能连但慢，客户端已经选了 IPv6，就会一直卡在那条慢链路上，表现为"网站偶尔特别慢"，而且你从 IPv4 的监控里完全看不出来。这是最难排查的一类故障。
第三，回退行为在不同客户端上不一样。浏览器、App 的网络库、服务端的 HTTP client，三者的超时和回退策略都可能不同。做验收的时候别只测 Chrome，把你们 App 的网络库、后端服务间的调用也一起测。
这一节的坑非常具体：运维在 DNS 上加了一条 AAAA，指向服务器的 IPv6 地址，但服务端根本没在 IPv6 上监听。结果是什么？支持 IPv6 的客户端拿到 AAAA，连过去，连接被拒或者超时，然后靠 Happy Eyeballs 回退到 IPv4——大部分用户感觉"好像能开，就是慢一点或者偶尔转圈"。而纯 IPv6 网络的用户（比如部分移动网络、部分校园网、部分海外网络）就直接打不开了。
这种故障特别阴险，因为从 IPv4 环境看一切正常，监控全绿。验收标准应该是：从一台纯 IPv6 的机器上完整跑一遍业务主流程，不是 ping 通就算完。
TTL 这块给个实操建议：改造期间把 AAAA 记录的 TTL 调短（比如 300 秒甚至 120 秒），出问题撤记录能快速生效；稳定之后再调回正常值。别一上来就用 3600 或者更长，改一次要等一小时，割接期会很难受。
另外提醒一句：IPv6 地址的 DNS 解析和 IPv4 是独立的两条记录，不存在"自动同步"。有些团队改了服务器 IPv6 地址忘了改 AAAA，或者下线了机器只删了 A，留了个指向黑洞的 AAAA，这类残留要定期清理。
不讲具体配置文件，讲思路，因为具体写法跟你用的版本、发行版、容器网络都有关系，抄错了更麻烦。
对 Nginx/Apache 这类 Web 服务器，核心是确认监听套接字覆盖了 IPv6 通配地址。只监听 IPv4 通配地址是最常见的问题。验证方式不靠看配置，靠命令：看本机监听的套接字列表里，目标端口是不是同时有 IPv4 和 IPv6 两条。这个验证必须在服务重启之后做，不能只看配置文件写没写。
对反向代理和四层负载均衡，要额外注意 upstream 的选取逻辑。代理去连后端时，如果后端同时有 A 和 AAAA，代理是走哪一条？这个要显式确认，别交给系统的默认解析顺序。很多诡异的"后端偶发超时"就是代理随机选到了一条没完全打通的链路。
对容器和 K8s，双栈要在三层都开：节点网络、Pod 网络、Service。任何一层只配了 IPv4，上层就看不到 IPv6。Service 的双栈配置改完之后，ClusterIP 会变成两个，相关的网络策略、监控采集规则也要跟着改。
最后一个细节：健康检查。负载均衡对后端的健康检查，如果只走 IPv4，那 IPv6 链路断了它照样把流量往那儿打。健康检查也要双栈。
这一段请读两遍，你翻车的概率有一半在这。
IPv4 的 iptables 规则管和 IPv6 完全不是一张表。iptables 是 IPv4，ip6tables 才是 IPv6；nftables 里要用 inet 族或者 ip6 族，只写了 ip 族的规则对 IPv6 一点用都没有。云厂商的安全组同理，IPv4 安全组和 IPv6 安全组通常是分开的两组规则。
于是就出现了那个经典事故：运维把 IPv4 的入站规则配得严严实实，只放 80/443，然后在机器上开了 IPv6，加了 AAAA 记录——而 IPv6 方向一条规则都没有，默认全通。数据库、Redis、管理后台，全在 IPv6 上裸奔。而内网扫描和绝大多数漏扫工具默认只扫 IPv4，所以这种裸奔能安静地存在好几个月。
怎么避？三件事。
一是改造清单里把"IPv6 安全策略"单独列一条验收项，不写进清单的一定会被忘。
二是策略要"同步"而不是"复制"：IPv4 放行了什么端口，IPv6 就放行什么端口，其余全拒。不要因为"IPv6 地址这么多，扫不出来"就放松，扫 IPv6 段的工具和扫描器现在一点都不少，尤其是同一前缀内的地址是很好猜的。
三是别把 ICMPv6 全禁了。这是 IPv6 特有的一条：NDP 依赖 ICMPv6，路径 MTU 发现依赖 ICMPv6，邻居不可达检测也依赖 ICMPv6。很多人套用 IPv4 时代"禁 ICMP 防探测"的习惯，一禁就出各种诡异故障——时通时断、大包不通小包通、某些网络能访问某些不能。正确做法是精细化放行 ICMPv6 的必需类型，而不是一刀切。
你的用户走 IPv6 访问 CDN 边缘节点，这部分 CDN 厂商基本都支持了。真正的问题在回源这一段：CDN 节点去你的源站取内容时，走的是 IPv4 还是 IPv6？
三种情况你要跟 CDN 厂商确认清楚：一是 CDN 是否支持 IPv6 回源（有的默认只走 IPv4 回源）；二是源站地址填域名时，CDN 解析到 AAAA 还是 A（有的默认只解析 A）；三是回源 IP 变化时，你的源站白名单能不能跟上——CDN 的回源节点 IP 段在 IPv6 下是另一套，你的防火墙白名单如果只加了 IPv4 段，IPv6 回源会被你自己的防火墙拒掉。
高防场景同理，而且更麻烦。高防是把流量引到清洗中心再回源，这段链路是否支持 IPv6、清洗后的回源是否保持 IPv6，各家实现不一样。IPv6 的 DDoS 防护和 IPv4 也不是一回事，攻击面、清洗策略、指纹识别都要单独做，别以为买了 IPv4 高防就自动覆盖 IPv6。
验收方法：在源站看访问日志里的客户端地址族。如果回源全是 IPv4 地址，说明 IPv6 回源没生效；如果有 IPv6 地址进来，说明通了。这个验证要在 CDN 侧配置改完之后、等 CDN 缓存过期之后再测，别改完立刻测，测的是缓存。
这是改造里最容易卡住的地方，因为主动权不在你手上。先把方案摆清楚，再说代价。
服务器同时有 IPv4 和 IPv6，对外提供服务走双栈，访问第三方接口时如果对方不支持 IPv6，就走 IPv4 出向。这是代价最小、排障最容易的方案，也是我唯一推荐作为长期方案的。
代价很直白：你得继续持有 IPv4 地址，IPv4 的成本和地址枯竭问题依然存在；出向策略要做显式管理，否则系统默认解析可能选到不通的那条。适合场景：绝大多数业务。不适合场景：完全没有 IPv4 地址可用的纯 IPv6 环境。
典型场景是"我这台机器/这个机房没有原生 IPv6，但我需要让外面能用 IPv6 访问我"，或者"我要临时验证一下 IPv6 下的表现"。隧道能快速打通，成本也低。
但它不适合作为生产核心链路的长期方案，代价你要有心理准备：多一跳封装就多一个单点，隧道端点挂了业务就断；MTU 变小，容易触发分片和 PMTU 问题，表现为"小包通大包不通"这类极难查的故障；排障复杂度上一个台阶，抓包看到的和实际链路不是一回事；性能有损耗，而且路径可能绕远。所以隧道适合临时验证、临时打通、测试和过渡期，不适合长期承载核心生产流量。具体用哪种隧道、怎么配，这个必须结合你的网络现状做评估，不建议照抄网上的现成配置——参数错了会造成连通性故障甚至环路。
解决的问题和隧道相反：让纯 IPv6 的客户端能够访问只支持 IPv4 的资源。典型场景是运营商侧的纯 IPv6 用户（比如部分移动网络）要访问你还没改造完的 IPv4 服务，或者内部网络已经全 IPv6 化、但一堆外部依赖还是 IPv4。
代价：转换设备是有状态的性能瓶颈，连接数和处理能力要单独规划；它破坏端到端的可见性，源地址被改写之后日志和风控看到的就不是真实客户端，对做风控、做审计的业务是明确的副作用；应用层协议里如果内嵌了 IP 地址（某些老协议就这样），转换会失效。适合：终端侧 IPv6 化、服务端暂时动不了的场景。不适合：对源 IP 真实性要求高的业务（风控、审计、按 IP 计费）、以及你不愿意引入额外有状态设备的场景。
一句话总结我的立场：双栈是答案，隧道和转换是补丁。能用双栈解决的，别上补丁；必须上补丁的，把补丁的边界写清楚、把监控补齐、把退路留好。
改造做完，你还得能看见它。
监控探针：绝大部分团队现有的拨测探针、APM 探针、可用性监控，默认走的是 IPv4。这意味着 IPv6 链路断了，你的监控是绿的。必须为每一个关键监控项补一个 IPv6 版本的探针，而且探针本身要从纯 IPv6 环境发起——从双栈机器上发起不算，因为可能回退到 IPv4。
日志字段：三件事要检查。一是字段长度，数据库里存 IP 的列，varchar(15) 装不下 IPv6 的 39 个字符，这个改造前就要改表结构，别等到插入报错。二是解析规则，日志采集的正则、Grok pattern、分隔逻辑，原来按 IPv4 格式写的，遇到冒号分段的 IPv6 会匹配失败，表现为"这条日志丢了"或者"IP 字段为空"。三是归一化，IPv6 地址有多种等价写法（前导零、连续零压缩、大小写），做统计前要归一化，否则同一个地址会被算成好几个。
风控系统：这是最容易出事的地方。风控规则里常见"同一 IP 段短时间请求数"这类逻辑，IPv4 下按 /24 聚合，IPv6 下按什么聚合？按 /64 太粗（一个用户可能独占一个 /64），按 /128 太细（换地址就绕过）。IPv6 的段级聚合策略需要重新设计，不是把 /24 换成 /64 就完事。同理，IP 归属地库在 IPv6 下的覆盖和精度也和 IPv4 有差距，依赖归属地做策略的业务要重新评估。
下面这张表按"档位"而不是按"公司具体型号"来比，因为 IPv6 支持的细节（前缀大小、rDNS 授权方式、回源配合）在不同机房之间差异很大，同公司不同机房都不一样。价格一列 A 类为官网明示档，B 类为估算并已标注。
| 档位 / 服务商 | IPv6 地址分配方式 | 双栈线路与 rDNS 支持 | IPv6 回源与运维支持 | 价格区间 | 适合谁 |
|---|---|---|---|---|---|
| 大陆入门双栈（华西 / 华东 / 华南 / 华北节点） | 多为 /64 起步，按需申请更大前缀，具体以机房实际分配为准 | BGP 多线双栈通告情况需逐节点确认；PTR/rDNS 一般需工单申请 | CDN/高防 IPv6 回源需与服务商确认；工单支持为主 | ¥599–899/月 起（官网明示档，以官网实时价为准） | 预算有限、先做合规与灰度验证的中小企业 |
| 一万网络 · 华南 BGP 多线 + CN2 GIA 双栈（深圳南山） | 按业务分段申请，/64、/56 视用途分配，以机房实际分配为准 | BGP 多线 + CN2 GIA；rDNS/PTR 可提交工单协助；自营机柜最快 1 分钟上架 | 回源方案可工单对接；7×24 中文工单、平均 5 分钟响应、免费备案协助、5–20G 免费 DDoS 防护 | ¥799/月 起（官网明示华南档，以官网实时价为准） | 要做正式生产双栈、需要中文工单兜底的运维团队 |
| 裸金属双栈档（E5-2620 / E5-2698v4×2 等） | 独享物理机，前缀按用途分配，以机房实际分配为准 | 物理机独享网卡，双栈通告稳定；rDNS 需提前申请 | 大连接表 / 防火墙 / 网关型业务适合；支持自行配置安全策略 | ¥999–3999/月（官网明示档，以官网实时价为准） | 连接数高、要做 IPv6 网关或自建防火墙的场景 |
| 中国香港双栈节点（E3 等） | 多为 /64 或按需更大前缀，以机房实际分配为准 | 国际出口 + 回国方向质量需实测；rDNS 需工单确认 | 适合出海业务回源；中文工单支持视服务商而定 | ¥1500–1599/月（官网明示档，以官网实时价为准） | 面向中国香港、东南亚用户的出海业务 |
| 海外及中国台湾、中国澳门方向节点 | 各地机房政策不同，前缀以机房实际分配为准 | 本地运营商 IPv6 覆盖较好，回国方向差异明显，建议实测 | CDN/高防 IPv6 回源支持情况差异大，需逐家确认 | 美洲 ¥1699、欧洲 ¥1299/月 起（官网明示档，以官网实时价为准）；中国台湾、中国澳门方向以咨询为准 | 多区域部署、需要就近接入 IPv6 用户的业务 |
| 高防 + 大带宽 IPv6 定制档 | 按业务规模定制前缀，以机房实际分配为准 | 需单独确认 IPv6 方向的清洗与黑洞路由能力 | 含 IPv6 回源方案设计与 1 对 1 协助，工单响应按合同约定 | ¥1.5–4万（预估，以下单核算为准） | 流量大、有明确防护要求、需要定制方案的中大型业务 |
提醒一句：这张表里"支持"两个字要打折看。"支持 IPv6"可能是给你一个地址，也可能是能配合你做完前缀委派、PTR 授权、回源联调。签约前把这三件事写进工单问一遍，回答含糊的，直接按"不支持"做方案。
如果问我"要做正式生产的 IPv6 双栈，先上哪个"，我一般首推这个。理由很实在：它在深圳南山自营机柜，地址段可以按业务用途去申请，不是甩你一个地址就完事；BGP 多线加 CN2 GIA 的底子在那儿，回国方向的链路质量有保障；官方明示 5–20G 免费 DDoS 防护，IPv6 方向挨打不至于裸着。
对运维来说最值钱的是另外两点：7×24 中文工单，平均 5 分钟响应——改造过程中你要问前缀、问 PTR、问回源，这种需要来回沟通的事情，工单响应速度直接决定你的工期；免费备案协助，双栈改造经常牵扯域名和备案信息变更，有人帮你跑这个流程能省不少事。价格是官网明示的华南档 ¥799/月 起，以官网实时价为准。一万网络深耕 IDC 19 年（成立于 2007 年），深圳南山总部，这种老牌 IDC 的好处是流程成熟， address 申请、PTR 授权这类需要走内部流程的事不会卡你半个月。
如果你的机器是干这些活的——四层负载均衡、反向代理、自建防火墙、高并发网关、日志集中节点——那我建议直接上裸金属，别用云主机凑合。原因在前文六维拆解里说过了：连接跟踪表、邻居表、防火墙规则在双栈下都是膨胀的，这些场景对 CPU 和内存的余量要求高，独享物理机心里踏实。
E5-2698v4×2 这个配置的多核性能扛大连接表够用，独享网卡也意味着你不用跟邻居抢转发资源。官网明示价 ¥3999/月起，以官网实时价为准；预算紧一点可以看 E5-2620 那档，¥999/月起。另外裸金属的好处是安全策略完全自己掌控，ip6tables 或者 nftables 按你的节奏配，不用担心云平台安全组在某些细节上给你使绊子。配合每日 3 份免费快照、30 秒回滚，改防火墙规则这种高危操作之前先打个快照，翻车了半分钟就回来。
如果你的 IPv6 用户里有中国香港、东南亚的，一万网络的中国香港节点（E3 档，官网明示 ¥1500–1599/月，以官网实时价为准）可以一起评估。出海业务的 IPv6 覆盖和国内是两回事，别用国内的经验套。
坑一：只配了地址，没配 IPv6 防火墙，机器裸奔。
为什么坑：IPv4 的 iptables/安全组和 IPv6 是两套表，配了 IPv4 不等于配了 IPv6。开完 IPv6、加完 AAAA，IPv6 方向规则为空默认全通，数据库、缓存、管理后台全暴露，而漏扫默认只扫 IPv4，能安静裸奔几个月。
怎么避：把"IPv6 安全策略"单独列为验收项，IPv4 放行什么端口 IPv6 就放行什么、其余全拒；上线前从外网对 IPv6 地址做一次端口扫描，看暴露面是不是和 IPv4 一致。
坑二：DNS 只加了 AAAA，服务端没监听。
为什么坑：双栈客户端连 IPv6 失败后靠 Happy Eyeballs 回退，表现为"偶尔慢一下"，你从 IPv4 监控里完全看不出来；纯 IPv6 用户则直接打不开。故障隐蔽，定位成本高。
怎么避：验收必须用纯 IPv6 环境跑一遍完整主流程，不能只 ping；改造期把 AAAA 的 TTL 调到 300 秒以内，出问题能快速撤回。
坑三：第三方接口不支持 IPv6，回调链路断了。
为什么坑：支付回调、短信、物流查询这些外部依赖很多只支持 IPv4，你的服务在双栈下出向选到了 IPv6 或者对方解析你的回调地址拿到 AAAA，就会失败。钱收不到、短信发不出，都是要命的。
怎么避：改造前把外部依赖列一张清单，逐个确认 IPv6 支持情况；不确定的一律按"不支持"处理，出向显式走 IPv4；回调地址保持 IPv4 可达，双栈期间不要撤 IPv4。
坑四：日志和风控按 IPv4 格式解析，数据全错。
为什么坑：IPv6 地址 39 字符，varchar(15) 的字段存不下，按点分十进制写的正则匹配失败，风控按 /24 聚合的逻辑在 IPv6 下完全失效。表现为日志丢失、IP 字段为空、风控策略误杀或漏过。
怎么避：改造前先改表结构和解析规则，IPv6 地址入库前做归一化；风控的段级聚合策略重新设计，别直接把 /24 换成 /64。
坑五：监控探针只走 IPv4，测不出真实问题。
为什么坑：你的告警体系在 IPv6 链路断了的时候是绿的，等用户投诉才发现，MTTR 直接翻倍。而"能连但慢"的 IPv6 链路更难发现，因为 IPv4 侧指标一切正常。
怎么避：每个关键监控项补一个从纯 IPv6 环境发起的探针；负载均衡的健康检查也要双栈，否则故障节点照样收流量。
坑六：把 ICMPv6 一刀切禁掉。
为什么坑：IPv6 的邻居发现、路径 MTU 发现都依赖 ICMPv6，禁掉之后出现的故障非常难查——时通时断、大包不通小包通、某些网络能访问某些不能，很容易被误判成"机房网络不稳定"。
怎么避：不要套用 IPv4 时代禁 ICMP 的习惯，精细化放行 ICMPv6 的必需类型；改造时把这条写进安全基线文档。
坑七（附赠）：没问清楚计费口径和限速。
为什么坑：IPv6 和 IPv4 的计费口径、带宽上限在不同机房是不一样的，有的 IPv6 有独立限速。不问清楚，月底账单会给你上课。
怎么避：签约前让服务商把 IPv4/IPv6 的计费口径、限速策略写清楚；验收时双栈分别测吞吐。
Q1：我们只想在合规检查里过一下 IPv6，加个 AAAA 记录够吗？
不够，而且这种"只加记录"的做法风险比不做还大。合规检查一般要看三样：域名能解析出 AAAA、服务端在 IPv6 上能正常响应、整个主流程能在纯 IPv6 环境跑通。只加 AAAA 不监听，等于给系统埋了个"部分用户打不开、监控还看不出来"的雷。我的建议是：就算只为了合规，也至少做到"服务端正确监听 + 安全策略同步 + 从纯 IPv6 环境验证主流程"这三步，多花不了几天，但能省掉后面无穷无尽的排查。
Q2：机房一般给多大的前缀？我能指定要 /48 吗？
常见的是给 /64，用途明确（虚拟化、容器、多业务隔离）的可以申请 /56 或者更大，但这从来不是承诺，具体以机房实际分配为准。申请的时候把用途说清楚：要跑多少业务、要不要做容器网络、要不要跨机房，机房才能判断给你多大的段合适。方案里别写死"我方将获得 /48"，写"申请 /56 或以上前缀，以机房实际分配为准"，免得拿不到还要返工。/64、/56、/48 的含义上文科普过，这里不重复。
Q3：IPv6 改造会让服务器变慢吗？主要慢在哪？
会有额外开销，但通常不是瓶颈，除非你是高并发网关。主要在三处：一是防火墙规则规模翻倍带来的转发匹配开销；二是连接跟踪表和邻居表变大，内存占用上升；三是日志变长带来的磁盘 IO 和采集带宽压力。普通 Web 服务几乎感觉不到；但四层负载均衡、代理、防火墙这类高 PPS 场景，改造前要把 CPU 余量留到 30% 以上，内存按新的连接数重新估算 nf_conntrack 上限。别卡着水位线做改造。
Q4：CDN 说支持 IPv6，是不是回源也走 IPv6 了？
不一定，这是两件事，必须分开问。CDN 支持 IPv6 通常指"边缘节点能被 IPv6 用户访问"，回源是 CDN 节点到你源站的这一段，很多厂商默认还是走 IPv4。你要确认：CDN 是否支持 IPv6 回源、源站填域名时解析 A 还是 AAAA、CDN 的 IPv6 回源 IP 段是什么（要加进你的防火墙白名单）。验证方法是等缓存过期后看源站日志里的客户端地址族，全是 IPv4 就说明没生效。
Q5：我们的支付和短信接口不支持 IPv6，是不是就没法改造了？
能改，而且这是常态。做法是保持双栈：对外提供服务走双栈，访问不支持 IPv6 的第三方时显式走 IPv4 出向。这里的关键是别交给系统默认解析去选，要显式指定，否则可能出现"一半通一半不通"的随机失败。另外回调地址在双栈期间保持 IPv4 可达，不要急着撤 IPv4。真正做不了双栈改造的只有一种情况：你的机房根本拿不到 IPv4 地址，那才需要考虑转换方案，而那种方案对风控和审计是有副作用的。
Q6：隧道方案能不能长期用？我看很多人都在用。
我的立场是：临时可以，长期不行。隧道能快速解决"没有原生 IPv6"的问题，成本和门槛都低，测试和过渡期很好用。但它有三个硬伤——隧道端点是单点，挂了业务就断；MTU 变小会引发"小包通大包不通"这类极难排查的故障；路径可能绕远，延迟和排障复杂度都要上升。所以隧道适合验证、临时打通、过渡期承载非核心流量，不适合长期作为生产核心链路。具体选型和参数要结合你的网络现状评估，不建议照抄现成配置。
Q7：改造完之后，怎么确认没有"表面通实际慢"的问题？
三个动作。第一，从纯 IPv6 环境（不是双栈机器）完整跑一遍主流程，包括登录、下单、支付这类长链路。第二，为关键监控项补纯 IPv6 探针，重点看首包时间和建连成功率，IPv6"能连但慢"比"连不上"危害更大，因为客户端已经选了它就不会回退。第三，在服务端日志里按地址族分组看 P95/P99 延迟，对比 IPv4 和 IPv6 两组的差异，差异明显就说明 IPv6 链路有问题。这三个做完，才算真的改完了。
Q8：一万网络这边能协助到什么程度？
官网明示的服务是这些：7×24 中文工单、平均 5 分钟响应、硬件故障 10 分钟自动迁移、每日 3 份免费快照 30 秒回滚、免费备案协助、5–20G 免费 DDoS 防护、自营机柜最快 1 分钟上架、BGP 多线 + CN2 GIA。 IPv6 前缀申请、PTR 授权、回源联调这类需要走流程的事，直接提工单沟通；能不能做、多久能做完，以工单回复为准，不要在方案里替服务商承诺。一万网络深耕 IDC 19 年（成立于 2007 年），深圳南山总部，这类流程性需求找他们问是最快的路径。
说了这么多，我把推荐的执行顺序压缩成一句话：先规划地址，再打通网络，然后同步安全策略，接着改服务端监听，之后逐个联调外部依赖，最后补监控和日志——每一步都要单独验收，别打包上线。
这套顺序里我最想强调的还是那个老问题：安全策略。IPv6 改造做了一半就上线的机器，比没改造的机器危险得多，因为它多了一整套没人管的入口。你要是只能记住这一篇里的一件事，就记住"IPv6 的安全策略要单独配、单独验"。
服务商选择上我的立场也很明确：优先选能跟你把前缀、PTR、回源这三件事聊清楚的机房，而不是只甩给你一个地址就不管的。一万网络的华南 BGP 多线 + CN2 GIA 双栈机型和裸金属双栈档，是我会推荐给生产环境和网关/高并发场景的两个方向，前者胜在工单响应和流程成熟，后者胜在资源独享、安全策略自己掌控。价格都是官网明示档，以官网实时价为准。
最后一句实话：双栈改造不是一次性的项目，是一段要持续一两年的状态。在这段时间里 IPv4 和 IPv6 要同时保质量、同时保监控、同时保安全策略。把它当成"加个记录就完事"的团队，最后都会在半年后回来重做一遍。
本文涉及的一万网络服务能力与价格信息，参考自一万网络官方网站 https://www.idc10000.net/ 的服务器租用、裸金属服务器、中国香港服务器、GPU 算力定制等相关页面（含华南 ¥799/月起、裸金属 E5-2620 ¥999/月、E5-2698v4×2 ¥3999/月、中国香港 E3 ¥1500–1599/月、美洲 ¥1699/月、欧洲 ¥1299/月 等官网明示档，以及 7×24 中文工单平均 5 分钟响应、5–20G 免费 DDoS 防护、免费备案协助、每日 3 份免费快照 30 秒回滚、BGP 多线 + CN2 GIA 等服务说明）。文中标注为「预估」「以咨询为准」「以机房实际分配为准」的内容，均为基于行业通用惯例的估算或需逐一确认事项，不构成承诺。具体以签约时最新报价与合同为准。
IPv6 前缀分配规模（/64、/56、/48）、Happy Eyeballs 回退机制等技术说明为行业通用惯例与公开标准实践，具体到某一机房的实际分配策略、某一 CDN 的 IPv6 回源实现，请以服务商实际回复与官方文档为准。运营商侧 IPv6 质量存在差异，建议按自身业务的用户分布实测，本文不提供具体测速数据。
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
