Fail2Ban本身不生成独立运行日志，关键行为记录在/var/log/fail2ban.log，其防护实效需结合防火墙规则变化与被封IP来源特征综合判断，核心是分析谁被封、为何被封、封得是否准确。
Fail2Ban 本身不生成独立的“运行日志”，它把关键行为记录在系统日志里（通常是 /var/log/fail2ban.log），而真正的策略效果，得靠分析它触发封禁时留下的痕迹——也就是防火墙规则变化 + 被封 IP 的来源特征。优化防火墙策略，核心不是调参数，而是看“谁被封了、为什么被封、封得对不对”。
直接看 fail2ban.log 判断封禁逻辑是否合理
这个文件记录了每次 ban/unban 动作的完整上下文：时间、IP、触发的 jail、匹配的日志行、使用的 filter 和 action。
- 如果某 IP 被反复封禁又解封（短时间内多次
Ban→Unban），说明bantime太短，或findtime/maxretry设置过于宽松； - 如果大量不同 IP 集中来自同一 ASN 或地理区域（比如俄罗斯、越南的 /24 网段），可考虑在 iptables/nftables 层面加一条前置 DROP 规则，减轻 Fail2Ban 日志解析压力；
- 出现
No file(s) found for: /var/log/nginx/error.log类错误，说明 logpath 配置错位，防火墙规则根本没机会生效。
结合 iptables -L -n -v 或 nft list ruleset 查封禁实效
Fail2Ban 最终靠写入防火墙链（如 f2b-sshd）起作用。光看日志不够，得确认规则真正在生效：
- 每条 f2b-xxx 链里应有
DROP规则，且 packet 计数器在增长，说明拦截真实发生； - 若计数器为 0，可能是：日志路径没权限读取、filter 正则漏匹配、action 指向了错误的 chain 名；
- 注意 chain 是否被其他规则跳过（比如在 INPUT 链顶部就
ACCEPT了 RELATED/ESTABLISHED，但没给 f2b-chain 留执行位置）。
用日志反推 filter 规则是否精准
打开 /var/log/fail2ban.log，找一行类似：
2026-06-14 09:22:17,123 fail2ban.filter [12345]: INFO [nginx-http-auth] Found 203.0.113.45 - 2026-06-14 09:22:16
然后去 /var/log/nginx/error.log 里搜这个 IP 和时间前后几秒的记录，看它到底干了什么：
- 是连续 10 次
/wp-login.phpPOST？该加强nginx-http-auth的maxretry； - 还是单次
404加一次401就触发？说明 filter 正则太宽，需收紧（比如只匹配带user authentication failed且含admin路径的行）； - 如果发现合法爬虫（如 Googlebot）也被误封，可在 filter 中排除
User-Agent特征。
根据高频攻击模式动态调整 jail 策略
别只盯着默认的 sshd 和 nginx-http-auth。从日志里统计 top 被封 IP 的请求路径、状态码、User-Agent：
- 若
403出现频次远高于404，说明有人在扫敏感目录（.git、/backup），可新建一个 jail 专盯nginx-botsearch； - 若
POST /xmlrpc.php错误暴增，对应 WordPress 暴力刷接口，启用apache-badbotsfilter 或自定义一条； - 发现大量
Invalid user xxx from yyy.zzz，但sshdjail 没响应，可能是日志格式变了（比如 systemd-journald 输出），需更新logpath为journalctl -u sshd --no-pager -o short-iso。
不复杂但容易忽略
