fail2ban在宝塔中安装后需检查三件事：服务状态是否active(running)、防火墙后端（firewalld/iptables）是否匹配、ssh日志文件（/var/log/secure或auth.log）是否存在且含失败记录；nginx防爆破需确保日志含401/403状态码、路径用通配符、优先监控waf日志；sshd规则需调优findtime/maxretry/bantime并配置ignoreip；自定义filter正则须适配实际日志格式且添加ignoreregex，最后用fail2ban-regex验证。
宝塔面板里装 Fail2ban 防爆破，不用碰命令行也能搞定，但直接点“安装”就走人，大概率封不住攻击 IP——关键在规则是否匹配日志格式、防火墙后端是否对得上。
宝塔软件商店安装 Fail2ban 后必须检查的三件事
Fail2ban 插件在宝塔「软件商店」→「已安装」里出现，只代表服务进程跑起来了，不代表它真在干活：
-
systemctl status fail2ban必须显示active (running)，否则后续所有配置都无效 - 确认后台用的是
firewalld还是iptables：宝塔 7.8+ 默认用firewalld，但 Fail2ban 默认配置可能仍指向iptables，会导致banaction失效，IP 封不了 - 检查
/var/log/secure（CentOS/RHEL）或/var/log/auth.log（Debian/Ubuntu）是否存在且有 SSH 登录失败记录，否则[sshd]规则根本没日志可读
在宝塔界面设置 Nginx 防爆破规则时，logpath 容易填错
宝塔的 Fail2ban 插件界面允许你为 Nginx 站点添加自定义规则，但「日志路径」字段不能只写 /www/wwwlogs/xxx.log 就完事：
- Nginx 访问日志默认不记录状态码为
401或403的暴力尝试，得先在站点配置里加log_format显式记录，否则 Fail2ban 找不到匹配模式 - 宝塔生成的站点日志路径带日期后缀（如
xxx.log-20260409），而 Fail2ban 默认只监控当前文件名，需改用通配符路径：/www/wwwlogs/xxx.log* - 如果用了宝塔的「防CC」或「WAF」插件，真实请求可能被提前拦截，Nginx 日志里压根没记录，此时应监控 WAF 日志（路径类似
/www/server/panel/plugin/btwaf/logs/）而非 Nginx 原生日志
启用 sshd 规则后仍被扫，大概率是 findtime/maxretry 不匹配实际攻击节奏
宝塔界面勾选「SSH 暴力破解防护」后，底层仍是读取 /etc/fail2ban/jail.local 里的 [sshd] 段。常见失灵原因：
-
findtime = 600（10 分钟）太长：现在脚本攻击常在 30 秒内发完 5 次请求，maxretry = 5却卡在 10 分钟窗口，等于放行 -
bantime = 3600（1 小时）太短：攻击者换批 IP 继续扫，不如设成86400（24 小时）或-1（永久），尤其对高频扫描 IP - 没加白名单：
ignoreip里漏了你的办公公网 IP，一重启 Fail2ban 就把自己锁在外面，只能靠 VNC 或控制台硬进
自定义 filter 规则时，正则写错不会报错，但完全不触发
比如你想针对 WordPress 后台爆破（/wp-login.php），新建 filter 文件 /etc/fail2ban/filter.d/wp-login.conf，里面 failregex 写成：
failregex = ^<host> -.*"(POST|GET) /wp-login\.php</host>
这行看着像那么回事，但实际会失效，因为：
- Nginx 日志默认没有
-分隔符后的用户字段，<host> -.*</host>会匹配失败；正确写法是^<host>.*"(POST|GET) /wp-login\.php</host> - 没加
ignoreregex：正常用户刷新页面也会带wp-login.php，得排除HTTP/1.1" 200成功响应，否则自己登录都被封 - 测试正则是否生效不能只看界面提示，得手动跑：
fail2ban-regex /www/wwwlogs/your-site.log /etc/fail2ban/filter.d/wp-login.conf
真正难的不是写几行配置，而是确认日志里真有你要抓的那条记录、正则真能把它揪出来、防火墙真把 IP 加进了黑名单——这三个环节断一个，Fail2ban 就是摆设。
