Nginx 与 Fail2ban 协同封禁的核心是 Fail2ban 解析 Nginx 日志中的攻击信号（如真实 IP、状态码、敏感路径），并通过防火墙（iptables/nftables）动态拦截，而非 Nginx 自身封禁；需确保日志含 $binary_remote_addr 和 status、定制 failregex 匹配实际攻击特征、合理设置 maxretry/findtime/bantime，并用 fail2ban-regex 和 fail2ban-client 验证规则有效性。
要让 Nginx 和 Fail2ban 协同实现自动封禁，核心不是“Nginx 封 IP”，而是让 Fail2ban 准确读懂 Nginx 日志里的攻击信号，并快速调用系统防火墙拦截。整个过程依赖日志格式、过滤规则、封禁逻辑三者严丝合缝。
确保 Nginx 日志含真实 IP 与关键状态
Fail2ban 只能从日志里提取信息，如果日志中没有真实客户端 IP 或响应状态码，它就无从判断。务必检查两点：
- 使用 $binary_remote_addr 而非 $remote_addr：后者在 CDN 或反向代理后永远显示为节点 IP；前者配合 real_ip 指令才能还原真实来源
- 日志格式必须包含 status（HTTP 状态码）和请求路径，例如：
log_format main '$http_x_forwarded_for - $remote_user [$time_local] "$request" $status $body_bytes_sent'; - 若用了宝塔或 Cloudflare，需在面板中开启「获取真实 IP」，否则所有封禁都作用于 CDN 节点，毫无意义
编写精准匹配的 Fail2ban 过滤器
默认的 nginx-http-auth 规则只认 401/403，但暴力破解常返回 200（如登录接口返回 JSON 错误）、404（扫后台路径）甚至 499（客户端断连）。你需要按实际攻击特征定制 filter：
- 针对后台爆破（如 /wp-login.php、/admin/login），可匹配：
failregex = ^-.*"(GET|POST) /(wp-login\.php|admin/login|api/auth) HTTP.*" (200|400|404) - 针对扫描行为（如 /.env、/git/config），用 404 + 敏感路径组合：
failregex = ^-.*"(GET|HEAD) /(\.env|\.git/config|backup\.zip) HTTP.*" 404 - 避免误伤：加 ignoreregex 排除爬虫 UA、健康检查路径或内部监控请求
配置 Jail 并设定合理阈值
在 /etc/fail2ban/jail.d/custom.conf 中定义新 jail，关键是把“高频”转化为可执行的参数：
- maxretry = 5：比如 1 分钟内访问敏感路径超 5 次即封——数值太低易误封，太高起不到作用
- findtime = 60：时间窗口必须与业务节奏匹配。CC 类低频扫描适合 60–300 秒；爆破类短时密集行为用 30 秒更灵敏
- bantime = 3600：建议 1 小时起步，足够打断自动化脚本；对反复出现的 IP，可用 bantime.increment = true 实现累加封禁
- action 推荐 iptables-multiport（兼容性好）或 nftables-multiport（较新系统）
验证与日常维护要点
配置完别急着重启，先做三步确认：
- 用 fail2ban-regex /var/log/nginx/access.log /etc/fail2ban/filter.d/your-filter.conf 测试正则是否真能捕获目标日志行
- 运行 fail2ban-client status your-jail-name 查看当前封禁数和日志位置是否正确监听
- 手动触发一次测试请求（如 curl -I http://yoursite.com/wp-login.php?x=1），再查 fail2ban-client status 是否新增 ban 记录
- 注意：Fail2ban 封的是系统层 IP，不依赖 Nginx reload，但需确保 iptables/nftables 服务正常且未被其他安全软件覆盖规则
