I had AI help me with this bug report to try and use proper terminology. Below it says "has no User-Agent" which is not how I would have described the situation, so hopefully it's correct.
Godoxy v0.31.1
File based route
Dashboard-triggered health check bypasses middleware pipeline, sends malformed request that breaks strict backends (e.g. Home Assistant)
Opening the GoDoxy WebUI dashboard causes a periodic (~15s) request to be sent directly to at least one of my upstreams (Home Assistant) that:
Bypasses the route's configured middlewares entirely
Results in the backend rejecting the request with a 400
Maybe a different code path than normal reverse-proxied traffic to the same route?
This is separate from the documented per-route healthcheck scheduled monitor — toggling healthcheck.disable between true and false has no effect on this behavior either way. The problem only occurs while the GoDoxy dashboard is open in a browser, and stops within seconds of closing it.
Steps to reproduce
-
Configure a route pointing at a backend that validates the X-Forwarded-For header strictly (Home Assistant's http integration is a good example — it calls Python's ipaddress.ip_address() on each entry and throws if any entry is empty or malformed).
-
Add a modify_request middleware on that route that unconditionally overwrites X-Forwarded-For:
homeassist.domain.com:
scheme: http
host: 192.168.20.185
healthcheck:
use_get: true
disable: true
interval: 30s
timeout: 15s
middlewares:
modify_request:
set_headers:
X-Forwarded-For: $remote_host
port: 8123
- Open the GoDoxy WebUI
- Watch the backend's access log.
With the dashboard open, the backend receives two distinct request patterns roughly every 15 seconds, from GoDoxy's own host IP (192.168.20.60 in my setup):
192.168.20.60 [05/Sep/2026:09:13:30 -0500] "GET / HTTP/1.1" 200 7700 "-" "GoDoxy/v0.31.1"
192.168.20.60 [05/Sep/2026:09:13:32 -0500] "GET / HTTP/1.1" 400 178 "-" "-"
The first line (GoDoxy/v0.31.1 user-agent, 200 response) looks like the normal/expected reverse-proxy or healthcheck request.
The second line has no User-Agent at all, and the backend returns 400 because the request arrives with an empty X-Forwarded-For value.
Home Assistant's log shows the corresponding error at the same timestamp:
2026-09-05 09:13:32.329 ERROR (MainThread) [homeassistant.components.http.forwarded] Invalid IP address in X-Forwarded-For:
The modify_request / set_headers middleware configured on the route (see config above) has no effect on this second request pattern, confirming it does not go through the route's middleware chain.
Toggling healthcheck.disable between true and false also has no effect — the errors occur identically either way, only correlating with whether the GoDoxy dashboard GUI is open.
I initially suspected this was the documented per-route healthcheck monitor (which I understand runs on its own configurable interval, separate from the proxy pipeline, per the health-monitoring docs) — but the ~15s cadence didn't match my configured 30s interval, and disabling healthcheck.disable entirely didn't stop it. It only starts/stops in direct correlation with the GoDoxy UI being open.
I had AI help me with this bug report to try and use proper terminology. Below it says "has no User-Agent" which is not how I would have described the situation, so hopefully it's correct.
Godoxy v0.31.1
File based route
Dashboard-triggered health check bypasses middleware pipeline, sends malformed request that breaks strict backends (e.g. Home Assistant)
Opening the GoDoxy WebUI dashboard causes a periodic (~15s) request to be sent directly to at least one of my upstreams (Home Assistant) that:
Bypasses the route's configured middlewares entirely
Results in the backend rejecting the request with a 400
Maybe a different code path than normal reverse-proxied traffic to the same route?
This is separate from the documented per-route healthcheck scheduled monitor — toggling healthcheck.disable between true and false has no effect on this behavior either way. The problem only occurs while the GoDoxy dashboard is open in a browser, and stops within seconds of closing it.
Steps to reproduce
Configure a route pointing at a backend that validates the X-Forwarded-For header strictly (Home Assistant's http integration is a good example — it calls Python's ipaddress.ip_address() on each entry and throws if any entry is empty or malformed).
Add a modify_request middleware on that route that unconditionally overwrites X-Forwarded-For:
With the dashboard open, the backend receives two distinct request patterns roughly every 15 seconds, from GoDoxy's own host IP (192.168.20.60 in my setup):
The first line (GoDoxy/v0.31.1 user-agent, 200 response) looks like the normal/expected reverse-proxy or healthcheck request.
The second line has no User-Agent at all, and the backend returns 400 because the request arrives with an empty X-Forwarded-For value.
Home Assistant's log shows the corresponding error at the same timestamp:
2026-09-05 09:13:32.329 ERROR (MainThread) [homeassistant.components.http.forwarded] Invalid IP address in X-Forwarded-For:The modify_request / set_headers middleware configured on the route (see config above) has no effect on this second request pattern, confirming it does not go through the route's middleware chain.
Toggling healthcheck.disable between true and false also has no effect — the errors occur identically either way, only correlating with whether the GoDoxy dashboard GUI is open.
I initially suspected this was the documented per-route healthcheck monitor (which I understand runs on its own configurable interval, separate from the proxy pipeline, per the health-monitoring docs) — but the ~15s cadence didn't match my configured 30s interval, and disabling healthcheck.disable entirely didn't stop it. It only starts/stops in direct correlation with the GoDoxy UI being open.