我用 docker 运行了 vaultwarden：
services:
vaultwarden:
image: vaultwarden/server:latest
container_name: vaultwarden
restart: always
ports:
- "127.0.0.1:8001:80"
volumes:
- ./:/data/
- /etc/localtime:/etc/localtime:ro
environment:
- LOG_FILE=/data/log/vaultwarden.log
然后用 Nginx 的反向代理 bitwarden.XXX.com 可以访问，套了 cloudflare CDN 。
配置 fail2ban 之后，测试了故意输入错误密码后，能 ban 到 IP：
Status for the jail: vaultwarden
|- Filter
| |- Currently failed: 1
| |- Total failed: 5
| `- File list: /home/Wi-Fi/Bitwarden/log/vaultwarden.log
`- Actions
|- Currently banned: 1
|- Total banned: 1
`- Banned IP list: 158.101.132.372
但是依然能访问，这是为什么？
services:
vaultwarden:
image: vaultwarden/server:latest
container_name: vaultwarden
restart: always
ports:
- "127.0.0.1:8001:80"
volumes:
- ./:/data/
- /etc/localtime:/etc/localtime:ro
environment:
- LOG_FILE=/data/log/vaultwarden.log
然后用 Nginx 的反向代理 bitwarden.XXX.com 可以访问，套了 cloudflare CDN 。
配置 fail2ban 之后，测试了故意输入错误密码后，能 ban 到 IP：
Status for the jail: vaultwarden
|- Filter
| |- Currently failed: 1
| |- Total failed: 5
| `- File list: /home/Wi-Fi/Bitwarden/log/vaultwarden.log
`- Actions
|- Currently banned: 1
|- Total banned: 1
`- Banned IP list: 158.101.132.372
但是依然能访问，这是为什么？
第 1 条附言 20 天前
发现 fail2ban 里自带就有 cloudflare 。通过 Global API Key ，
action = cloudflare
/etc/fail2ban/action.d/cloudflare.conf
cftoken = cloudflare 全局 key
cfuser = 你的邮箱
就 OK 了。
action = cloudflare
/etc/fail2ban/action.d/cloudflare.conf
cftoken = cloudflare 全局 key
cfuser = 你的邮箱
就 OK 了。
18 条回复 2025-09-26 10:57:05 +08:00
 | 1 billlee 27 天前 因为 fail2ban 默认调用的是系统防火墙，系统防火墙看到的 IP 都是 Cloudflare 服务器的 IP. |
 | 2 Nt6Z1g 27 天前 fail2ban 可以用 cloudflare 的模块调用 API 封 IP |
 | 套了 cloudflare ，ip 就会一直变吧，你 ban 的是 cloudflare 的 ip ，ban 了个寂寞 |
 | 4 KousukeSakurako 27 天前 via iPhone 试试自定义一下 ban action ，让它能把规则插到 DOCKER-USER 里 |
 | 5 xyfan 26 天前 你都说了套 CDN ，ban 来 ban 去，ban 的是衣服不是人 |
 | 6 julyclyde 26 天前 你这个 docker 是做了 NAT 吧 fail2ban 是在 INPUT 封的吧，你这个 NAT 是不经过 INPUT 的吧？ |
 | 7 yokisama 26 天前 不如在 cloudflare 的 WAF 直接屏蔽它的 ip 让 AI 写个脚本，读取 bw 的日志，加入到黑名单就好了 你只 ban 回源 ip 没用 |
 | 8 bingfengfeifei 26 天前 如果功能没问题的话，可能是当前的会话没断，阻断的仅仅是新建连接，当前的连接不会断。 我没用过这个不太清楚是不是这个原因，只是之前遇到过类似的问题，是这种原因导致。 |
 | 10 datocp 25 天前 via Android 当年测试防火墙似乎是默认 iptables -P INPUT ACCEPT |
 | 11 lifansama 25 天前 via Android 你的 banaction 是使用的哪一种？换成 iptables-allports 试试？ |
 | 12 elboble 24 天前 应该是 cdn 的问题 我用 nps 做穿透，内网机器即使开了 fail2ban ，看到的都是内网跳板机的 ip ，所以封了之后，自己也连不回去了。只能设 10 分钟的 block ，即使这样，照样有扫描，间隔 10 分钟尝试 5 次，然后 block ，最后只能把转发关了，需要再开。 |
 | 13 dode 20 天前 容器使用主机网络吧 |
| 14 dode 20 天前 docker 的网络默认不受 ufw 管理控制，网络控制这个来说，fedora 、centos 的 podman 真好哇 |
 | 15 leeshong27 13 天前  网站挂了老哥修一下 |
 | 16 CSGO OP  1 @leeshong27 你是用我的这个吗？！我才发现挂了。看了 AI 日志： 在 2025-09-25 18:42 左右，RustDesk 的服务端容器 (hbbs) 或其依赖模块因为版本 bug 或意外错误崩溃／被 systemd 停止。这个退出过程可能触发数据库 flush 、文件操作、日志关闭等写操作。此时如果底层磁盘、文件系统或 IO 子系统有隐患（如坏道、驱动错误、控制器异常），这些写操作可能被阻塞。随着操作被阻塞，系统调度、日志写入、进程响应等链条被牵连，导致系统进入一种半死锁或硬锁死状态，kernel 无法继续写日志、处理中断、切换进程。长达数分钟几乎无日志输出。直到某些中断 / IO 路径恢复或系统内部恢复能力部分重建时，才又能写出 UFW BLOCK 等日志，系统恢复部分响应能力。最终，你重新干预启动 /重启服务，系统恢复正常。 |
| 17 leeshong27 13 天前 @CSGO #16 对 用了好久了非常好用 |
| 18 CSGO OP @leeshong27 OK ，现在服务器用的 200Mbps |
Select Language