网站IPv6改造要准备什么

很多站点听说要支持 IPv6，第一反应是加一条 AAAA 记录就完事了，结果上线当天一部分用户打不开，日志里全是连接超时。问题不在 DNS，而在这条链路上从负载均衡到应用、从防火墙到监控，每一层都得真的认得这个新地址。改造不是加记录，是一次贯穿全栈的连通性重建。这篇按实际推进的顺序讲：地址怎么分、哪一层最费劲、上线前怎么验证、改完之后怎么维护。

IPv6 改造到底难在哪

难的不是协议本身，是\"以为已经支持\"的错觉。系统内核早就默认开了 IPv6，数据库监听也多绑定在双栈地址上，可真正卡住的是那些写死 IPv4 字符串的地方：白名单、统计脚本、短信告警模板、日志解析规则。这类地方平时没人特意去看，一改协议就集中爆发，行号固定、字段定长的地方问题最多。上线前把这些位置列一张清单，逐个改逐个验，比出了问题再回头找快得多，清单还能当验收依据用，交付时不用再凭印象确认做没做，验收记录也能留痕，后续复盘有一手材料。

第二个难点在地址长度。IPv4 的点分四段很好记，IPv6 的十六进制一长串，人工抄录几乎必错。任何需要人手工输入地址的环节，都会在改造后变成一个高频故障点。把输入环节改成下拉选择或者在配置里引用变量，比反复强调\"别抄错\"有效。

第三个难点是访问控制。原来按 IPv4 网段做的封禁、限流、防刷规则，在 IPv6 下失效很快——一个用户随手就能拿到一整段地址，按单个地址封禁根本挡不住。这一条在改造后被刷过流量的站点应该都有体会，规则看着生效，压力一点没减。改造后第一件事就是把封禁策略从按地址改成按网段加行为特征，动作要走在被刷之前，等被打满了再改，用户已经流失一批，挽回成本比预防高得多。

地址怎么规划和分配

先向机房或服务商申请一段地址，不要指望单条地址够用。单个地址只能给一台机器的一个网卡用，做负载均衡、做健康检查、做多站点分域，很快就不够了，一段前缀才能覆盖后续所有需求。

前缀长度按用途分。对外服务的机器、内网管理地址、监控探活地址，最好分开规划，出问题时能一眼看出是哪一类流量在访问，日志分析也方便。

机器的地址建议用固定配置，不要全靠自动分配。自动分配的前缀会随上游通告变化，重启之后地址可能就换了，反向代理的回源白名单和监控目标立刻全部失效。

把 IPv6 地址写进配置时，注意格式差异。全写、缩写、大小写混用都会被当成不同的字符串比较，配置比对脚本要统一规范化之后再比，否则每次跑都会报一堆假差异。

地址规划落成一张表，谁用哪个前缀、哪些地址预留给什么用途，写清楚。改造涉及多人协作，靠口头约定一定会乱，改造涉及开发、运维、网络几拨人，一张表比开三次会对齐更有效。

申请下来的前缀先在小范围验证，确认上游通告正常、回程路由通畅，再往生产环境铺。这一步花的时间不多，能省掉后面大量排查，也避免整批机器铺下去才发现路由不对。

预算有限的起步阶段，一台机器双栈跑起来就够验证，云途 350 元档那台做双栈入口完全撑得住，等流量真的起来再考虑拆分。

应用和中间件要改什么

先查取客户端地址的代码。很多应用从前端拿 IP 的逻辑写在业务代码里，改造后拿到的是压缩格式或者带前缀的地址，长度校验、正则匹配、入库字段长度全都要跟着调整，否则报错或者截断。字段长度按 45 个字符预留，压缩写法也要能通过校验，别只按最长格式写死。存进数据库之前统一转成标准写法，查询和比对才不会出现同一台机器两种记录，后续统计和告警都会跟着错乱，报表口径也对不上，两个月的趋势图会出现断点，做季度汇报时不好解释。

再看监听配置。数据库、缓存、消息队列如果只监听在 IPv4 上，应用往 IPv6 地址连就会失败，监听地址要改成通配或者显式双栈，改完用本地连接验证一遍。验证的时候别只看端口通不通，还要确认应用连上之后能正常读写，有些驱动在双栈下的行为不一样。连接池里如果混着两种地址，重连逻辑要确认能分别处理，不然一半连接会莫名失败，排查时又找不到报错来源，只能一台台机器登上去看连接数，一个个排除特别耗时间，有统一的连接统计省事得多。

