CC 攻击通常表现为大量看似正常的请求集中访问动态页面、搜索、登录或接口，导致 CPU、数据库连接或回源压力迅速升高。第一步不是马上把全站开启最强验证，而是确认究竟是哪条链路被打。
第一分钟：记录现象
- 开始时间、持续时间和当前是否仍在发生。
- 带宽、连接数、CPU、数据库和错误率的变化。
- 被集中访问的域名、路径、参数和地区。
- 正常用户是否已经受影响，影响的具体功能是什么。
前三分钟：保护源站
检查源站 IP 是否可以通过历史 DNS、邮件、第三方监控或直连绕过边缘。临时限制非必要直连，并确认登录、支付、API 等关键入口的流量路径。
五分钟内：先处理最明确的异常
优先对明确异常的高频路径、恶意参数或特定来源做小范围限制。人机验证、限流和规则拦截都可能影响真实用户，应逐步启用，并观察误伤和业务转化。
稳定后：验证比“拦截数”更重要
- 首页、搜索、登录、下单和支付是否正常。
- 异常请求下降后，回源和 CPU 是否恢复。
- 是否出现被正常用户触发的误拦截。
- 攻击是否转移到其他域名、接口或协议。
事后：保留证据和复盘
记录攻击时间、峰值、路径、规则变化、业务影响与处置结果。确认是否需要调整源站架构、隐藏真实 IP、增加缓存或优化数据库，而不是只增加一层防护后继续暴露同样的入口。
正在遭受严重攻击时，不要在没有记录的情况下反复重启或盲改全部配置。先保留现象和日志，再按可控步骤处理；正式服务应以服务商的实际应急流程为准。