真正起效的方案是Nginx限流与Fail2Ban联动：Nginx用limit_req做实时速率控制，Fail2Ban通过分析日志识别绕过限流的恶意IP并调用防火墙封禁，再辅以分层策略、日志标记和人机验证形成闭环防御。
靠单一限流指令扛不住真实 CC 攻击。真正起效的方案，是把流量监控、实时响应和自动封禁串成一条线——Nginx 负责“看门+限速”，Fail2Ban 负责“盯日志+拉黑”，再加一点日志分析和策略分层，就能形成闭环防御。
用 limit_req 做第一道动态闸机
Nginx 的 limit_req 模块不是简单设个“每秒10次”，而是按场景分层控流：
- 对登录页、验证码接口这类高风险路径，用
rate=1r/s burst=3 nodelay，严防暴力试探 - 对 API 接口，建议组合维度限流：
limit_req_zone "$binary_remote_addr$uri" zone=ipuri:10m rate=3r/s，避免同一 IP 刷多个端点 - 静态资源（js/css/图片）可放宽到
burst=20，但记得关掉 access_log 减少 I/O 压力 - 所有限流规则必须配合
log_format中的$limit_req_status字段，才能区分 passed、rejected、delayed
让 Fail2Ban 看懂 Nginx 日志并自动出手
光限流不够，很多攻击会降频绕过。Fail2Ban 的价值在于“从日志里揪出异常模式”：
- 配置 filter 规则时，不只匹配 404 或 503，更要抓
"GET /login.*HTTP+ 高频 200/429 组合，识别“成功爆破前的扫号行为” - 封禁动作别只走 iptables，优先用 firewalld 的 rich rule，支持带时间戳的日志标记，方便回溯
- 设置
bantime = 3600（1小时）、findtime = 600（10分钟内触发5次），避免误伤 CDN 回源或爬虫白名单 - 把 Fail2Ban 的 jail 日志接入 ELK 或 Grafana，一眼看出哪些 IP 在反复试探、哪个 URI 是攻击热点
加一层轻量级人机验证兜底
当限流频繁触发又无法确认是否为真实用户时，不要直接 503，改用 429 + 重定向到验证页：
- 在 server 块中配
error_page 429 = @captcha;，把超限请求导流到验证入口 - @captcha location 内嵌 Cloudflare Turnstile 或 hCaptcha，返回纯 HTML 页面，不走后端
- 验证通过后发放短期 token，Nginx 用 map 指令识别该 token 并临时豁免限流区域
- 注意：此机制仅用于关键路径（如下单、评论），首页或列表页不建议启用，影响 SEO 和首屏速度
监控与调优不能只看配置有没有生效
上线后必须验证闭环是否真通：
- 用
nginx -T | grep limit_req检查配置是否被正确加载，特别注意 zone 名称拼写和作用域（http/server/location） - 查共享内存使用率：
awk '/^mylimit/ {print $3}' /proc/$(pidof nginx)/status，超 80% 就要扩 zone 大小或换 key - 定期跑脚本统计
$limit_req_status rejected占比，持续高于 5% 就说明阈值设太紧，需结合业务基线调整 rate/burst - 用
fail2ban-client status nginx-http-auth查当前封禁数，若每小时新增超 200 条，说明攻击强度上升，应同步收紧 findtime 或增加 geoip 黑名单
