Removing a CrowdSec decision does not guarantee that the IP will remain unblocked. If the same client keeps generating matching access-log events, a trigger scenario can create a fresh decision seconds later. An ipset entry may also linger briefly while the firewall bouncer synchronizes its state.
Identify the source of the ban
cscli decisions list -a --ip 198.51.100.25
cscli alerts list -a
ipset test crowdsec-blacklists-0 198.51.100.25
The example uses a reserved documentation address. Check the decision’s source, reason, expiration and creation time. A local CrowdSec scenario may behave differently from a blocklist imported by a feed.
Remove a decision safely
cscli decisions delete --ip 198.51.100.25
cscli decisions list -a --ip 198.51.100.25
If cscli shows no decision but the IP is still in ipset, allow a short synchronization interval and check the bouncer logs. Do not flush the whole set or restart the firewall simply to remove one entry.
Fix repeat offenders at the right layer
For a legitimate service, add a precise parser whitelist based on verified IP or CIDR and activate it after crowdsec -t. For abusive clients, the re-ban may be correct, and you should leave the protection intact. Never whitelist a broad cloud hosting network just to prevent a handful of false positives.
Validate the whole pipeline
Run cscli explain using a real, sanitized Apache access-log line. It should show whether the event is discarded by a whitelist before reaching the scenario. Follow with cscli decisions list and an ipset membership check after the bouncer update cycle. A successful deletion is not sufficient evidence that the firewall no longer blocks the address.