当服务突然出现大量 UDP 流量，且带宽或边缘设备接近处理上限时，先别急着改应用配置。反射放大攻击通常利用可被滥用的 UDP 服务向受害目标发送响应；应对重点是让流量先经过有能力处理它的入口。下面按五步说明反射型流量攻击期间的业务入口切换与恢复预案。
第一步：确认影响，保留现有证据
先联系网络服务商、云平台或现有防护服务，确认异常流量的协议、方向、峰值变化和影响范围。NTP、SSDP 等 UDP 协议可能出现在反射流量中，但仅凭协议名称不能断定攻击来源。同步检查网站或 API 的可用性、错误率、延迟，以及监控告警是否指向同一入口。
记录开始时间、受影响的域名与服务、流量变化和已做操作，暂缓无关的发布、扩容或防火墙调整。不要向疑似反射源发起反击，也不要为了压流量直接封禁所有 UDP；这可能误伤 DNS、语音或其他正常服务。
第二步：选定备用入口和切换方式
优先使用已经开通、完成验证的流量清洗服务、CDN 或具备分布式接入能力的网络服务。流量清洗适合先过滤异常流量再转发；CDN 适合缓存可缓存的内容，但动态请求仍需确认回源链路能承受压力。若考虑通过路由调整引流，应由有权限的网络团队和服务商执行，确认路由公告范围与回退方法。
DNS切换操作相对直观，但递归解析器和客户端会按各自缓存策略处理记录，修改后不一定立即全网生效。提前降低 TTL 有助于缩短后续切换等待，却无法保证攻击发生后所有缓存立即刷新。选择入口时还要核对证书、域名、健康检查和日志是否可用。
第三步：保护源站，验证备用链路
切换前确认备用入口能连到源站，且源站不会绕过防护直接对公网开放。通过云安全组、网络 ACL 或私网连接，将回源范围限制为已确认的代理或防护节点；这就是回源保护的核心。不要照抄未经核实的地址清单，允许范围应以服务商提供并维护的资料为准。
用健康检查或受控测试确认首页、登录、关键 API 等代表性路径可正常响应，并检查请求头、客户端地址记录和访问日志是否符合业务需要。若备用入口只支持静态内容，或回源仍走原来的拥塞链路，就不应把它当成完整替代方案。
第四步：执行切换并分阶段观察
- 指定负责人。明确谁有权修改 DNS 或路由，谁观察监控，谁向业务方通报，避免多人同时改动。
- 确认变更目标。再次核对记录、路由或入口配置指向的是已验证的防护路径，保留原配置以便回退。
- 实施切换。按既定变更流程调整入口；若采用 DNS，记录修改前后的值和时间，并考虑 TTL 与缓存造成的延迟。
- 分批验证。从外部探测和真实业务监控观察可用性、响应时间、错误率及回源负载。出现明显恶化时暂停扩大切换，按预先约定的回退条件处理。
切换完成不等于风险解除。反射型流量攻击期间的业务入口切换与恢复预案应规定观察窗口和升级联系人；具体观察时长取决于攻击是否持续、服务商处置进度和业务恢复速度，不宜设置一个适用于所有场景的固定分钟数。
第五步：稳定后逐步恢复并复盘
确认异常流量已受控、备用入口运行稳定、源站负载回到可承受范围后，再评估是否回切。不要仅因监控短暂下降就撤掉清洗或防护。可先确认原入口恢复能力，再分阶段调整 DNS 或路由；每次调整后检查错误率、延迟、回源请求和用户反馈，异常时停止回切并恢复上一状态。
事件结束后核对配置差异、告警时间线和服务商记录，补齐入口权限、回退步骤及联系人。将测试纳入演练，验证备用证书、健康检查、日志和回源规则是否仍有效。把这些内容写入反射型流量攻击期间的业务入口切换与恢复预案，下一次处置才能从已验证的步骤开始，而不是临时猜测。
常见问题
攻击期间临时降低 TTL 有用吗？
可能帮助后续 DNS 变更更快被采用，但已缓存的记录仍可能继续使用，不能保证立即切换。
切到 CDN 就一定能恢复吗？
不一定。要确认 CDN 能处理当前流量类型，且动态请求的回源路径、源站容量和访问控制均正常。
什么时候可以关闭流量清洗？
应结合流量趋势、服务商判断和业务监控决定；稳定一段时间并确认回切条件后，再按计划逐步调整。
没有备用入口怎么办？
先联系网络服务商或云平台寻求可用的临时防护与引流方案，同时保护源站并保留证据。事后补建经过验证的备用入口和书面预案。
