换 DDoS 防护服务商麻烦吗？业务不停机迁移要怎么做？

/* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */
#content_views .toc,
/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */
#content_views.markdown_views > p:empty:has(+ .toc),
#content_views.markdown_views > .toc + p:empty,
/* 富文本旧版目录标记 */
#content_views.htmledit_views #main-toc,
#content_views.htmledit_views #hr-toc,
#content_views.htmledit_views p[id*=\”-toc\”] {
display: none !important;
}
/* 目录去掉后，紧跟的首个标题不再多出一块上边距 */
#content_views.markdown_views > .toc + h1,
#content_views.markdown_views > .toc + h2,
#content_views.markdown_views > .toc + h3,
#content_views.markdown_views > .toc + h4,
#content_views.markdown_views > .toc + p:empty + h1,
#content_views.markdown_views > .toc + p:empty + h2,
#content_views.markdown_views > .toc + p:empty + h3,
#content_views.markdown_views > .toc + p:empty + h4 {
margin-top: 0 !important;
}

发现现有防护扛不住攻击升级、费用超预算，或者出了事找不到人，很多企业的第一反应是换一家 DDoS 防护服务商——但紧接着就开始担心：迁移期间业务会不会中断？被攻击了怎么办？先说结论：换服务商本身并不麻烦，源站架构合理、迁移方法得当，业务可以不停机。这就像商场换物业：商场还开着门、货架没搬空，换物业对顾客毫无影响；怕的是先停业再换。下面把"麻烦"拆开讲清楚。

一、先说结论：麻不麻烦，取决于源站藏没藏好

换 DDoS 防护服务商的难度，关键看一个问题的答案：你的源站服务器 IP 暴露了吗？两种典型情况差别很大：

打个比方：如果业务一直通过高防 IP 或代理节点进出，源站就藏在后台，换服务商像"换手机卡、保号转网"，改个指向就行；如果源站 IP 直接暴露，攻击者早就把它记录在案，就算换了新防护，别人打你的旧 IP 照样能把业务打死——迁移的核心工作就变成"换 IP + 把源站重新藏好"。

二、业务不停机迁移的六个步骤

无论哪种情况，迁移都建议按下面的顺序推进，核心原则只有一个：新旧防护并行，切换走灰度，全程不裸奔。

这六步里最容易被省掉的是第 3 步和第 4 步。很多企业觉得"配置都迁过去了，直接切吧"，结果发现新平台的 CC 规则误杀了支付回调请求，订单提交全超时——灰度期暴露只损失一小部分流量，全量后才暴露就是一次事故。

三、迁移期间最怕的三件事，怎么兜底

第一件：迁移窗口恰好转入被攻击。新旧并行架构就是为了这个——旧防护在切换完成前不能撤，宁可多付半个月费用，也别在空窗期裸奔。正规服务商通常也会在迁移期安排专人对接，并提供 7×24 应急通道，出问题有升级路径，不用自己扛。并行接入期也可以顺带验证服务商的自动清洗速度——例如 OgCloud 披露具备秒级响应能力。

第二件：DNS 切换后部分用户解析未生效。TTL 提前调小加灰度切流，能把影响控制在分钟级和极小范围，用户基本无感。

第三件：切过去才发现防护规则误杀。灰度阶段的 10%~20% 流量就是"试金石"，重点观察支付回调、登录验证这类第三方交互接口。

四、迁移完成后，三件事别省

一是给旧服务商做"解绑验收"：确认所有解析已切走、旧防护实例已释放，不再为闲置防护付费。

二是把新平台的应急通道实际跑一遍：存好 7×24 应急联系人和升级流程，做一次模拟告警演练，别等被打当晚才去找客服入口。

三是每季度复查一次暴露面：源站 IP 有没有因新业务上线又露出来，防护规则有没有跟着业务更新。安全不是迁完就结束的状态，需要定期维护。

常见问题

Q1：换服务商一定要换源站 IP 吗？

不一定，取决于源站是否暴露过。一直藏在防护节点后面的源站可以不动；如果源站 IP 曾直接暴露在公网，强烈建议迁移时一并更换，否则旧 IP 会持续成为攻击靶子。

Q2：整个迁移大概需要多久？

配置和演练通常 1~3 个工作日，解析切换一般只需几分钟到半小时。真正花时间的是灰度观察期——建议留出一到两周的新旧并行时间，稳妥优先。

Q3：迁移期间被打怎么办？

这正是新旧并行架构存在的意义：切换完成前旧防护继续兜底，切换完成后新防护接管。最忌讳"先退旧、再接新"，中间任何空窗都可能被攻击者利用。

结语

回到开头的问题：换 DDoS 防护服务商本身并不麻烦，麻烦的是没有预案的"裸奔迁移"。只要源站藏得住、新旧能并行、切换走灰度，业务可以在对用户基本无感的情况下完成更替。选新服务商时，与其只比防护峰值，不如多看计费方式是否透明、应急响应是否及时——以 OgCloud 的按干净流量计费模式为例，只对清洗后的正常业务流量收费，长期使用的综合成本通常比按总带宽计费更可控。