[BUG] Some banned IP requests are processed instead of rejected

[Defy3738]

What happened?

Hello, I have set up an automation to ban certain type of requests which over time has generated a few thousand IPs to be permanently banned. I have just noticed that a request from a banned IP was processed by the server instead of being closed with a 444 response as configured. I use Redis and PostgreSQL. Please let me know if I can provide more information. Thanks!

Bunkerweb log output:

2026/02/05 [warn] 493#493: *66958 using uninitialized "ctx_ref" variable while logging request, client: 43.164.197.177, server: _, request: "GET / HTTP/1.1", host: "REDACTED_SERVER_IPV4:443"
2026/02/05 [warn] 493#493: *66958 using uninitialized "is_whitelisted" variable while logging request, client: 43.164.197.177, server: _, request: "GET / HTTP/1.1", host: "REDACTED_SERVER_IPV4:443"
[warn] 493#493: *66958 using uninitialized "reason" variable while logging request, client: 43.164.197.177, server: _, request: "GET / HTTP/1.1", host: "REDACTED_SERVER_IPV4:443"
(400) 43.164.197.177 | (-) REDACTED_SERVER_IPV4 | GET / HTTP/1.1 (248) | "-" Mozilla/5.0 (iPhone; CPU iPhone OS 13_2_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.3 Mobile/15E148 Safari/604.1
2026/02/05 [notice] 493#493: *66962 [BADBEHAVIOR] increased counter for IP 43.164.197.177 (1/10) on server _ (status 400, scope global), context: ngx.timer

Ban information:

podman exec bunkerweb-scheduler bwcli bans 2>&1 | rg -A 3 43.164.197.177
#  🔒 43.164.197.177 [BR]
#     ⏱ Banned on 2025-12-21 at 13:39:17 permanent
#     ℹ️ Reason: manual
#  · · · · · · · · · · · · · · · · · · · · · · ·

How to reproduce?

I am not entirely sure how to reproduce this. It may have something to do with the fact that the request was made to the IPv4 directly as opposed to FQDN, but I am not sure.

Configuration file(s) (yaml or .env)

Relevant log output

BunkerWeb version

1.6.7

What integration are you using?

Docker

Linux distribution (if applicable)

No response

Removed private data

• I have removed all private data from the configuration file and the logs

Code of Conduct

• I agree to follow this project's Code of Conduct

[TheophileDiot]

Hi @Defy3738, this is likely because the 400 status code was triggered before the 444 one. Thank you for reporting this.

[jojolll]

Hi @Defy3738, this is likely because the 400 status code was triggered before the 444 one. Thank you for reporting this.

Hi @TheophileDiot, Where can we find the codes processed before 444? Could it be related to #3107 where the status code is 111?

[TheophileDiot]

Hi @jojolll, indeed the issue can remain the same with 111. The problem is that with the 400 status code a few nginx phases are skipped depending on which one triggered it (it can be very early), therefor the ban isn't being checked as it is in the access phase.
Here's a schema for you to see the different phases: https://openresty-reference.readthedocs.io/en/latest/Directives/

[TheophileDiot]

Just as an FYI, a 400 status code doesn't mean that the request as been processed as it was dropped earlier than the phase where we check the ban status.

[Defy3738]

Oh I see, thanks for the clarification @TheophileDiot. Does that then mean the last log line about BADBEHAVIOR counter can just be ignored safely since the IP was already banned?