防御 CC 攻击没有万能参数，推荐从 limit_req_zone 按 IP 限流入手，rate 设 1-5r/s、burst 设 5-10、配合 10m 共享内存，根据业务敏感度逐步调整。

完整配置上下文示例

以下是一个最小可用的 nginx.conf 结构示例，展示了限流配置在配置文件中的正确位置。注意 limit_req_zone 必须放在 http 块内，而 limit_req 指令放在 server 或 location 块内。

http {
    # 定义限流区域，10m 内存约存储 16 万个 IP 状态
    limit_req_zone $binary_remote_addr zone=mylimit:10m rate=5r/s;
    limit_conn_zone $binary_remote_addr zone=addr:10m;

    server {
        listen 80;
        server_name example.com;

        # 全局默认限流（可选）
        limit_req zone=mylimit burst=10 nodelay;
        limit_conn addr 10;

        location /login {
            # 敏感接口单独严格限制
            limit_req zone=mylimit burst=5 nodelay;
            limit_conn addr 5;
        }

        location /static/ {
            # 静态资源通常不限流或宽松限制
            limit_req off;
        }
    }
}

不同业务场景参数推荐

直接套用 5r/s 可能会误伤高并发正常业务。建议先通过日志分析正常用户请求频率基线，再参考以下范围进行初始配置：

注意：生产环境上线前，务必在灰度环境或使用低流量时段进行基线测试，观察正常用户是否触发 429/503 状态码。

验证与监控方法

1. 日志统计验证

限流触发后，Nginx 默认返回 503 状态码（可配置为 429）。使用以下命令统计被拦截的请求数量：

grep " 503 " /var/log/nginx/access.log | wc -l
# 如果配置了 limit_req_status 429，则 grep " 429 "

2. 模拟压力测试

在测试环境使用 ab 工具模拟超过 rate 的请求频率，观察是否被拦截。生产环境谨慎使用，避免误触发防护影响真实用户。

ab -n 1000 -c 10 http://your-domain.com/login

3. 错误日志监控

limit_req 和 limit_conn 触发时会在 error.log 中记录关键词 "limiting requests" 或 "limiting connections"，便于实时告警。

grep "limiting" /var/log/nginx/error.log

常见工程坑点

1. burst 参数误解

burst 不是并发数上限，而是漏桶能临时容纳的额外请求数。设为 0 时所有超速请求立刻拒绝；设为 10 并配 nodelay，等于允许瞬时 10 个请求打进来，但后续仍受 rate 约束。

2. 配置位置错误

limit_req_zone 只能在 http 块中使用，不能在 server 或 location 块定义，否则 Nginx 启动会报错。limit_req 指令则相反，必须放在 server 或 location 中生效。

3. 单一维度易绕过

仅按 IP 限流时，攻击者使用代理池可绕过。高敏感场景建议结合 IP+URI 组合限流，例如 key 设置为 $binary_remote_addr$uri。

4. 误伤正常用户

rate 设得太低会影响真实用户体验。建议先设宽松参数，观察日志后逐步收紧。公开资料中没有可靠的量化数据说明"多少 r/s 最合适"，需结合基线测试调整。

5. 忘记配合其他防护

限流只是基础防护，CC 攻击严重时需配合 WAF、验证码、CDN、黑名单等手段。单靠 Nginx 限流无法应对大规模分布式攻击。

参考文档

• Nginx Official Documentation - ngx_http_limit_req_module
• Nginx Official Documentation - ngx_http_limit_conn_module