站点被 CC/DDoS 的时候，你们第一反应做什么？

最近处理了几次站点被 CC/DDoS 打到不可用的情况，发现很多时候不是“没方案”，而是当下太乱：谁先做、做哪一步、怎么判断有没有效果。 我把自己常用的“十分钟止血”流程整理了一版，欢迎大家补齐/纠错，也想听听你们的第一反应是什么。

0-1 分钟：先确认是不是“真被打”

目标：别把数据库慢查询/磁盘爆了/程序死锁当成攻击。

• 看边界：Nginx/网关 QPS 是否突然飙升？带宽/连接数是否顶满？

• 看特征：是否集中在少量路径（/login 、/wp-login.php 、/api/*）或少量 IP 段？还是全站随机？

• 快速抓一眼日志（随便选一种你顺手的）

  • tail -n 200 access.log 看请求路径/UA/Referer 有没有明显模式
  • awk '{print $1}' access.log | sort | uniq -c | sort -nr | head 看 Top IP
  • awk '{print $7}' access.log | sort | uniq -c | sort -nr | head 看 Top URL

1-3 分钟：先“保可用”再“保完美”

目标：先让正常用户能打开，不纠结误伤。

第一优先：把动态请求挡在门外，先让静态/缓存顶上。

• 如果你有 CDN/WAF：

  1. 立刻开/加严 Bot/CC 防护（挑战/JS Challenge/验证码/人机验证）
  2. 对高风险路径单独加规则（/login /api /search /comment 等）
  3. 临时把全站缓存策略调“更激进”（能缓存就缓存）

• 如果只有源站：

  1. 先降级：关掉非核心功能（评论、搜索、上传、注册、API 某些接口）
  2. 让首页/关键页尽可能走缓存（哪怕是短 TTL ）

3-6 分钟：快速限速/限连（源站侧兜底）

目标：就算边界没拦住，也别让源站被打死。

Nginx 常见三板斧（按需选）

1. limit_req：限制单 IP 请求速率（对动态接口很有效）
2. limit_conn：限制单 IP 并发连接（对慢连接/刷连接有效）
3. 对特定路径单独更严：/login 、/xmlrpc.php 、/api/*

如果你愿意分享你现在的技术栈（ Nginx/Apache/Caddy 、是否容器、是否有 CDN ），我也想看看大家各自怎么落地规则的。

6-8 分钟：切换入口/换节点/隐藏源站

目标：把攻击面从“真实源 IP”转移到“抗的住的边界”。

• 有条件就切到高防/更抗揍的入口（更强的 CDN/WAF 节点、或临时切解析到抗压更强的前置）

• 隐藏源站：源站只允许 CDN/WAF 回源 IP 访问（白名单），其他全部拒绝

• 如果被直连源站打爆：

  • 临时换源站 IP/端口（配合边界）
  • 入口强制 HTTPS + HSTS （减少杂流量）

8-10 分钟：确认效果 + 留证据，准备下一步

目标：判断止血有没有成功，以及为后续溯源/优化留数据。

• 指标：带宽是否下来了？ 5xx 是否下降？源站 load 是否回落？正常访问是否恢复？

• 记录：攻击开始时间、峰值 QPS 、Top URL 、Top UA 、Top ASN/国家地区、采取的规则变更

• 如果仍扛不住：优先考虑

  1. 更强边界（专业高防/更强 WAF ）
  2. 更彻底的源站隔离（仅回源白名单）
  3. 应用层降级（只保核心接口）

想请教大家的三个问题

1. 你们遇到 CC/DDoS 时第一反应是什么？先封 IP 还是先上挑战？
2. 你们觉得“最有效的止血动作”是哪一个？（ CDN/WAF 规则、限速、缓存、隐藏源站、还是直接切高防）
3. 有哪些“看起来很对其实没用/反而更糟”的坑？