fail2ban启动报connectionrefusederror是因为默认尝试连接未启用的8080 socket；需检查systemctl status fail2ban、禁用systemd backend、改用auto或polling，并确认日志路径与后端匹配。
fail2ban 为什么一装就报 ConnectionRefusedError
因为默认配置里 fail2ban-server 尝试连 127.0.0.1:8080 的 socket，但实际没开 Web API。这不是 bug，是它默认启用 systemd socket 激活，而你没启动对应服务。
- 先确认是否真在跑：
systemctl status fail2ban，不是fail2ban-server - 删掉
/etc/fail2ban/jail.local里所有带backend = systemd或socket的行 - 改用
backend = auto或明确写backend = polling（尤其日志在 NFS 或容器里时） -
journalctl -u fail2ban -n 50看真实报错，别只信启动失败提示
sshd 日志路径不对导致 fail2ban 不拉黑
新版 OpenSSH 默认把日志发给 journald，而 fail2ban 默认只扫 /var/log/auth.log 或 /var/log/secure —— 这俩文件可能根本没 ssh 登录记录。
- 查 ssh 实际输出位置：
sudo journalctl _COMM=sshd --no-pager -n 20 - 如果确实走 journald，就别配
logpath = /var/log/secure，改用backend = systemd并确保Filter = sshd对应的journalmatch正确 - 或者强制 ssh 写文件：在
/etc/ssh/sshd_config加SyslogFacility AUTH，再改/etc/rsyslog.conf确保auth.*落盘 - 验证日志是否可读：
sudo -u root tail -n 20 /var/log/secure，fail2ban 是以root或fail2ban用户身份读的
fail2ban 拉黑了但 iptables 规则不生效
常见原因是系统用了 nftables 后向兼容层没开，或 iptables 命令被 alias 成 nft，导致 fail2ban 调用失败却静默忽略。
- 运行
sudo iptables -L -n | head -5，如果报command not found或输出是 nft 格式，说明底层已切到 nftables - 检查
/etc/fail2ban/jail.local是否设了banaction = iptables—— 在 nftables 系统上得换成banaction = nftables - 确认
nft list ruleset里有没有fail2ban-开头的 chain；没有的话可能是action.d/nftables.conf里的chain = input写错了，应为chain = input或chain = forward，取决于你的 ssh 端口监听方式 - 临时测试：手动加一条
sudo nft add rule ip filter input tcp dport 22 ip saddr 192.168.1.100 drop，看是否立刻断连
用 ufw 配合 fail2ban 容易漏掉 IPv6 或状态连接
ufw 默认只管 IPv4，且对 RELATED,ESTABLISHED 放行太宽，fail2ban 拉黑后旧连接仍通，攻击者能靠长连接绕过。
- 开 IPv6：
sudo ufw enable之前先确认/etc/default/ufw里IPV6=yes - fail2ban 的
banaction别直接设成ufw，它不支持动态端口和自定义链，建议用nftables+ 手动同步规则 - ufw 的默认策略是
deny incoming，但 fail2ban 的 ban 规则优先级低于 ufw 的 allow 规则 —— 所以必须让 fail2ban 插入到 ufw chain 的最前面，靠before.rules或nft实现 - 真正要防暴力破解，
MaxAuthTries 3和LoginGraceTime 30这类 sshd 内置限制比外挂工具更早生效、更省资源
真正的难点不在装工具，而在确认每层日志流向、每条规则实际生效位置、每个用户权限是否匹配 —— 少查一步 journalctl，就可能以为“拉黑了”，其实什么都没发生。