[BUG] Regression in 1.6.10rc4 when rewriting 404 error pages (and others?)

[jojolll]

What happened?

When BunkerWeb rewrites an error page (tested only with 404), the page that should be served appears to be looked up from the wrong location and is no longer found.

This is very easy to reproduce from the BunkerWeb UI if the UI is not mounted on / and instead uses a URI suffix/path. Bad URI = 404.

It also happens when the 404 is caught from the reverse proxy.

How to reproduce?

There is no issue with version 1.6.10rc3, but after upgrading to 1.6.10rc4 the problem appears.
Rolling back to 1.6.10rc3 fixes the issue.
Upgrading again to 1.6.10rc4 causes it again.

Configuration file(s) (yaml or .env)

N/A

Relevant log output

2026/04/30 22:53:31 [error] 5975#5975: *551 open() "/nowhere/home" failed (2: No such file or directory), client: 192.0.2.10, server: example.invalid, request: "GET /home HTTP/2.0", host: "example.invalid"

Client side : always ERR_HTTP2_PROTOCOL_ERROR
BW side with reverse proxy intecepted error : None

BunkerWeb version

1.6.10rc4

What integration are you using?

Linux

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

[satt105]

I dug into this, the issue comes from commit 7ebef92f8 (#3448), which touches errors.conf and default-server-http/errors.conf.
When DENY_HTTP_STATUS=444, the @bwerror* handlers unconditionally issue a return 444, regardless of which error code triggered them. So any real error (a 404 on a missing file, a 502 from upstream) drops the TCP connection instead of serving an HTML page. That's where the ERR_HTTP2_PROTOCOL_ERROR comes from.
Except these handlers have nothing to do with the deny logic. Requests blocked by BunkerWeb go through ngx.exit(444) in the Lua access phase (access-lua.conf:85), which completely bypasses error_page, so @bwerror* is never invoked for that. These handlers only fire for real nginx errors. Putting a return 444 in them doesn't change anything for the deny case, but breaks error rendering for legitimate errors.
Regarding the open() "/nowhere/home" in the logs: unrelated. That's just nginx trying to serve a file with root /nowhere; (serve-files.conf:5, active when SERVE_FILES != yes) before triggering error_page. Expected behavior, harmless.
I've opened a PR to fix this.

[TheophileDiot]

Hi @jojolll @satt105 indeed you're right, I'm investigating it.

[TheophileDiot]

I'm also looking at the branding leak

[TheophileDiot]

Hi @Defy3738 — update: the rc4 fix introduced a regression on legitimate intercepted errors (#3490), so it's reverted on dev for rc5. Branded default page stays as-is on OSS.

For full stealth on the error pages, two paths:

OSS — override error.html directly. The branded template lives at /usr/share/bunkerweb/core/errors/files/error.html inside the BunkerWeb container (or on the host for Linux installs). Replace it with your own HTML — fully blank, generic, or rebranded. It's rendered by lua-resty-template and receives: error_code, error_title, error_text, error_solution, error_type, title, request_id, client_ip, request_time, plus nonce_script / nonce_style for the CSP. Use them or ignore them.

Mount example (Docker / docker-compose):

services:
  bunkerweb:
    volumes:
      - ./my-error.html:/usr/share/bunkerweb/core/errors/files/error.html:ro

On Linux installs, edit the file in place — note that a package upgrade will overwrite it, so keep a backup or ship the override via your config-management of choice. Lighter-weight escape hatches if you don't need a custom template at all: INTERCEPTED_ERROR_CODES="" (nginx generic defaults, no branding) or ERRORS="400=/path/to/blank.html 404=/path/to/blank.html …" (per-code mapping to your own files).

PRO — Custom Pages plugin. Same end result through the Web UI, per-service, no volume gymnastics — replaces the built-in error / default-server / antibot pages with your own HTML or Lua templates managed from the dashboard. Recommended path if you're maintaining several services or don't want to ship the override through your deployment pipeline.

[Defy3738]

@TheophileDiot that's totally understandable, thanks for the explanation. Just so I understand it, is it intended behavior for return code 400 to be served sometimes even if DENY_HTTP_STATUS=444 and the request increments bad_behavior?

I have seen a lot of bot traffic (10k+ IPs banned), and basically when there is "bad" traffic (where $host is not FQDN but is instead either the IPv4 or _), 444 is returned as configured, except when the $request is for GET /bwerror400 - specifically, which results in 400 being returned. For example, see below logs where LOG_FORMAT=($status) $remote_addr | ($remote_user) $host | $request_method $uri$args_sanitized $server_protocol ($body_bytes_sent) | $http_user_agent | $http_referer:

(444) 87.236.176.88 | (-) nonexistent_subdomain.[REDACTED_FQDN] | GET / HTTP/1.1 (0) | Mozilla/5.0 (compatible; InternetMeasurement/1.0; +https://internet-measurement.com/) | -
(400) 87.236.176.76 | (-) _ | GET /bwerror400 - (0) | - | -

Unfortunately commit 7ebef92f8 did not change this when I tested rc4 so I definitely agree that the revert is warranted. I did try your suggestions to set INTERCEPTED_ERROR_CODES="" and/or setting a custom error page. On all my attempts I continue to see 400 being returned on GET /bwerror400. Is there any way I can get these requests to return 444?

Another way of looking at it: if I set BLACKLIST_URI=^/.+ and DENY_HTTP_STATUS=444, I would think all requests get denied with 444, and this does happen except when the request is specifically for /bwerror400.

If it is intended behavior then I understand. Admittedly I may be overly paranoid. Can you think of any work around for this? Thanks for your time!

[jojolll]

Hi @TheophileDiot,

It is fixed in 1.6.10rc5, thanks 💯

[Defy3738]

@TheophileDiot I did some testing and found out that even though the logs show GET /bwerror400 it does not mean the original request was for that... For example curl -H "Host:" example.com will produce the log output in question. Hope this helps narrow down on the solution.