Description:
When a Proxy Host has multiple custom locations, and even one of them points to an unresolvable upstream (e.g. a stopped/renamed docker container), nginx's config test fails for the whole generated file — which is expected, since nginx validates the file as a unit. The problem is what happens next:
- The UI shows a generic "saved" success toast, with no indication anything went wrong.
- The failed nginx reload is logged, but only into the
meta.nginx_err JSON field in the SQLite proxy_host table — it never surfaces in the UI, and it does not appear in docker logs in an obviously flagged way.
- Because the reload failed, NPM never writes/updates the actual conf file in
/data/nginx/proxy_host/. This means the entire host — including all its other, perfectly healthy locations — silently stops resolving, with clients seeing a raw TLS unrecognized name alert (from NPM's default ssl_reject_handshake catch-all) rather than any indication of what broke.
Steps to reproduce:
- Create a Proxy Host with 2+ custom
locations, each pointing to a different upstream.
- Make one location's
forward_host point to a docker hostname that isn't currently resolvable (container stopped, renamed, or not on the same network).
- Save the host. UI shows "saved" with no warning.
- Observe:
/data/nginx/proxy_host/<id>.conf is not created/updated, and all locations on that host — including the working ones — fail with a TLS SNI rejection, not just the broken location.
- The actual error (
nginx: [emerg] host not found in upstream "...") is only discoverable by querying the SQLite proxy_host.meta column directly
Expected behavior:
- The UI should surface the nginx config test failure at save time (e.g. a toast/banner with the actual
nginx -t error), instead of reporting success.
- Ideally, a single bad
location upstream shouldn't be able to take down the whole host — though I guess this may be inherent to how nginx validates config files as a unit
Environment:
jc21/nginx-proxy-manager:latest (docker)
- config generation to
/data/nginx/proxy_host/
Description:
When a Proxy Host has multiple custom
locations, and even one of them points to an unresolvable upstream (e.g. a stopped/renamed docker container), nginx's config test fails for the whole generated file — which is expected, since nginx validates the file as a unit. The problem is what happens next:meta.nginx_errJSON field in the SQLiteproxy_hosttable — it never surfaces in the UI, and it does not appear indocker logsin an obviously flagged way./data/nginx/proxy_host/. This means the entire host — including all its other, perfectly healthy locations — silently stops resolving, with clients seeing a raw TLSunrecognized namealert (from NPM's defaultssl_reject_handshakecatch-all) rather than any indication of what broke.Steps to reproduce:
locations, each pointing to a different upstream.forward_hostpoint to a docker hostname that isn't currently resolvable (container stopped, renamed, or not on the same network)./data/nginx/proxy_host/<id>.confis not created/updated, and all locations on that host — including the working ones — fail with a TLS SNI rejection, not just the broken location.nginx: [emerg] host not found in upstream "...") is only discoverable by querying the SQLiteproxy_host.metacolumn directlyExpected behavior:
nginx -terror), instead of reporting success.locationupstream shouldn't be able to take down the whole host — though I guess this may be inherent to how nginx validates config files as a unitEnvironment:
jc21/nginx-proxy-manager:latest(docker)/data/nginx/proxy_host/