识别CC攻击需从真实请求源出发，结合时间集中性、路径单一性、UA/Referer异常、响应状态码失衡四维度交叉验证，并确保Nginx日志记录的是$binary_remote_addr真实IP，再通过脚本筛查高频恶意IP并闭环至自动化防御。
识别 CC 攻击不能只看日志里有没有“异常”，关键是从真实请求源出发，结合时间、行为、响应三维度交叉验证。Nginx 的 access_log 是唯一可信的原始证据，但必须确保记录的是还原后的客户端真实 IP（即 $binary_remote_addr），否则所有分析都建立在错误基础上。
确认日志记录的是真实 IP
如果网站前面有 CDN 或反向代理（如 Nginx 前还有一层 SLB、Cloudflare），默认的 $remote_addr 只是上游节点地址。必须启用 realip 模块，并配置：
– 使用 X-Forwarded-For 或 X-Real-IP 头还原源 IP
– 在 log_format 中使用 $binary_remote_addr（二进制格式更省内存，也适配 limit_req_zone）
– 验证方式：用 curl -H "X-Forwarded-For: 1.2.3.4" 访问，检查日志中是否出现 1.2.3.4
从日志中抓取典型 CC 行为特征
CC 请求表面合法，但组合模式暴露本质。重点筛查以下几类信号：
- 时间集中性：用 awk + sort 统计每分钟请求数，例如某 IP 在 13:22 分发起 187 次请求，而其他分钟均 ≤5 次，就是强可疑脉冲
- 路径单一性：top 10 请求 URI 中，超过 7 个是 /api/search、/wp-login.php 或 /index.php?keyword=xxx，说明目标明确
- UA 与 Referer 异常：大量请求 UA 为空、含 python-requests/go-http-client/java、Referer 为空或固定为某不存在域名
- 响应状态码失衡：同一 IP 的请求中，95% 以上返回 200（说明后端成功处理，资源已被消耗），几乎无 302/404/429，区别于正常爬虫或误访问
用脚本快速定位攻击源 IP
无需复杂工具，一条 shell 命令就能筛出高危 IP：
- 查最近一小时高频 IP：awk '$4 > "[01/Sep/2026:12:" {print $1}' /www/wwwlogs/your-site.log | sort | uniq -c | sort -nr | head -20
- 查集中扫登录页的 IP：awk '$9 == "200" && $7 ~ /\/(wp-login|login|api\/auth)/ {print $1}' /www/wwwlogs/your-site.log | sort | uniq -c | sort -nr | head -10
- 查空 UA 或工具 UA：awk '$12 ~ /"(-|python|go-http|java|curl)/ {print $1}' /www/wwwlogs/your-site.log | sort | uniq -c | sort -nr
输出结果中，单 IP 请求量 >80 次/10 分钟，且集中在动态接口，基本可判定为 CC 源头。
把日志分析结果转为防御动作
发现恶意 IP 后，不能只手动 deny —— 要闭环到自动化防护：
- 将脚本输出的 IP 自动写入 Nginx 的 geo 或 map 模块，配合 if return 444 实现实时拦截
- 接入 Fail2Ban：配置 jail.local 规则，匹配 “同一 IP 10 秒内 50 次 200 响应到 /api/submit”，触发 iptables 封禁 1 小时
- 对已限流的请求，在日志中打标（用 log_format + if），例如加字段 limit_status，方便后续统计误判率和攻击衰减趋势
