受攻击业务迁移至清洗集群的实施步骤，关键不在“把流量导过去”，而在于让正常请求能通过清洗、到达源站，并在异常时有路可退。迁移前先确认当前接入方式、源站地址和可用的运维窗口；以下五个环节按实施顺序展开。
一、先画清流量路径，别只改入口
先记录客户端到业务的实际链路：入口地址、清洗集群、回源地址，以及源站前的负载均衡或代理。不同接入方式的切换点不同：使用 BGP 路由牵引时，需确认公告网段和路由回收责任；使用反向代理或解析记录切换时，则要核对入口域名、目标地址与缓存影响。两种方式不能只凭“已接入清洗”判断完成，必须验证请求实际经过清洗节点。
- 列出受影响的域名、端口、协议和源站地址，并标明业务负责人。
- 向服务商或网络团队确认流量如何进入清洗集群、清洗后从哪里回源，以及源地址是否会变化。
- 准备一条可验证的测试路径；通过请求日志、连接记录或平台流量视图确认链路，而非仅看配置状态。
二、把清洗策略和业务配置提前对齐
清洗策略过严可能拦截正常请求，过宽则削弱防护。切换前整理业务实际使用的 HTTP 方法、URL 路径、请求头和长连接需求，再逐项核对策略。若有登录、支付回调或文件上传等特殊路径，应单独验证，不要假设所有页面行为相同。
证书与转发信息
检查清洗侧是否部署了覆盖目标域名的 TLS 证书，证书链和有效期是否正常；确认回源时 HTTP Host 与 TLS SNI 使用的名称符合源站配置。若应用依赖客户端真实地址，需明确使用何种可信转发头，并让应用仅信任清洗代理写入的值，避免直接采信外部请求中伪造的字段。
三、回源白名单要先改、再验证
源站若只允许指定来源访问，清洗集群新增的回源地址必须提前加入回源白名单。否则入口看似已经切换，清洗节点却无法连接源站，表现为超时或错误响应。反过来，若源站仍对所有来源开放，也可能让攻击流量绕过清洗直接抵达源站。
- 获取清洗平台给出的回源地址范围，并与网络安全规则逐项核对。
- 先添加必要的放行规则，再从清洗路径发起健康检查；保留原有管理通道，避免误锁运维访问。
- 确认日志中源站看到的连接来源与预期一致后，按变更流程收紧不再需要的直连入口。
这一环节要区分客户端源地址和清洗节点的回源地址：前者用于识别访问者，后者用于源站网络放行，不能混为一谈。
四、切换期间同时看业务与网络指标
设定切换前基线，并约定由谁观察。建议至少检查请求成功率、响应时间、源站连接数、清洗侧拦截情况和应用错误日志。指标阈值应结合业务平时波动确定，不宜套用统一数值；新路径刚启用时，可先用少量可控流量验证，再逐步扩大。若接入方式不支持分流，就应选择低风险窗口并准备更快的回退操作。
五、回退方案必须能实际执行
受攻击业务迁移至清洗集群的实施步骤，最后还包括明确失败后的恢复动作。切换前写明触发条件，例如关键请求持续失败、回源连接异常或误拦截影响核心功能；同时确认谁有权限撤回路由、恢复原入口或调整解析记录。记录原配置、变更时间和操作顺序，并确认回退后旧路径仍可用。不要只写“必要时回滚”，却没有负责人和可执行的恢复项。
切换检查清单
- 入口、协议、端口与流量路径已核对。
- 清洗策略、证书、Host 与 SNI 已验证。
- 回源白名单已放行，源站未留下不必要的绕行入口。
- 监控人员、观察指标、切换窗口和回退负责人已明确。
常见问题
清洗策略能否直接沿用原配置？
不一定。清洗平台的规则能力和业务流量特征可能不同，应先核对关键路径，并观察误拦截情况。
为什么入口切换后仍然访问失败？
常见原因包括回源地址未放行、证书或 Host 配置不匹配，以及切换后的请求没有进入预期链路。
什么时候可以撤掉旧入口？
待新路径经过业务验证、监控稳定且回退要求允许后，再按变更流程撤除；具体观察时长取决于业务周期和风险要求。
把路径、策略、回源、监控和回退逐项闭环，才能让受攻击业务迁移至清洗集群的实施步骤真正落地，而不是停留在入口配置已变更。
