换防护厂商不是改个 CNAME 就完事，切错一步就是几小时业务中断。本文用 10 个问答讲清 DDoS高防迁移 的触发信号、迁移前盘点、灰度切流比例、回源校验和回切预案。
Q：什么情况下才该考虑换防护厂商？
- 先分清两类问题：攻击打不穿但服务差，和根本打穿了。后者先按防护链路自查，别急着怪厂商，源站自己扛不住的情况占一半以上。
- 真该换的六个信号：清洗后仍被打穿且给不出原因；误封率长期高于 1% 而工单响应超过 4 小时；SLA 只赔代金券；计费口径含糊；节点覆盖不足（回源绕路，P95 劣化）；业务上了 IPv6 或 QUIC 而对方不支持。
- 核心原则：换厂商是计划性工程，不是应急手段。正在被攻击时不要迁移，那时的每一次解析变更都可能放大故障。
Q：迁移前要盘清哪些东西？
- 四张表，缺一张就会在切换当晚卡住：
- 域名清单：主域、子域、泛解析、备用域名，逐个标注当前入口方式。泛解析最容易漏。
- 规则清单：CC 规则与阈值、IP 黑白名单、自定义 WAF 规则、证书列表、区域封禁。
- 回源配置：源站 IP、端口、Host 头、SNI、超时设置、是否走 HTTPS 回源。
- 依赖方：谁在用你的 IP（客户端、合作方回调、监控拨测），这些是迁移时最先炸的。
- 旧平台的配置全部导出或截图存档，日志至少留 90 天。迁移中出问题，靠的就是这份对照。
Q：CNAME、NS、高防IP 三种接入，迁移难度差在哪？
- 差别很大，选错接入方式等于给自己加难度：
- CNAME 接入最容易。业务 IP 不变，只改一条解析记录，回切也是改回来，分钟级。
- NS 接入最麻烦。整个域名的解析权要搬走，MX、TXT、SPF、DKIM、验证记录必须逐条迁移，漏一条邮件就发不出去。而且注册商层面的 glue 记录也要改。
- 高防 IP 接入最硬。业务 IP 会变，凡是写死 IP 的客户端、App、第三方白名单全部要跟着改，改动面不可控。
- 结论：如果业务能接受 CNAME，迁移就选 CNAME；已经用了 NS 的，把解析记录导出成表格逐条核对再动。
Q：TTL 要不要提前改？改多少？
- 必须改，这是最容易被跳过、也最容易导致回切失败的一步。
- 切换前 48 小时 把业务记录的 TTL 降到 60~300 秒，否则全球递归服务器还在缓存旧值，你改了记录，一部分用户还在访问旧 IP。
- NS 记录本身的 TTL 也要提前降，它决定的是”解析服务器指向”的缓存时长，通常比 A 记录更长。
- 切换完成、稳定运行 72 小时 后再把 TTL 升回 3600，别提前升。
# 切换前确认全网 TTL 已经降下来
dig +short NS example.com
dig example.com A +noall +answer
dig example.com CNAME +noall +answer
# 从多个公共 DNS 交叉验证，别只看本地
dig @223.5.5.5 example.com A +short
dig @119.29.29.29 example.com A +short
dig @8.8.8.8 example.com A +shortQ：灰度切流怎么切？比例和观察指标怎么定？
- 按 5% → 20% → 50% → 100% 四档推进，每档至少观察 30 分钟，跨越一个完整的监控采集周期。
- CNAME 可按解析权重切，先给新平台 5% 权重；NS 和高防 IP 只能整体切，用”低峰时段 + 短窗口”替代灰度。
- 每档只看四个数：5xx 比例、P95 响应时间、回源 QPS、拦截率。
- 熔断线写死：5xx 超过 0.5% 或 P95 超过基线 2 倍，立即把权重拉回 0，不要”再观察五分钟”。
Q：双跑期间最容易踩的坑是什么？
- 规则不一致。流量一半走到新平台，而新平台还没配 CC 规则，攻击者只要多打几轮就能命中这个缺口，等于自己开了半边门。
- 正确做法：切流前把旧平台规则在新平台以只记录不拦截模式跑 24~48 小时，比对两边的命中差异，补齐后再开拦截。
- 第二个坑是限流桶不共享。两个平台的限流各自独立，攻击者换 IP 池能同时压两边，源站承受的是叠加流量，不是平均值。双跑期的源站容量要按 1.5 倍预估。
- 第三个坑是回源白名单只加新的没留旧的。切换失败要回切时，旧平台的回源 IP 已经被源站拒绝，回切等于再挂一次。
Q：回源怎么配才不会被绕过？
- 迁移期源站要同时允许两个平台的回源 IP 段，切换完成后才能撤旧的。这一步写进清单，别靠记忆。
- 光靠 IP 白名单不够，回源 IP 段可能被别人租用。加一层自定义头校验，头里放密钥，边缘注入、源站校验。
# 源站只接受来自防护节点的回源，并用请求头二次校验
geo $from_edge {
default 0;
203.0.113.0/24 1; # 新平台回源段
198.51.100.0/24 1; # 旧平台回源段（双跑期保留）
}
server {
listen 443 ssl http2;
server_name www.example.com;
if ($from_edge = 0) { return 403; }
if ($http_x_edge_token != "换成你的长随机串") { return 403; }
location / {
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $http_x_forwarded_for;
}
}- 另外注意：新平台的接入域名和验证信息会出现在证书透明度日志里，源站真实 IP 不要借这个机会再暴露一次。
Q：规则和证书怎么搬才不出错？
- 证书优先用 DNS 验证签发的泛域名证书，一次覆盖所有子域，避免逐域名上传。旧证书先不要删，回切时还要用。
- CC 规则的阈值不能照抄。旧平台按”每 IP 每分钟请求数”配的，新平台可能按 QPS 或按人机校验比例配，换算成同一个口径再落地，否则上线就是大面积误封。
- 黑名单导出成 CIDR 列表批量导入，几千条以上先合并相邻网段，规则条数过多会拖慢匹配。
- 自定义 WAF 规则要逐条在新平台做一次回归，尤其是正则写法和大小写敏感设置，两边引擎不同，同样的正则结果可能不同。
Q：什么时间窗切换？要避开什么？
- 选周二到周四的业务低谷，通常凌晨 1 点到 5 点。周一有发版高峰，周五出问题找不到人，周末同理。
- 避开：大促与活动期、版本发布窗口、结算或对账日、月底账单周期（出问题说不清是谁的费用）。
- 窗口给 4 小时操作 + 2 小时缓冲，并且提前一天把三方拉进同一个群：业务方、客服、厂商值班。客服不知道你在迁移，用户一投诉就会乱。
Q：回切预案怎么写？验收看哪几项？
- 回切不是”出问题再说”，而是提前把触发条件写死：5xx 持续 10 分钟超过 1%，或 P95 超过基线 2 倍，或拦截率异常（误封激增）——满足任一条就回切，不需要开会。
- 回切操作本身要演练一次：TTL 已经降过，把 CNAME 改回旧值，实测恢复时间。没演练过的预案等于没有。
- 验收五看：清洗能力的压测报告、误封率基线、日志字段是否齐全（能不能查到 IP、UA、命中规则 ID）、告警是否接入你的系统、控制台权限与 API 是否够用。
- 最后是合同：旧合同提前 30 天 书面通知，问清最低消费、超额计费口径、剩余预付款怎么退。这一步不处理，迁完还会被账单追三个月。
Q：还有什么补充建议？
- 把迁移当成一次体检。趁着重新配规则，把三年来攒下的僵尸白名单、失效黑名单、没人认领的例外一并清掉。
- 迁移完成后保留 两周 的双平台配置快照，第三周再删旧平台资源。删早了，回切就没退路。
- 写一份一页纸的迁移记录：切流时间、每档观察数据、遇到的问题、最终配置差异。下次换厂商直接拿这页当输入，能省掉一半时间。
- 反常识的一点：换了更强的防护，源站压力反而可能上升（更多流量被放行回源）。迁移后第一周要盯源站 CPU 和回源 QPS。