Webinterface fails to start when stream host is unavailable.

[david-d-white]

Checklist

• Have you pulled and found the error with jc21/nginx-proxy-manager:latest docker image?
  • Yes
• Are you sure you're not using someone else's docker image?
  • Yes
• Have you searched for similar issues (both open and closed)?
  • Yes

Describe the bug

Configuring stream hosts on NPM by hostname prevents startup while repeatedly reporting: host not found in upstream "<hostname>".

Nginx Proxy Manager Version

v2.10.4

To Reproduce Steps to reproduce the behavior:

1. Add a stream host to nginx proxy manager. Refer to the stream host by container name.
2. Start nginx proxy manager when the stream host is down.
3. NPM fails to start, and web interface is unreachable.

Expected behavior

NPM management interface should still be reachable when a stream host is unavailable. Currently the container files need to be edited/removed manually if there is a typo in the hostname, or otherwise a host must be made available with that name for NPM to start.

Additional context

NPM repeatedly reports the following log messages while failing to start:

" nginx-proxy-manager  | ❯ Starting nginx ...
nginx-proxy-manager  | nginx: [emerg] host not found in upstream "<hostname>" in /data/nginx/stream/x.conf:11"

The problem seems similar to issue https://github.com/NginxProxyManager/nginx-proxy-manager/issues/633

server {
  listen 2200;
listen [::]:2200;


  proxy_pass <hostname>:<port>;

  # Custom
  include /data/nginx/custom/server_stream[.]conf;
  include /data/nginx/custom/server_stream_tcp[.]conf;
}

The generated nginx config file seems to follow the format above. It looks like the hostname is used directly in the proxy_pass directive which causes nginx to fail when it can't find the host. I imagine changing the behaviour to first store the hostname in a variable and use that veriable in the proxy_pass directive would circumvent this issue like it does in the generated configs for for the proxy hosts.

If possible it would also be good if the NPM would first serve it's own web interface first before attempting to serve any of the configured hosts, to prevent issues like this from requiring command line intervention, or diving into the dockerfiles of the NPM container. I'm not sure how feasible this would be though since I have not looked at the code at all.

[gigaion]

Ran across this also. Glad to see an issue is already open for it.

[guilhermeluciano3]

+1

[github-actions[bot]]

Issue is now considered stale. If you want to keep it open, please comment :+1:

[nfriedly]

:+1:

[danierukun]

:+1:

[gavinc]

#3970 is the same issue (and, I favor, this IS an issue. If you enjoy making docker services come and go at whim, NPM now has you on a leash. Better tell NPM before you shut down that service for a bit.)

[Dominic-Preap]

This is a huge issue for us, as we are using Portainer to stop the container, reboot the server just to add more HDD space. After it restarts, we can't go to Portainer to start the container as NPM is stuck on an error upstream of that container. And now every containers we're hosting are all down.

[github-actions[bot]]

Issue is now considered stale. If you want to keep it open, please comment :+1:

[Dominic-Preap]

There you go

[nfriedly]

:+1:

[fireinice]

why we just unlink the failed conf and show some alert on ui? since we can get the failed conf from nginx -t.