Nginx 访问控制中怎么在系统遭受 CC 攻击时通过 limit_req 结合状态码临时拉黑攻击源-Nginx-PHP中文网

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

nginx 访问控制中怎么在系统遭受 cc 攻击时通过 limit_req 结合状态码临时拉黑攻击源

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;
}

✅ 效果：

正常用户极少触发 429；
攻击者在几秒内反复刷接口，会持续产生 limit_req_status=rejected 或 429 日志行；
所有被限流的请求都记录在 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 = true
filter = nginx-cc
logpath = /var/log/nginx/blocked_access.log
maxretry = 5
findtime = 60
bantime = 3600
action = iptables[name=nginx-cc, port=http,http,https, protocol=tcp]

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

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

✅ 含义：

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

重启生效：

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

sudo systemctl restart fail2ban

验证是否生效：

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

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

排除内网和 CDN IP：在 failregex 前加 ignoreregex 过滤已知可信段，例如：
```
ignoreregex = ^192\.168\..*|^10\..*|^172\.(1[6-9]|2[0-9]|3[0-1])\..*|^127\.0\.0\.1
```
区分 NAT 用户：若业务有大量共享出口 IP（如企业用户），改用 $http_x_forwarded_for 需谨慎，务必配合 real_ip_header 和 set_real_ip_from 确保可信；否则优先考虑 URI + IP 组合限流（如 "$binary_remote_addr$uri"），降低误封概率。
监控限流命中率：开启 limit_req_status 后，用 grep rejected /var/log/nginx/blocked_access.log | wc -l 快速评估攻击强度。
不要依赖 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 防御的“眼睛”和“闸门”，真正的“拉黑”动作要交给系统级工具完成。这种组合既轻量又可靠，生产环境已广泛验证。