Nginx 访问控制中如何在系统遭受 CC 攻击时通过 limit_req 结合状态码临时拉黑攻击源

Nginx 本身不支持直接拉黑 IP，需通过 limit_req 标记异常请求（如返回 429），再由 fail2ban 解析日志并调用 iptables 等系统工具实现自动封禁；核心是限流作检测、外部工具执行封禁。

Nginx 本身不支持直接“拉黑 IP”（即永久或临时封禁），limit_req 的核心作用是限速，不是封禁。但它可以通过高频触发限流 + 日志标记 + 外部工具联动的方式，实现自动识别并临时拉黑攻击源的效果。关键在于：把 limit_req 当作“检测器”，再用 fail2ban 或自定义脚本读取日志，调用系统防火墙（如 iptables / nftables）真正封禁。

---

一、用 limit_req 精准标记可疑请求

先配置一个严格但可观察的限流规则，让攻击流量明显暴露在日志中：

http {# 按IP定义基础限流区（宽松些，用于探测）limit_req_zone $binary_remote_addr zone=probe:10m rate=5r/s;# 针对高危路径加严（如登录、API）limit_req_zone $binary_remote_addr zone=login:10m rate=1r/s;limit_req_zone $binary_remote_addr zone=api:10m rate=3r/s;# 自定义日志格式，带限流状态log_format blocked '$remote_addr - $remote_user [$time_local] ''"$request" $status $body_bytes_sent ''"$http_referer" "$http_user_agent" ''$limit_req_status';}

在 server 或 location 中启用，并统一返回 429 Too Many Requests（比默认 503 更语义明确，也便于日志过滤）：

server {location /api/ {limit_req zone=api burst=2 nodelay;limit_req_status 429;proxy_pass http://backend;}location /login {limit_req zone=login burst=1 nodelay;limit_req_status 429;proxy_pass http://backend;}access_log /var/log/nginx/blocked_access.log blocked;}

效果：

1. 正常用户极少触发 429；
2. 攻击者在几秒内反复刷接口，会持续产生 limit_req_status=rejected 或 429 日志行；
3. 所有被限流的请求都记录在 blocked_access.log，含真实 IP 和状态。

---

二、用 fail2ban 实时解析日志并封禁 IP

安装 fail2ban（以 Ubuntu/Debian 为例）：

sudo apt update && sudo apt install fail2ban

新建 jail 配置 /etc/fail2ban/jail.d/nginx-cc.conf：

[nginx-cc]enabled = truefilter = nginx-cclogpath = /var/log/nginx/blocked_access.logmaxretry = 5findtime = 60bantime = 3600action = iptables[name=nginx-cc, port=http,http,https, protocol=tcp]

新建 filter /etc/fail2ban/filter.d/nginx-cc.conf：

[Definition]failregex = ^<HOST> -.*"HTTP.*" 429 .*ignoreregex =

含义：

1. 60 秒内出现 5 次 429 响应 → 自动封禁该 IP 1 小时；
2. 封禁通过 iptables 直接丢包，Nginx 完全收不到后续请求，零资源消耗；
3. bantime = 3600 可按需调整为 86400（24 小时）或更短。

重启生效：

sudo systemctl restart fail2ban

验证是否生效：

sudo fail2ban-client status nginx-cc# 查看当前封禁列表sudo iptables -L f2b-nginx-cc -v -n

---

三、补充建议：避免误伤 & 提升精度

1. 排除内网和 CDN IP：在 failregex 前加 ignoreregex 过滤已知可信段，例如：

   ignoreregex = ^192.168..*|^10..*|^172.(1[6-9]|2[0-9]|3[0-1])..*|^127.0.0.1

2. 区分 NAT 用户：若业务有大量共享出口 IP（如企业用户），改用 $http_x_forwarded_for 需谨慎，务必配合 real_ip_header 和 set_real_ip_from 确保可信；否则优先考虑 URI + IP 组合限流（如 "$binary_remote_addr$uri"），降低误封概率。

3. 监控限流命中率：开启 limit_req_status 后，用 grep rejected /var/log/nginx/blocked_access.log | wc -l 快速评估攻击强度。

4. 不要依赖 if + limit_req：Nginx 明确不支持在 if 块中使用 limit_req，会导致配置加载失败。

---

四、替代方案：无 fail2ban 时的手动快速响应

若服务器环境受限（如容器、无 root 权限），可用简单脚本临时封：

# 示例：查出最近 1 分钟内触发 10+ 次 429 的 IP，并用 ufw 封禁（Ubuntu）awk '$9 == 429 {print $1}' /var/log/nginx/blocked_access.log | awk -v cutoff="$(date -d '1 minute ago' '+%b %d %H:%M:%S')" '$0 > cutoff {print $1}' | sort | uniq -c | sort -nr | awk '$1 >= 10 {print $2}' | while read ip; do ufw insert 1 deny from "$ip"; done

注意：这只是应急手段，不可长期替代 fail2ban 类守护机制。

---

Nginx 的 limit_req 是 CC 防御的“眼睛”和“闸门”，真正的“拉黑”动作要交给系统级工具完成。这种组合既轻量又可靠，生产环境已广泛验证。