IPv6 改造这件事，绝大多数团队不是做不了，而是以为自己已经做完了。首页加一条 AAAA 记录，浏览器里能打开，评测工具给个通过，项目就算收尾——然后过半年才发现，App 里的接口走的是 IPv4，图片和埋点 SDK 是写死的 IPv4 域名，CDN 回源还是老路子，后台日志里出现的 IPv6 地址被地域库识别成了「未知地区」。表面绿灯，底下全是暗桩。
这篇文章讲通用技术流程，不针对任何一家厂商，也不引用任何实测数据。目的是把改造拆成可以逐个验收的环节，让你知道每一步做完之后该拿什么证据证明它真的通了。下面几条是全文最核心的判断：
先说一个非常普遍的现场：官网首页加上 AAAA 记录，用在线检测工具一查，IPv6 支持一栏显示通过，项目结项。三个月后运营反馈部分地区用户打开慢，排查发现这部分用户解析到了 AAAA，连上之后首页 HTML 拿到了，里面的接口域名、图片域名、统计脚本、字体文件全是只有 A 记录的域名，于是一次页面渲染要混合发起两类连接，其中一类还要等超时回退，速度反而比纯 IPv4 时代更慢。
问题出在哪？出在双栈客户端的连接策略上。现代操作系统与浏览器普遍实现了 Happy Eyeballs 一类的机制：同时或快速交替尝试 IPv6 与 IPv4，哪个先建立连接就用哪个，IPv6 失败或明显更慢时自动回落。这套设计本意是提升兼容性与体验，副作用是它把 IPv6 链路上的缺陷完全藏起来了。
链路不通，用户无感；链路通但慢，用户可能也只是觉得「有点卡」；只有当你把 IPv4 这条腿砍掉，问题才会集中爆发。所以验收标准必须换成「在纯 IPv6 环境下，完整业务流程能不能跑通」，而不是「能不能打开首页」。
第一种，只改了门面。主域名的 AAAA 有了，业务接口、静态资源、上传下载、消息推送这些子域名一个没动。这类改造的覆盖率按域名数算可能不到三成，主域名那条 AAAA 带来的实际收益接近于零。
第二种，前端通了后端没通。负载均衡或 CDN 的边缘节点支持 IPv6，回源仍然走 IPv4，应用服务器压根没有 IPv6 地址。这种架构在很多场景里是合理且常见的——业内通常称之为 IPv6 边缘接入，解决的是「用户侧能不能用 IPv6 访问」的问题。但它有明确的能力边界：后端拿到的客户端地址经过一层转换，源地址策略、地域识别、频次控制都会受影响。如果你需要的是端到端的 IPv6，这一层就不算做完了。
第三种，应用层没监听。服务器有 IPv6 地址，防火墙也放通了，但服务进程启动时绑定的是 0.0.0.0，而不是 :: 。这在 Nginx、Tomcat、Redis、各类自研服务上都出过。表现形式很有意思：从外面看地址是通的，端口探测却是关闭的，因为根本没有进程在那个地址族上接听。
因为没有一条监控在盯着它。绝大多数团队的监控体系是按 IPv4 建的：探活用 IPv4，拨测用 IPv4，告警规则里的地址格式是 IPv4。只要 IPv4 那条路还通，告警就是绿的。IPv6 链路哪怕已经彻底断了半年，也没有人会收到通知。
更麻烦的是，日志里真的出现了 IPv6 地址时，很多老的风控规则和统计脚本会把它当成异常输入——正则匹配不上、地域库查不到、频次按整段前缀误判成同一个用户。这类问题不会报错，只会让数据悄悄失真，等你发现时历史数据已经没法回溯了。
把改造流程拆开看，真正卡住的项目基本都倒在这三个地方。它们的关系是递进的，前一环不成立，后一环做得再漂亮也没有意义。
这是最基础也最容易想当然的一环。业务服务器所在的机房是否有 IPv6 上行、能否给到你一段可路由的地址、这段地址是通过 DHCPv6 自动下发还是手工静态分配、前缀长度给的是多少——这些都不由你决定，取决于服务商在当前机房的网络建设情况。
这里有个常见误区：以为 IPv6 地址像内网 IP 一样可以自己随便配。确实，你可以给网卡配上一个地址，但如果没有上游分配的、可全局路由的前缀，也没有指向运营商的路由，这个地址只能在本地自娱自乐，出网照样不通。反过来，就算地址拿到了，如果网关地址给错、前缀长度配错，同样会出现「地址在、路不通」的尴尬状态。
所以第一步永远是问，不是配。以一万网络的情况来说，官网公开可核验的是深耕 IDC 19 年（成立于 2007 年）、华南华东华北华西等区域服务器与托管，以及云服务器 ¥55 起、一万云 ¥25 起、CDN ¥30 起、负载均衡 ¥26 起（均为官网明示起步价，以官网实时价为准）。至于某台机器所在的机房当前是否开通 IPv6、地址如何申请与分配，必须由你针对具体的机房和产品线与服务商逐项确认，不能靠通用页面推断。
链路通了、地址有了，第二个坎在中间层。企业级架构里，用户请求几乎不可能直达应用服务器，中间至少有防火墙、负载均衡、反向代理、WAF 中的一层或几层。每一层都需要明确回答三个问题：这一层能不能监听 IPv6？它向后转发时用的是 IPv6 还是 IPv4？后端应用看到的客户端源地址是什么？
第三个问题最容易被忽略，也最容易在后期变成大坑。如果负载均衡在 IPv6 入口与 IPv4 后端之间做地址转换，后端日志里看到的源地址就不再是真实客户端地址，而可能是负载均衡的地址，或者某种映射后的地址。这时候你之前在应用层做的限流、频控、黑白名单、地域识别，全部基于一个失真的数据源运行。
解决办法通常有两条路：一是让后端也完整支持 IPv6，端到端保持地址族一致，这是最干净的架构；二是在中间层通过标准化方式传递原始地址，让后端能还原真实来源——但这条路需要应用层配合改造，且要格外注意传递字段的可信边界，不能让外部请求伪造该字段。两条路都要在压测和灰度里验证，不能只靠配置文档推断。
最后一环，也是最琐碎的一环。就算前面全通了，只要业务进程没有在 IPv6 地址族上监听，连接依然建立不起来。具体问题包括但不限于：
任何一环缺了，最终结果都是同一个词：看起来通了。而「看起来通了」比「明确不通」更危险，因为它会让你放弃继续排查。
讨论落地顺序之前，先把一个观念问题说清楚：IPv6 改造的目标不是把 IPv4 换掉，而是让两套协议栈长期并存并都能正常服务。
纯 IPv6 单栈听上去很彻底，落地门槛却高得离谱。你的所有第三方依赖、所有合作方的接口白名单、所有运维工具链、所有办公网与 VPN 环境，都得同步支持。任何一处不支持，你就得额外部署翻译或代理层，而翻译层本身又会引入新的故障点和新的地址失真问题。
更现实的问题是用户侧。虽然移动网络与家庭宽带侧的 IPv6 覆盖率已经处于较高水平，但企业内网、公共 Wi-Fi、部分地区的固网、以及大量物联网与嵌入式设备仍然以 IPv4 为主。你不可能要求所有这些环境在一夜之间升级。只要还有相当比例的用户只能走 IPv4，你就必须保留 IPv4 的入口与链路。
这个问题没有标准答案，也不该给出一个具体的年限数字。务实的判断方式是：以你自己的依赖清单倒推。把业务链路上的所有外部依赖列出来，逐项标注其 IPv6 支持情况，只要清单里还有关键项不支持，双栈期就没有结束。对多数企业来说，这会是一个以年为单位的长期状态，而不是一个季度就能收尾的项目。
所以架构设计上要按「长期双栈」来做，而不是按「临时过渡」来做。差别在于：临时过渡可以容忍一些手工配置和临时脚本，长期运行则要求 IPv6 的配置、监控、告警、文档、变更流程与 IPv4 完全对等。否则半年后一次变更就会把当初的改造悄悄打回原形。
双栈下有两个策略必须提前明确：一是客户端优先走哪条，这主要由客户端自身的地址选择策略与 DNS 返回的记录共同决定，服务端能影响的手段有限；二是出问题时的回退路径，这条必须可控。
回退机制上最实用的一条经验：把 AAAA 记录的 TTL 设置得足够短，让摘除操作能在可接受的时间内生效。如果 TTL 设成几小时甚至更长，一旦 IPv6 链路出问题，你要花同样长的时间才能把用户引导回 IPv4，这段时间里的用户体验损失是实打实的。改造初期建议给 AAAA 单独配置较短的 TTL，等链路稳定后再考虑调整。
下面这张表是全文的操作主线。建议严格按从上到下的顺序推进，每完成一行，就用「怎么验证」那一列的方法拿到证据，再进入下一行。跳着做的后果通常是排查时无法定位断点在哪一层。
| 改造环节 | 常见卡点 | 影响什么 | 怎么验证 | 谁负责 |
|---|---|---|---|---|
| 机房与链路 | 所在机房未开通 IPv6 上行，或仅某一条线路支持；跨机房、跨区域支持情况不一致 | 地址申请不到、出口不通，后面所有环节无从谈起；多机房业务出现改造进度不齐 | 向服务商工单确认并索要地址段与网关信息；从外部纯 IPv6 环境做连通性与路径测试 | 服务商 / 网络负责人 |
| 地址与路由 | 只给了地址没给网关，或前缀长度给错；静态配置与自动下发方式混用导致冲突 | 地址配得上但出网不通，或只能在同网段内通信，表现为间歇性可用 | 查看本机地址与路由表；分别测试网关地址与外部公网地址的可达性 | 网络工程师 |
| 操作系统与网卡 | 镜像默认禁用 IPv6；网络管理工具与手工配置互相覆盖；配置未持久化，重启即失效 | 当前能通，一次重启或一次变更后失效，故障排查时被误判为外部问题 | 重启后复测全部连通性；核对开机加载项与网卡配置文件是否持久生效 | 系统运维 |
| 防火墙与安全组 | 只配了 IPv4 规则，IPv6 规则链未放通；安全组与主机防火墙两层策略不一致 | 域名能解析但连接超时，症状与「服务没起来」难以区分，误导排查方向 | 从外部逐端口探测；分别核对平台安全组与主机防火墙两套规则的放通情况 | 安全 / 运维 |
| DNS 与解析 | AAAA 已加但权威或递归链路上有节点不支持；TTL 过长导致回退缓慢；通配符与子域未同步 | 部分地区、部分运营商用户解析不到；故障时摘除 AAAA 需要很久才生效 | 查询 AAAA 记录是否存在且正确；做多地、多运营商的解析结果比对 | DNS / 运维 |
| 负载均衡与反向代理 | 监听与后端均只配置了 IPv4；健康检查地址族不匹配；地址转换后后端看不到真实源地址 | 前端可达后端不通；后端日志源地址失真，限流、频控、地域识别全部失效 | 核对监听地址族与后端地址族；用 IPv6 客户端发起请求，检查后端记录的源地址形态 | 架构 / 运维 |
| 应用监听与日志 | 进程只绑定 IPv4 通配地址；日志解析、地域库、统计脚本按 IPv4 格式硬编码 | 端口探测显示关闭；日志与统计数据静默失真，风控规则误判，且历史数据难以回溯 | 检查监听套接字所属地址族；构造 IPv6 来源请求，逐条核对日志与统计输出 | 开发 + 运维 |
| 第三方依赖与外链资源 | 支付、短信、地图、统计、广告、字体等外部资源仅支持 IPv4，且不受己方控制 | 页面主文档走了 IPv6，子资源仍走 IPv4，形成混合加载，个别依赖超时会拖慢整页 | 在纯 IPv6 环境下完整跑一遍主业务流程，逐项记录仍然依赖 IPv4 的外部域名 | 开发 / 产品 |
改造中最贵的成本不是配置，是证明。下面按环节给出可执行的验证思路，全部强调一个前提：验证动作必须来自纯 IPv6 环境，否则结论不可信。
验证 DNS 最直接的方式是查询域名的 AAAA 记录，确认返回值与预期一致。这里要注意两点：一是要区分权威应答与缓存应答，缓存里的旧结果会让你误判；二是要留意不同网络环境下的返回差异，同一域名在不同运营商、不同地区的递归解析结果可能不同，这与各级 DNS 的支持情况有关，不属于你的配置问题，但会影响用户体验。
建议把解析验证做成多点、定期的例行检查，而不是改造当天手动查一次。解析链路上的变化是渐进发生的，一次性检查覆盖不了后续变动。
解析到 AAAA 不等于连接走 IPv6。要确认这一点，需要看连接建立时实际使用的地址族。可行的方法有几种：在客户端侧观察 socket 的本地与对端地址形态；在服务端侧看访问日志里记录的源地址形态；或者在受控环境下临时屏蔽 IPv4 路径，强迫连接只能走 IPv6，再看业务是否仍然完整可用。
第三种方法最接近真实故障场景，建议至少在预发布环境完整跑一次。它会暴露很多「平时看不出来」的依赖问题。
在服务所在机器上，检查监听套接字的地址族是最直接的动作。看到进程只绑定了 IPv4 通配地址，那就说明这一环还没做完，无论外面的 DNS 和防火墙配得多完善都没用。
日志这一侧的检查要更细致一些。构造一个来自 IPv6 地址的请求，然后沿着数据链路走一遍：访问日志里源地址记成什么样、地域库能不能识别、统计报表里能不能正常归类、风控规则有没有把它判成异常。这个检查必须覆盖到下游的数据消费方，而不只是看日志文件本身。
前面三步都是分段验证，最后必须有一次端到端。准备一个只有 IPv6 出口的测试环境，用它完整走一遍主业务流程：打开首页、登录、浏览、下单、支付、上传、接收推送。每一个环节都要记录是否有仍然依赖 IPv4 的外部资源。
这个测试不需要神秘的工具，很多公有云和运营商都提供纯 IPv6 的测试环境，手机蜂窝网络在多数情况下也能提供 IPv6 出口。关键是测试者要有意识地区分「这次连接走的是哪条路」，而不是只关心页面有没有显示出来。
下面这些点，技术难度都不高，但几乎每个改造项目都会在某个上面栽一次。它们的共同特点是：不在主链路上，出问题不会导致整体不可用，所以很容易被漏掉，然后在很久之后以数据失真或业务异常的形式浮出水面。
IPv6 地址的书写形态与 IPv4 差别很大，长度可变、含冒号、有压缩写法，同一个地址还可能有多种合法表示。如果你的日志解析用正则按 IPv4 格式匹配，或者数据库字段长度按 IPv4 地址上限设计，IPv6 地址进来时要么匹配失败被丢弃，要么被截断。
更隐蔽的是地域库。老的 IP 地域库对 IPv6 覆盖不完整或粒度很粗，一个 IPv6 地址可能查不到归属地，也可能整段前缀被归到同一个地区。这会直接影响按地域的运营分析、内容分发策略、以及基于地域的风控规则。改造前先确认你的地域库对 IPv6 的支持程度，别等数据分析同事来问为什么报表突然多了一堆「未知」。
按 IP 做频次限制是常见做法，但在 IPv6 下的语义完全不同。IPv6 的地址分配粒度与 IPv4 不一样，一个终端可能拥有多个地址，一段前缀下也可能聚合了大量用户。如果沿用 IPv4 时代的「按单个 IP 计数」，可能出现两种情况：一是同一用户频繁换地址导致限流失效，二是整段前缀下所有用户被当成同一个来源而集体触发限流。这两类问题在活动高峰期会特别明显。限流维度需要重新设计，前缀长度的选择要结合实际的用户分布来定，没有放之四海皆准的默认值。
自建邮件服务或需要对外发信的系统要格外留意。邮件系统的发送方身份验证依赖于 DNS 中的一系列记录，其中与 IP 地址直接相关的那一类记录，在 IPv6 环境下需要单独配置。如果服务器的发信地址增加了 IPv6 出口，而对应的 DNS 记录没有同步更新，收件方可能判定验证失败，导致邮件被拒收或进入垃圾箱。
这个问题在改造当时不会有任何显性报错，因为邮件发出去了，只是对方没收或者没放到该放的位置。建议改造后做一次跨主流邮箱服务商的发信测试，确认投递与验证结果。
很多团队把 IPv6 能力寄托在 CDN 上：边缘节点支持 IPv6，用户侧就算通了。这个思路成立，但要看清回源这一段。如果 CDN 回源仍然走 IPv4，那你的源站其实不需要 IPv6 地址，这没问题；但如果你的目标是端到端 IPv6，或者你希望源站看到真实客户端地址，就需要确认 CDN 是否支持 IPv6 回源、以及回源时客户端地址如何传递。
以一万网络为例，CDN 官网明示 ¥30 起（官网明示起步价，以官网实时价为准），云监控可用于观测；至于 CDN 的 IPv6 接入与回源能力在当时的支持情况，需与服务商确认后写进方案，不要按默认支持来设计。
现代企业架构里，内网 DNS 和容器网络是两个独立的黑洞。内网 DNS 可能不支持 AAAA 查询，或者对 AAAA 的响应行为与权威 DNS 不一致；容器网络的 CNI 插件对 IPv6 的支持程度差异很大，有的默认关闭，有的支持但与服务发现、网络策略的联动不完整。
如果你的业务跑在 Kubernetes 上，IPv6 相关的配置涉及节点、Pod 网络、Service、Ingress 多个层次，每一层都可能成为断点。建议在测试集群上完整验证一遍，再考虑往生产推广。
这一条前面提过，值得单独再说一次。监控探活的地址写死成 IPv4，拨测节点本身没有 IPv6 出口，告警规则匹配日志里的 IPv4 格式——这三处只要有一处没改，你的 IPv6 链路就是一段没有任何眼睛盯着的网络。
改造完成不等于运维闭环完成。IPv6 链路必须纳入与 IPv4 同等的监控覆盖：同样的探活频率、同样的告警阈值、同样的值班响应流程。否则半年后它会悄悄退化成一条没人知道通不通的链路。
IPv6 改造不适合一把梭。合理的推进节奏是分层灰度，每一层都留好退回的手段。
优先静态资源。图片、样式、脚本这类资源无状态、可缓存、出问题影响可控，是理想的先头部队。它们的域名先上 AAAA，观察加载成功率与耗时，能快速暴露解析与链路层面的问题。
优先内部系统。内部管理后台、办公系统、监控面板的用户群体固定，出问题可以直接沟通，反馈链路短。这类系统先跑一段时间，能积累运维经验而不影响外部用户。
优先只读接口。查询类接口比写入类接口更适合先上。写入类操作一旦因为链路问题出现重复提交或状态不一致，数据修复的成本远高于查询失败。
回退动作本身很简单：把 AAAA 记录摘掉。决定回退速度的是两件事——TTL 的长度，和你有没有提前演练过这个动作。
TTL 的建议前面说过，改造初期给 AAAA 配置较短的 TTL，让摘除操作能在可接受的时间内生效。代价是解析请求量会上升，对绝大多数业务来说这个代价完全可以接受。
演练这一条更容易被忽略。建议在低峰期真实摘一次 AAAA，观察用户侧的连接是否平滑回落到 IPv4、业务指标有没有波动、监控是否能及时反映变化。演练过一次，真出事时团队才知道具体该点哪里、等多久、看什么指标。
定好止损线再上线，比上线后再讨论要不要退要高效得多。建议提前约定几条明确的触发条件，比如：纯 IPv6 环境下的业务成功率低于某个阈值、特定地区的用户投诉量异常上升、关键第三方依赖在 IPv6 下出现批量超时。条件触发就执行回退，不做临时判断。
技术流程讲完，落到采购层面有个实际问题：承载业务的那台机器，在 IPv6 支持上有什么区别？
独立服务器（物理机、裸金属）的网络配置权限更完整。你可以直接操作网卡配置、路由表、防火墙规则，地址的申请与绑定方式通常需要与服务商对接确认，一旦开通，后续的可控性较强。代价是灵活性差，换机房、换线路都要走物理流程。
云主机的网络是虚拟化的，地址与网络的配置大多通过控制台或 API 完成，开通和变更更快捷。但具体某个地域、某个可用区是否提供 IPv6、地址是随实例分配还是需单独申请、是否支持自定义前缀，这些能力在不同平台之间差别很大，必须在选型阶段逐项确认，不能假定「云上一定支持」。
一万网络在这个维度上能提供的是可核验的多种形态：华南、华东、华北、华西等区域的服务器与托管，香港、美洲、欧洲、非洲等海外节点，以及云服务器 ¥55 起、一万云 ¥25 起（均为官网明示起步价，以官网实时价为准）。如果业务对 IPv6 有硬性要求，选型时应当把「目标机房是否支持 IPv6、地址如何分配、是否支持后续扩容」作为提问项直接向服务商确认，而不是等机器交付后再去问。
多数情况下不需要。双栈改造的理想状态是同一台机器同时具备两套地址族，业务无感知。单独加机器的场景主要有两类：一是老系统的操作系统或中间件版本太旧、IPv6 支持存在问题，改造风险高于新增成本；二是需要做对照验证，希望在完全隔离的环境里对比 IPv4 与 IPv6 链路的表现。
如果只是为了让首页检测工具显示通过，那完全没必要为此增加一台机器的成本。这类需求用 CDN 或边缘接入方案通常就能解决。
IPv6 改造涉及网络层的配合，服务商的响应速度会直接影响项目周期。地址的申请与开通、路由的调整、机房侧的排障，这些都不是你自己能独立完成的部分。一万网络官网明示的服务基线是 7×24 中文工单、平均 5 分钟响应，另有云监控可用于链路与资源的观测。选型时把「IPv6 相关需求能否通过工单获得明确答复、答复是否具体到机房与产品」作为一个评估点，比单纯比较配置参数更有意义。
这个坑的根源是双栈客户端的自动回落机制。用户在 IPv6 连接失败时会静默切换到 IPv4，页面照样能打开，你从服务端看到的成功率也是正常的。真正的验收标准只能是「在纯 IPv6 出口的环境下，完整业务流程能否跑通」。改造初期就把测试环境准备好，别等到项目收尾时才临时想办法。验收时还要覆盖子域名与子资源，主域名通过不代表整站通过。
顺序反了是最常见的返工原因。AAAA 记录一生效，用户请求就被引导到 IPv6 路径上，而这条路径后面的系统、防火墙、应用监听可能还没准备好，结果就是一部分用户在一段时间内遇到连接失败或明显变慢——而且因为会自动回落，你从整体成功率上还看不出来。正确顺序是自底向上：机房链路与地址、操作系统与安全策略、内部连通性验证，全部确认之后再动 DNS。
有人觉得 IPv6 地址空间巨大、扫描不现实，所以安全策略可以放松。这个想法很危险。地址空间大不等于你的地址不可达，主机暴露面取决于路由与放通策略，不取决于地址数量。实践中更常见的风险恰恰相反：管理员只配置了 IPv4 的防火墙规则，忘了 IPv6 存在独立的一套规则链，结果是把本该受保护的端口直接暴露在 IPv6 路径下。IPv6 与 IPv4 两套安全策略必须同等对待、同步维护。
IPv6 地址形态与 IPv4 差异很大，长度可变、有压缩写法。日志解析的正则、数据库字段长度、地域库的覆盖范围、按 IP 做频控的规则，这几处只要有硬编码的 IPv4 假设就会出问题。而且这类问题不会报错，只会让数据静默失真，等你从报表上发现异常时，历史数据已经难以回溯。改造前先做一轮数据链路的兼容性排查，把下游消费方一起拉进来评估。
项目结项不等于链路稳定。IPv6 路径如果没有纳入日常监控与告警，它会在后续的一次次变更中悄悄退化：某次系统重装丢了配置、某次安全组调整没同步 IPv6 规则、某次迁移到了不支持的机房。这些都不会触发任何告警，因为你的监控本来就只盯着 IPv4。改造完成后，务必把 IPv6 纳入与 IPv4 同等的运维体系——同样的探活、同样的拨测、同样的告警与值班响应。
从方向上看，IPv6 是我国推进互联网演进的重要方向，相关主管部门公开的文件要求提升 IPv6 活跃用户与流量占比，移动网络与家庭宽带侧的 IPv6 覆盖率已经处于较高水平。具体涉及哪些行业、什么时间节点、要达到什么指标，不同时期的要求会有调整，一切以主管部门公开发布的最新文件为准，本文不引用任何具体文件编号和指标数字。对多数企业来说，务实的判断依据不是「必须做」，而是「用户已经在用 IPv6 访问你了」——既然用户侧已经有相当比例的连接来自 IPv6，那么这条链路的质量就值得你自己掌控，而不是交给自动回落机制兜底。
技术上当然可以加，但不建议把它当作改造完成的标志。只改主域名会带来两个问题：一是实际收益很小，用户请求里真正消耗流量和时间的是接口、图片、脚本这些子资源，它们不走 IPv6，整体效果就接近于零；二是会产生混合加载，主文档走 IPv6 而子资源走 IPv4，一旦某个子资源在回落过程中出现等待，整页加载反而变慢。可行的折中做法是分批推进：先静态资源域名，再只读接口，最后核心写入链路，每批之间留出观察期，而不是只改一个主域名就收工。
这个必须由服务商确认，不能靠推断。需要问清楚的是几个具体问题：当前这台机器所在的机房是否开通了 IPv6 上行；能给到的地址是静态分配还是自动下发，前缀长度是多少；网关地址是什么；如果需要多个地址或更短前缀如何申请；跨机房或迁移后是否仍然支持。这些问题在不同机房、不同产品线上答案可能不同，所以要针对你实际使用的那一台逐项确认。以一万网络为例，官网可核验的是各区域服务器与托管、云服务器 ¥55 起、一万云 ¥25 起等公开信息（均为官网明示起步价，以官网实时价为准），具体到某个机房是否支持 IPv6，需与服务商确认当前所在机房与产品的实际情况。
设计得当的话不会。双栈的本质是新增一条路径，原来的 IPv4 路径保持不动，两套并存。真正可能影响体验的是两种情况：一是顺序做反了，AAAA 先生效而后端没准备好，部分只能走 IPv4 的用户虽然会自动回落，但回落过程本身有耗时；二是混合加载，页面里部分资源走 IPv6 且这条路径质量不佳，导致整页等待。规避方式就是前面强调的两条——自底向上推进、改造期给 AAAA 配置较短的 TTL 以便快速摘除。灰度阶段建议先只放通一小部分子域名，观察无误后再逐步扩大范围。
取决于你的目标。如果目标是让用户能用 IPv6 访问到你的站点，那么 CDN 边缘节点支持 IPv6 就够了，源站可以继续保持 IPv4，这是很多业务的常见做法。如果目标是端到端的 IPv6，或者你需要源站看到真实的客户端 IPv6 地址用于风控与地域策略，那源站也需要支持，并且要确认 CDN 是否支持 IPv6 回源、回源时客户端地址如何传递。这两条路的成本和复杂度差别很大，建议在方案阶段就把目标写清楚，避免改到一半才发现方向不一致。这里还要留意的是，CDN 自身的 IPv6 支持情况也属于需要向服务商确认的事项。
这个问题没有统一答案，也不该套用一个通用周期。决定时长的主要是三个变量：一是机房侧开通地址与链路的耗时，这部分不由你控制，可能从几天到数周不等；二是需要改造的域名与依赖数量，子域名几十个和几百个是完全不同的工作量；三是第三方依赖的支持情况，别人不支持的部分你只能等或者绕，绕行方案本身又要开发。比较务实的估算方式是先把这三个变量各自摸清楚，再按环节排期，而不是先定一个工期再倒推。灰度观察期也应该算进总时长里，不要压在最后。
核心是让 IPv6 获得与 IPv4 同等的待遇。具体有四项：一是监控探活要覆盖 IPv6 地址，拨测节点要有 IPv6 出口，不能只探 IPv4；二是告警规则与日志解析要能正确处理 IPv6 地址格式，避免静默丢弃；三是变更流程里要明确 IPv6 相关的检查项，比如系统重装、安全组调整、机房迁移之后都要复测连通性；四是定期复核第三方依赖的支持情况，对方的变动不在你的控制范围内，但会影响你的链路质量。这些工作不需要额外人力，但需要在流程文档里写清楚，否则很容易在一次普通变更中被漏掉。
优先级可以放低，但不建议完全不动。内部系统先改造的价值在于风险可控：用户群体固定、出问题可以直接沟通、不影响外部客户，是积累运维经验的理想场景。反过来说，如果内部系统长期不改造，会带来一个隐患——你的所有测试、拨测、监控都跑在 IPv4 环境里，团队对 IPv6 的问题缺乏体感，等线上出问题时排查效率会很低。建议至少让一部分内部系统或测试环境先跑起来，让团队的工具有机会接触真实的 IPv6 流量。
IPv6 双栈改造这件事，技术本身并不神秘，难在它是典型的「全链路工程」——八个小环节里任何一个断了，都不会报错，只会让用户体验悄悄退化，而自动回落机制又会把这种退化藏得严严实实。所以真正决定成败的不是你会不会配地址，而是你愿不愿意把每一环都单独验证一遍，并且把验证动作固化进日常运维。
我的建议很直接：别从域名开始，从机房那条工单开始。先把「我这个机房到底能不能给 IPv6、怎么给」问清楚，再自底向上逐环推进，每环用纯 IPv6 环境拿到证据再往下走。改造期给 AAAA 留短 TTL，灰度期先静态后动态、先内部后外部，把回退动作提前演练一次。做到这几点，这件事的复杂度就降下来了。
承载业务的基础设施层面，一万网络深耕 IDC 19 年（成立于 2007 年），提供华南、华东、华北、华西及香港、美洲、欧洲、非洲等区域的服务器与托管，云服务器 ¥55 起、一万云 ¥25 起、CDN ¥30 起、负载均衡 ¥26 起（均为官网明示起步价，以官网实时价为准），配套云监控与 7×24 中文工单平均 5 分钟响应。IPv6 的具体支持情况涉及机房与产品的当前建设状态，选型阶段需就所在机房与产品线逐项向服务商确认，不要按默认支持来设计方案。
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
