防护服务商变更时如何平滑迁移攻击流量，关键不在于“切得快”，而在于新旧路径都准备妥当，并能及时发现异常、退回旧路径。团队应先确认流量如何进入旧服务，再核对新服务的接入方式、清洗策略和回滚条件。以下五个环节适用于不同规模的线上服务，具体操作仍需按网络架构和供应商能力调整。
一、先盘清入口、依赖和基线
把公网业务入口逐项列入迁移清单，包括域名、对外地址、协议和端口、证书责任方、源站地址，以及依赖固定来源地址的合作方。不要只查主站：管理后台、文件下载、邮件入口和移动端使用的接口域名，也可能有独立接入方式。
同时记录当前服务的正常流量基线，例如常见的每秒请求数、带宽范围、连接数和业务错误率；再从历史告警中整理攻击高峰时的流量特征。数据可以取近几周的监控记录作为参考，但节假日、发布活动等特殊时段应单独标注。没有基线，新服务上线后就难以区分正常波动与防护异常。
二、逐项复刻策略，不只复制规则名称
要求新服务商按清单确认防护范围，并核对限速阈值、挑战或拦截动作、允许列表、封禁时长、告警渠道及人工升级流程。规则名称相同，不代表触发条件和处置结果相同；过严可能拦住正常访问，过松则可能让攻击流量到达业务入口。
还要检查源站访问控制：若旧服务商使用固定出口地址，源站可能只接受该地址的连接。迁移前，应按安全审批流程加入新服务商所需的来源范围，并确认旧范围不会过早撤销。避免为图省事开放所有来源。把清洗策略和告警联系人写入交接表，便于值班人员快速定位责任方。
三、先并行验证新路径
优先选可控入口做验证，例如测试域名、内部验收环境或低风险业务入口。按真实业务流程检查页面和接口是否正常、日志能否追踪、告警是否送达，并确认新服务商能解释异常流量的处置方式。若服务商支持影子观察或仅记录不拦截的模式，可先用它评估误报；不支持时，不要擅自把生产流量导入未经验证的配置。
迁移方式也要分清：通过域名解析切换的服务，提前降低DNS TTL通常有助于缩短部分缓存的更新等待，但并不保证所有递归解析器立即刷新；使用BGP引流的服务，则需确认前缀授权、路由发布与撤销流程由谁负责。两种方式的控制面不同，不能用改解析的步骤代替路由迁移检查。
四、分批切换，并设定观察窗口
防护服务商变更时如何平滑迁移攻击流量，应把“切换顺序”和“停止条件”提前写清。可按业务重要性和依赖关系分批，每批切换后观察请求成功率、延迟、源站负载、拦截数量和告警情况。观察时长取决于流量周期与解析缓存，至少覆盖一次业务高峰更有参考价值；不能仅凭几分钟内页面可打开就判定完成。
- 指定一名切换负责人和一名监控观察人，确认双方有权限执行变更。
- 记录变更前的解析或路由状态、规则版本、联系人和回滚步骤。
- 按预定批次导入流量，每批完成后检查业务指标及新服务的清洗、告警记录。
- 如错误率持续升高、源站负载异常或关键业务不可用，暂停后续批次，按预案恢复旧路径。
如果攻击正在发生，应先与两家服务商确认并行防护是否兼容，避免两套策略互相覆盖或流量绕过清洗。此时不要临时扩大开放范围，也不要在没有确认路由状态时反复切换。
五、把回滚和收尾纳入变更
回滚预案要写成可执行步骤：由谁操作、恢复什么记录或路由、如何确认旧服务仍可接收流量、异常时联系谁。旧服务不要在新路径稳定前立即退订或撤掉必要配置。回滚后检查缓存、路由传播和源站访问控制，确认流量确实回到预期路径。
稳定运行后，再对照清单撤销不再需要的旧来源授权和账号权限，导出并保存变更记录、告警样本及新旧策略差异。防护服务商变更时如何平滑迁移攻击流量，最终要靠可验证的指标和责任明确的交接，而不是单次切换成功。
常见问题
旧服务和新服务能同时开启吗？
有时可以，但取决于接入架构及供应商是否支持并行处理。上线前确认流量走向、策略叠加影响和计费规则，不能默认双开就等于双重防护。
降低DNS TTL后多久能完成切换？
没有适用于所有网络的固定时长。解析器缓存策略、客户端缓存和记录调整时间都会影响结果；应提前调整并通过多地查询和业务监控确认，而非只看设置的TTL。
什么情况下应立即回滚？
关键业务持续不可用、错误率明显超出既定阈值、源站负载异常，或无法确认流量是否经过新防护路径时，应暂停迁移并按预案处置。阈值应在变更前结合自身基线确定。
迁移完成后能马上关闭旧服务吗？
不宜仅凭短时正常就关闭。先覆盖主要业务时段，核实告警、访问控制和应急联系人均已转交，再按合同与内部审批流程完成旧服务收尾。