NGINX-proxy-manager fails to start if one of the hosts are not found

[y0nei]

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

I have a some stuff routed through npm, today after a reboot, one of my containers failed to start and nginx proxy manager kept returning
nginx: [emerg] host not found in upstream "host name" in /data/nginx/proxy_host/11.conf:62

Nginx Proxy Manager Version

v2.9.18

To Reproduce
Steps to reproduce the behavior:

1. Reboot with a failing container
2. Done, nginx proxy manager freaks out and doesent let any access to the instance

Screenshot

Operating System

Rpi ARCH

Additional context

Docker: Docker version 20.10.21, build baeda1f82a
Browser: Firefox and Chromium (not browser issue)
Docker compose version: Docker Compose version 2.12.2

[the1ts]

The problem appears to me to be:

1. You are using the DNS from within docker, when a container is not running it will fail to lookup the host this is by design, hosts are added and removed from DNS on the fly as containers start and stop.
2. Also by design when nginx fails to lookup a backend (for example, a container that is down) it will refuse to start, rather than start with a known broken proxy.

The logic is that if the config is broken a human will look at the situation and fix, if it starts with a known broken proxy a human will have to notice that breakage and fix. So better fail quickly and get a fix. How can nginx know that the DNS failure is only temporary and decide to start and hope for a fix?

One way around this is to expose the container ports on to the host and use that IP:PORT in NPM. This would allow NPM to start since the backend will always lookup successfully but you are loosing one of the benefits of docker.

[y0nei]

The problem appears to me to be:

1. You are using the DNS from within docker, when a container is not running it will fail to lookup the host this is by design, hosts are added and removed from DNS on the fly as containers start and stop.

2. Also by design when nginx fails to lookup a backend (for example, a container that is down) it will refuse to start, rather than start with a known broken proxy.

The logic is that if the config is broken a human will look at the situation and fix, if it starts with a known broken proxy a human will have to notice that breakage and fix. So better fail quickly and get a fix. How can nginx know that the DNS failure is only temporary and decide to start and hope for a fix?

One way around this is to expose the container ports on to the host and use that IP:PORT in NPM. This would allow NPM to start since the backend will always lookup successfully but you are loosing one of the benefits of docker.

thanks for reply, now closing

[kabadisha]

@y0nei FYI, I raised a PR to fix/change this behaviour:
#2672

If you could take a look and maybe test my PR, that would be super :-)

Personally, I respectfully disagree with @the1ts. I believe that Nginx should start because it may be proxying multiple services and this behaviour takes out all services, even if only one is down. Nginx starting, but returning 502 errors for any down upstream host is a better solution. This is the behaviour after merging my PR.
Monitoring should be applied to check if the upstream service is actually up and functioning properly rather than just noticing that the entire Nginx proxy is down.