| IP | 场景 | 时间 |
|---|---|---|
| 198.51.100.13 | crowdsecurity/ssh-bf | 2026-10-12 11:14 |
| 198.51.100.22 | crowdsecurity/http-bad-user-agent | 2026-10-12 10:54 |
| 198.51.100.29 | crowdsecurity/nginx-req-limit-exceeded | 2026-10-12 10:27 |
| 198.51.100.13 | crowdsecurity/ssh-bf | 2026-10-12 10:33 |
| 198.51.100.35 | crowdsecurity/http-crawl-non_statics | 2026-10-12 09:17 |
| 198.51.100.12 | crowdsecurity/http-crawl-non_statics | 2026-10-12 06:57 |
| 198.51.100.17 | crowdsecurity/ssh-bf | 2026-10-12 10:36 |
| 198.51.100.20 | crowdsecurity/http-bad-user-agent | 2026-10-12 06:40 |
| 198.51.100.32 | crowdsecurity/nginx-req-limit-exceeded | 2026-10-12 04:50 |
| 198.51.100.29 | crowdsecurity/http-crawl-non_statics | 2026-10-12 04:14 |
| 198.51.100.26 | crowdsecurity/http-bad-user-agent | 2026-10-12 05:39 |
| 198.51.100.35 | crowdsecurity/ssh-bf | 2026-10-12 07:01 |
| 198.51.100.18 | crowdsecurity/http-probing | 2026-10-12 03:48 |
| 198.51.100.22 | crowdsecurity/http-bad-user-agent | 2026-10-12 02:25 |
| 198.51.100.34 | crowdsecurity/ssh-bf | 2026-10-12 04:13 |
| 198.51.100.14 | crowdsecurity/http-bad-user-agent | 2026-10-12 00:33 |
| 198.51.100.12 | crowdsecurity/http-bad-user-agent | 2026-10-11 21:38 |
| 198.51.100.18 | crowdsecurity/ssh-bf | 2026-10-12 01:08 |
| 198.51.100.25 | crowdsecurity/http-crawl-non_statics | 2026-10-12 01:17 |
| 198.51.100.18 | crowdsecurity/http-probing | 2026-10-12 00:40 |
CrowdSec 读你的日志，把它们与场景比对，然后判定某个地址应当被封。执行这项判定的得是另一样东西：那就是 bouncer，而正是这道分工头一回让几乎所有人都愣住。一个地址可以出现在 decisions 列表里，却依然能抵达你的服务器，因为并没有安装任何 bouncer 去执行它。
这一页把两半都展示出来：生效中的判定，连同触发它们的场景与剩余时间；以及登记在册、负责动手的 bouncer。若第二份列表是空的，CrowdSec 就只是一套告警系统，别的什么也不是。
该不该把 CrowdSec 与 Fail2ban 并排跑，是个正当的问题，答案多半是该。两者重叠却不冲突：Fail2ban 对已经发生在你机器上的事情作出反应，而 CrowdSec 还额外借助所有其他用户上报的地址，于是攻击者往往在抵达时就已经是熟面孔。另一处差别值得记下：CrowdSec 的官方控制台是托管服务，这一页不是，它只读取本地 API。