告警升高不等于所有访问都该拦截。应对ddos时，过宽的限制可能让真实用户无法登录、提交订单或完成登记；措施太轻，又可能挡不住攻击。先核对下面六项，再决定是否启用拦截以及拦到什么范围。
处置前核对这6项风险
1. 受影响的业务边界是否明确
确认告警对应的是哪个服务、页面或接口，并查清它依赖的登录、支付、查询等环节。面向公众的查询页面和内部管理入口，承受风险的方式不同。若只确认“服务变慢”，就对全部入口采取同一策略，容易把故障范围扩大。记录受影响功能、开始时间和可接受的降级方式。
2. 阈值是否依据正常流量基线
不要只凭一个瞬时峰值触发严厉封锁。按分钟或更短时间间隔查看近期正常时段的请求量、错误率、响应时间和地域变化；再与历史高峰、发布日或周期性业务高峰对照。基线要分服务和时段建立，短时波动未必是ddos。阈值没有统一适用值，应结合服务容量和观察窗口设定，并保留人工复核。
3. 正常访问变化是否被误判
新品发布、报名截止、内容被广泛转发，都可能让访问快速增加。检查业务日历、公告和近期部署记录，观察访问是否集中在合理页面、是否伴随正常的后续操作。新版本上线后，重试机制异常也会放大请求量。遇到来源分散但行为多样的流量时，先分层观察，不要仅凭访问速度或数量认定为攻击。
4. 缓解措施会影响哪些用户
不同措施各有代价：速率限制适合压制单个入口的过量请求，但阈值太低会限制共享网络中的多人；挑战验证能筛查部分自动化访问，却可能妨碍无障碍工具或无法执行脚本的客户端；流量清洗可过滤可疑流量，但需确认接入路径和覆盖范围；黑洞路由可能使目标服务整体不可达，只适合评估过业务中断代价后使用。应对ddos前，明确每种措施的对象、影响和撤销条件。
5. 谁来执行、如何回滚是否清楚
处置前指定决策人、操作人和业务联系人，确认供应商的紧急联络方式及权限。预先写明启用条件、观察时长、升级条件和回滚步骤。每次只调整一个关键策略并记录时间，便于比较效果；若正常用户错误率升高或核心功能受阻，按预案降低限制或撤销规则，而不是继续叠加封锁。
6. 日志、隐私与用户恢复是否考虑
保存足以复盘的告警、策略变更和错误统计，并限制访问权限、设定合理留存周期。避免为了排查而长期收集不必要的个人信息。攻击缓解后，还要检查排队任务、失败提交和积压请求，提供清晰的状态说明与重试指引；否则服务恢复了，用户仍可能遭遇重复提交或遗漏。
按顺序执行，减少误封
记录告警时间、受影响功能和当前用户报错，先排除发布变更或依赖服务故障。
对照分时段基线和业务日历，区分全站异常、单一入口异常与预期高峰。
选择影响范围最小的措施，从单个入口或短时策略开始，写明观察指标。
观察响应时间、错误率和正常业务完成情况；效果不佳时按升级流程处理，出现误伤则回滚。
事后复盘触发条件、误拦情况和用户恢复问题，修正基线及预案。
常见问题
流量变大就能判断是ddos吗？
不能。促销、热门内容传播或系统重试也会造成峰值，应结合访问行为、错误率和业务日历判断。
可以直接封锁可疑访问来源吗？
不宜只凭单一特征大范围封锁。共享网络可能承载许多正常用户，先用小范围策略观察影响，并准备回滚。
什么时候考虑黑洞路由？
当其他措施不足以保护更关键的网络或服务，且已评估目标服务整体不可达的代价时，再按预案决定。处置ddos的目标不只是压低流量，还要尽量维持正常用户可用。
