是否切换，关键不在于攻击流量看起来有多大，而在于它是否已挤占正常业务的入口资源。受攻击业务迁移至清洗集群的实施步骤，适用于攻击持续、入口反复拥塞，且现有防护无法稳定区分正常与异常流量的情况；如果只是短时波动，扩容可能更快，也更简单。
先判断扩容能不能解决瓶颈
临时扩容增加的是业务侧的计算、连接处理或网络承载能力。如果攻击流量在到达业务前已经压满接入链路，增加服务器通常不能消除入口拥塞；若瓶颈确实在应用处理能力，扩容则可能缓解压力。还要检查数据库、缓存、负载均衡等下游环节，避免入口变宽后把压力转移到后端。
清洗集群先识别并过滤异常流量，再把可放行的请求转发至源站。它能否发挥作用，取决于接入方式、清洗能力、规则准确性和回源链路。切换还会增加链路环节，若配置错误或规则过严，可能影响正常用户。因此，不能只因“正在被打”就无条件迁移。
受攻击业务迁移至清洗集群的实施步骤
- 确认保护范围。列出受影响的公网地址、业务入口、服务端口及依赖关系，区分哪些服务必须优先恢复。记录正常时的访问量、响应时间、错误率和源站负载，作为切换前基线。
- 核实接入与容量。向防护服务提供方确认接入方式、可承载范围、清洗策略和故障支持流程。若采用BGP引流，需确认路由授权、公告范围及撤回方式；若采用代理接入，则要检查客户端来源信息、证书配置和源站访问控制。容量应按业务峰值及攻击不确定性留出余量，不能仅按当前观测值配置。
- 准备源站与规则。先设置允许清洗集群回源的访问策略，限制不必要的直连入口，避免攻击者绕过清洗节点直达源站。与服务方核对放行规则，对登录、搜索、下单等不同请求分别评估；先采用保守策略，避免把正常请求误判为攻击。
- 进行小范围验证。在不影响主业务的条件下，验证健康检查、证书、回源地址、客户端来源记录和关键功能。检查静态内容与动态请求表现，确认清洗节点到源站的延迟和错误率在业务可接受范围内。未验证回退方案前，不要把全部流量一次性切过去。
- 分阶段切换并观察。按预案调整路由或接入配置，先迁移可控范围，再扩大到其余业务。切换期间持续关注正常请求成功率、响应时间、清洗命中情况、源站负载和回源链路；若误拦截增加，应及时调整规则，而不是盲目扩大放行范围。
- 明确回退条件。预先约定触发回退的现象，例如关键功能持续失败、回源异常或清洗策略误伤明显，并确认路由撤回、配置恢复的负责人和顺序。每次调整后留存时间、变更项和监控结果，便于定位问题。
清洗迁移与临时扩容，适用条件不同
| 方案 | 更适合的情况 | 主要限制 |
|---|---|---|
| 临时扩容 | 瓶颈在源站计算或应用处理，攻击较短且入口仍有余量 | 不能自动过滤恶意流量，成本与资源调度受限 |
| 迁入清洗集群 | 入口持续拥塞，需要在到达源站前识别并过滤流量 | 涉及引流、策略和回源配置，切换不当会产生误拦或新增延迟 |
因此，持续攻击且入口资源受压时，清洗通常比单纯扩容更直接；如果只有源站算力不足，先扩容可能更合适。受攻击业务迁移至清洗集群的实施步骤应与扩容判断并行：先确认瓶颈，再决定是改变流量路径、增加处理资源，还是两者配合。
常见问题
切换期间业务一定会中断吗？
不一定。是否中断取决于接入方式、配置准备和变更过程。先验证健康检查、回源和回退，再分阶段切换，可降低风险，但不能承诺完全无感。
切到清洗集群后还要扩容吗？
可能需要。清洗负责过滤异常流量，不会自动增加源站处理能力；如果正常请求已超过应用容量，仍需扩容或优化后端。
什么时候不宜立即迁移？
接入授权、回源策略或回退路径尚未确认时，不宜仓促切换。应先补齐配置并验证关键业务，否则可能把攻击问题变成配置故障。
清洗规则误拦正常用户怎么办？
查看被拦请求特征和业务日志，缩小规则影响范围，必要时调整策略并验证。不要直接关闭所有过滤规则，以免异常流量重新压垮入口。
