攻击已经影响服务时，直接把全部流量切进清洗集群，可能把路由、容量和策略配置问题同时放大。受攻击业务迁移至清洗集群的实施步骤应先确认业务入口和回源路径，再验证清洗效果，最后逐步扩大流量比例。下面的方法适用于网站、在线服务及其他需要保持外部访问的业务，具体配置要以现有网络架构为准。
先选牵引方式，确认业务怎么走
先画出“用户入口—清洗集群—源站”的链路，记录业务地址、端口、源站地址、正常流量范围、主要依赖和维护联系人。重点确认清洗后源站看到的来源地址是否变化；如果应用依赖客户端地址识别、访问控制或审计，需提前确认地址传递方式和日志解析是否兼容。
流量牵引常见有三类：运营商或网络侧路由牵引适合能统一调整入口的地址段，接入较集中，但依赖网络侧协调；隧道转发适合源站和清洗节点分处不同网络、且两端可建立稳定链路的场景，需核对隧道容量与路由范围；反向代理适合应用层流量，可按域名或路径处理，但要验证会话保持、证书和应用头部等配置。不要只按部署速度选方案，应优先选能明确回退、且与现有架构匹配的方式。
受攻击业务迁移至清洗集群的实施步骤
- 建立基线。记录切换前一段稳定时段的请求量、成功率、延迟、源站连接数与资源使用情况。可用 Prometheus、Grafana 查看既有监控；没有完整监控时，至少保留源站日志和设备计数器。基线应区分日常波动与当前攻击影响。
- 核对容量和依赖。确认清洗集群可承载的业务峰值、可用节点、最大连接能力及故障切换方式，并检查源站返回路径、访问控制和应用依赖。容量不要只看带宽，还要核对连接数、包处理能力和业务本身的计算开销。
- 配置并验证清洗策略。先使用宽松、可观测的策略，逐项检查限速、连接管理和异常流量识别规则。将已知的合法客户端、健康检查和关键业务操作纳入验证；通过测试账号或受控来源确认请求能到达源站。策略命中计数可帮助识别误拦截，必要时先调低处置强度再观察。
- 小比例灰度切换。先让一小部分可控流量经过清洗集群；若架构不支持按比例分流，可选低峰时段切换一组非关键业务地址。观察约5至15分钟作为初步检查窗口，但攻击波动、业务周期和监控延迟可能要求更长时间。确认成功率、延迟和源站负载未出现持续恶化后，再分批扩大比例。
- 全量迁入并持续观察。扩大流量后同步检查清洗侧通过量、拦截量、回源连接和源站资源。流量下降不一定表示攻击已消失，也可能是误拦截；应结合业务成功率、抽样日志和清洗策略计数判断。保留变更记录，明确谁负责观察、谁有权继续切换。
设置回退条件，不把回滚留到故障时
切换前就写明回滚触发条件，例如核心操作成功率持续低于切换前基线、延迟明显超出业务可接受范围，或清洗集群健康状态不满足承载要求。阈值应依据业务基线和服务目标制定，不存在适用于所有业务的统一数值。回滚时按预定顺序撤销牵引、恢复原入口，再确认流量回到源站原路径；同时保留清洗侧和源站的监控记录，便于定位是策略、容量还是链路问题。
常见问题
攻击仍在持续，能不能直接全量切换？
只有在容量、回源和策略已验证且回退可执行时才考虑。条件不足时，先迁入可控流量，避免一次变更扩大故障范围。
清洗后源站负载反而升高，怎么办？
检查清洗策略是否放过了大量无效请求、回源是否出现重复连接，并核对源站是否收到预期的来源信息；不要仅凭入口流量判断效果。
多长时间能判断切换成功？
至少覆盖初步观察窗口和业务关键操作；若流量有明显周期性，应跨过有代表性的业务时段再确认。
初次实施不必追求一次完成。按基线、验证、灰度、扩量和回退准备推进，受攻击业务迁移至清洗集群的实施步骤才更可控，也更容易在异常时快速恢复。
