Webinterface fails to start when stream host is unavailable.

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.

Start with the generated stream configuration at /data/nginx/stream/x.conf and the startup log showing nginx validation failure, then trace the stream-host configuration generation and startup entry point. Verify behavior with a stream host whose target hostname is unavailable; done means the management web interface remains reachable without manual container-file edits while the host is down.