第三方接口调用也要检查。出站方向如果走 IPv6，某些老接口可能直接拒连，改造前做一轮出站连通性探测，把不支持的目标标出来，该绕开的绕开，出站方向的问题排查起来比入站更绕，提前标注能省掉大量反复试错。

防火墙和访问控制怎么调

规则要按前缀写，不要按单地址写。IPv6 下同一用户往往持有一整段，按单地址封禁等于没封，按前缀或者按网络维度限制才有效。

别把 IPv4 的规则直接复制过来。协议差异不小，很多规则在 IPv6 上下文里根本匹配不到，表面上规则都在，实际一条没生效。，限流维度也得重新想过：按地址限流在 IPv6 下很容易被绕过，改成按账号、按会话、按设备标识组合限流更稳，地址只作为辅助维度。

日志里保留完整地址方便排查，但对外展示和统计时要做脱敏，把后 64 位掩掉，既保留定位能力，又不至于把用户完整地址暴露出去。

内网管理入口单独设规则。只允许运维侧的固定前缀访问管理端口，公网侧一律拒绝，这条在 IPv6 下尤其重要，扫段工具对新协议同样熟练，管理端口暴露出去，被扫到只是时间问题，改端口只是拖延，限制来源才解决问题，两层一起做才算稳妥。

改完规则做一次全量回归：正常访问、限流触发、封禁生效、误封恢复，四种场景各验一遍，别只看正常访问通过就收工，误封恢复这条最容易漏，真误封了又找不回规则，白白丢一段时间的正常流量，恢复之后还要重新核对数据，人工成本比规则本身大得多，这笔账算下来，误封比少封贵得多，规则宁可细一点、动作慢一点，也比误伤正常用户划算。

上线前怎么验证双栈

把验证拆成两条独立链路：纯 IPv4 访问、纯 IPv6 访问，各自走一遍完整流程。混着测很容易被浏览器自动回落掩盖，看着都通，实际上一条链路是坏的，这种问题最难解释，用户说打不开，你在自己机器上怎么也复现不出来，只能靠对比两段日志才找到线索，前后花了两个小时。

先从 DNS 查起。A 和 AAAA 记录都要有，解析结果和实际机器地址一致，TTL 设置合理，切换时不至于长时间指向旧地址，改造期间两条记录并存的时间要算准。

再做端到端访问。页面、图片、接口、回调四种请求分别从两条链路打一遍，看状态码、耗时、返回内容是否一致，差异就是问题所在，耗时差出一截说明某条链路有绕行或者限速。

回源链路单独测。CDN 或反向代理到源站这一段如果走 IPv6，源站的防火墙和白名单要放行对应前缀，这一段最容易在上线当天暴露。

监控要能看到两条链路。探活任务分别配置 IPv4 和 IPv6 目标，任何一条不通立刻告警，别等用户投诉才知道。

灰度上线，按流量比例逐步放开 AAAA 记录的影响力。先小比例解析到 IPv6，观察错误率和耗时，稳定后再全量，出问题把记录撤掉就回到 IPv4。

把这次验证的清单留存下来。下一台机器上线时直接照单执行，不用重新设计一遍验证方案，也避免漏项。

改造后的长期维护

地址变更要有流程。机器重装、换机房、迁移实例都可能带来地址变化，变更前先更新白名单和监控目标，再切流量，顺序别反，先改白名单再切流量，这个顺序能让故障窗口缩到最小，回退也有据可依，不会出现两边配置对不上的尴尬。

统计口径要半年复核一次。IPv6 流量占比在持续上升，按 IPv4 时代的经验做容量和限流规划，误差会越来越大，尤其限流阈值，按老口径算会把正常用户挡在外面，阈值按新口径重新压测更稳，数字有依据，业务方也更容易接受。

地址段的续用和回收要有人管。申请下来不用是浪费，用完了没记录下次又要重新申请，写进资产台账最省事，到期时间也一起记，别等被通知回收才想起来这段地址上仍挂着业务。

新业务上线默认双栈。把双栈写进部署模板，新站点不用再单独改造一遍，这类入门机型也能直接按模板跑，省下的时间比省下的钱更值，模板统一之后新站点几乎不用额外投入，也少了一次临时改造的风险，排期上更从容，也不容易在版本切换时出岔子，节奏自己掌握，不用看别人排期，也不用临时找窗口。

收尾时再回头看一遍告警模板。地址字段长度、正则匹配、展示格式都要跟着改，别等到夜里被一条格式化失败的告警吵醒才发现问题，那种时候往往已经错过了处置窗口。