Skip to content

Failed nginx config reload (bad upstream in one location) silently disables entire proxy host with no UI error #5853

Description

@pwedev

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:

  1. The UI shows a generic "saved" success toast, with no indication anything went wrong.
  2. 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.
  3. 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:

  1. Create a Proxy Host with 2+ custom locations, each pointing to a different upstream.
  2. 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).
  3. Save the host. UI shows "saved" with no warning.
  4. 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.
  5. 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/

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions