Nginx limit_req结合fail2ban配置后IP已被标记封禁但仍可正常访问站点的问题排查

我已经搞定了Nginx的limit_req模块配置——现在只要有人尝试访问我们服务器上根本不存在的PHP文件，就会收到503响应。本来想在此基础上再加个fail2ban规则，把频繁碰PHP文件的IP封禁一段时间，看起来日志里已经显示我的测试IP被加入封禁列表了，但实际我还是能正常逛网站，完全没被限制住，这就很头疼了。

先贴一下我目前的配置文件：

已配置的filter文件：/etc/fail2ban/filter.d/nginx-limit-req.conf #

[Definition]
ngx_limit_req_zones = deny_rules
failregex = ^\s*\[[a-z]+\] \d+#\d+: \*\d+ limiting requests, excess: [\d\.]+ by zone "(?:%(ngx_limit_req_zones)s)", client: <HOST>,
ignoreregex =
datepattern = {^LN-BEG}

（注：/etc/fail2ban/jail.local的配置内容未完整提供，下面是针对当前问题的排查方向）

给你梳理几个大概率的排查点，你可以逐个验证：

• 检查fail2ban的封禁动作是否适配当前防火墙：默认fail2ban用iptables做封禁，但如果你的服务器用的是nftables或者其他防火墙工具，默认动作就失效了。去看你对应jail的banaction配置，是不是用了和当前防火墙匹配的动作（比如nftables环境下用nftables-multiport）。

• 确认Nginx日志路径是否在fail2ban jail中正确配置：fail2ban得能抓到Nginx的limit_req日志才能触发封禁，你要确保jail配置里的logpath指向了正确的Nginx日志文件（访问日志或错误日志），而且这个日志里确实有你测试时产生的limit_req限制记录。

• 验证防火墙里是否真的存在封禁规则：手动执行iptables -L -n（用iptables的话）或者对应的nftables命令，看看你的测试IP有没有出现在封禁链里。如果找不到这条规则，说明fail2ban的封禁动作没执行成功，可能是权限不足或者动作配置错误。

• 排查是否存在IP转发/代理导致的真实IP识别问题：如果服务器用了CDN、反向代理，fail2ban可能封禁的是CDN的IP而不是你的真实访客IP。这种情况要先确保Nginx能获取到真实访客IP，再让fail2ban基于真实IP做封禁。

• 查看fail2ban的详细日志定位问题：去翻/var/log/fail2ban.log，里面会记录封禁动作的执行细节，比如有没有报错、规则有没有正确匹配，能帮你精准定位哪一步出了问题。

备注：内容来源于stack exchange，提问作者Kevin Renskers