kerem commented

Owner

Originally created by @pecqueurS on GitHub (Jan 26, 2022).
Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/1807

Is your feature request related to a problem? Please describe.
When the proxy_host is used to proxy a docker container and this container is shut down afterwards, if you restart nginx-proxy-manager, it generates an error because the domain no longer exists. Nginx-proxy-manager can no longer launch.

Describe the solution you'd like
Modify the proxy pass option in nginx
actual :
proxy_pass http://:/;
proposal :

No stop when error on config

https://stackoverflow.com/questions/32845674/setup-nginx-not-to-crash-if-host-in-upstream-is-not-found/32846603#32846603

https://stackoverflow.com/questions/35744650/docker-network-nginx-resolver/37656784#37656784

resolver 127.0.0.11 valid=30s ipv6=off;
set $upstream_pass http://:/;
proxy_pass $upstream_pass;

Describe alternatives you've considered
Easier access to proxy_host configuration when nginx-proxy-manager is off to remove non-working configuration

Additional context
error when nginx-proxy-manager is restarted :
host not found in upstream "bar:3000" in /data/nginx/proxy_host/1.conf

Originally created by @pecqueurS on GitHub (Jan 26, 2022). Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/1807 **Is your feature request related to a problem? Please describe.** When the proxy_host is used to proxy a docker container and this container is shut down afterwards, if you restart nginx-proxy-manager, it generates an error because the domain no longer exists. Nginx-proxy-manager can no longer launch. **Describe the solution you'd like** Modify the proxy pass option in nginx actual : proxy_pass http://<domain>:<port>/; proposal : # No stop when error on config # https://stackoverflow.com/questions/32845674/setup-nginx-not-to-crash-if-host-in-upstream-is-not-found/32846603#32846603 # https://stackoverflow.com/questions/35744650/docker-network-nginx-resolver/37656784#37656784 resolver 127.0.0.11 valid=30s ipv6=off; set $upstream_pass http://<domain>:<port>/; proxy_pass $upstream_pass; **Describe alternatives you've considered** Easier access to proxy_host configuration when nginx-proxy-manager is off to remove non-working configuration **Additional context** error when nginx-proxy-manager is restarted : host not found in upstream "bar:3000" in /data/nginx/proxy_host/1.conf

kerem added the

enhancement

label

2026-02-26 07:30:33 +03:00

kerem commented

2026-02-26 07:30:33 +03:00

Author

Owner

@kabadisha commented on GitHub (Mar 19, 2023):

I also had this problem. I've raised a PR which I believe fixes the issue:
https://github.com/NginxProxyManager/nginx-proxy-manager/pull/2672
If you can test my fix, that would be really helpful.

@kabadisha commented on GitHub (Mar 19, 2023): I also had this problem. I've raised a PR which I believe fixes the issue: https://github.com/NginxProxyManager/nginx-proxy-manager/pull/2672 If you can test my fix, that would be really helpful.

kerem commented

2026-02-26 07:30:33 +03:00

Author

Owner

@github-actions[bot] commented on GitHub (Feb 25, 2024):

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

@github-actions[bot] commented on GitHub (Feb 25, 2024): Issue is now considered stale. If you want to keep it open, please comment :+1:

kerem commented

2026-02-26 07:30:33 +03:00

Author

Owner

@Scemist commented on GitHub (May 3, 2024):

Same problem here, it doesn't make sense to fail the Nginx server for one proxy pass, since you can use it as an proxy for multiples addresses. So if some of websites fails, all the others will too.

@Scemist commented on GitHub (May 3, 2024): Same problem here, it doesn't make sense to fail the Nginx server for one proxy pass, since you can use it as an proxy for multiples addresses. So if some of websites fails, all the others will too.

kerem commented

2026-02-26 07:30:33 +03:00

Author

Owner

@Lavshyak commented on GitHub (Jun 8, 2024):

location /foo/ {
        resolver 127.0.0.11; #(in my case with docker)
        set $upstream_server someserver:80;
        proxy_pass http://$upstream_server/;
}

now nginx don't crashes when someserver:80 is down

Upd: but then nginx cut off the rest of the request uri. http://host/foo/bar becomes just http://someserver:80/. How to fix this?

@Lavshyak commented on GitHub (Jun 8, 2024): ``` location /foo/ { resolver 127.0.0.11; #(in my case with docker) set $upstream_server someserver:80; proxy_pass http://$upstream_server/; } ``` now nginx don't crashes when someserver:80 is down Upd: but then nginx cut off the rest of the request uri. http://host/foo/bar becomes just http://someserver:80/. How to fix this?

kerem commented

2026-02-26 07:30:33 +03:00

Author

Owner

@tyyrok commented on GitHub (Jul 15, 2024):

location /foo/ {
        resolver 127.0.0.11; #(in my case with docker)
        set $upstream_server someserver:80;
        proxy_pass http://$upstream_server/;
}
now nginx don't crashes when someserver:80 is down

Upd: but then nginx cut off the rest of the request uri. http://host/foo/bar becomes just http://someserver:80/. How to fix this?

Hi. Look at this article:

https://dev.to/danielkun/nginx-everything-about-proxypass-2ona#let-nginx-start-even-when-not-all-upstream-hosts-are-available

@tyyrok commented on GitHub (Jul 15, 2024): > ``` > location /foo/ { > resolver 127.0.0.11; #(in my case with docker) > set $upstream_server someserver:80; > proxy_pass http://$upstream_server/; > } > ``` > > now nginx don't crashes when someserver:80 is down > > Upd: but then nginx cut off the rest of the request uri. http://host/foo/bar becomes just http://someserver:80/. How to fix this? Hi. Look at this article: https://dev.to/danielkun/nginx-everything-about-proxypass-2ona#let-nginx-start-even-when-not-all-upstream-hosts-are-available

kerem commented

2026-02-26 07:30:33 +03:00

Author

Owner

@Lavshyak commented on GitHub (Aug 7, 2024):

nginx:mainline-alpine3.18-perl works well for me. I don't notice any failures

@Lavshyak commented on GitHub (Aug 7, 2024): nginx:mainline-alpine3.18-perl works well for me. I don't notice any failures

kerem commented

2026-02-26 07:30:33 +03:00

Author

Owner

@ZandercraftGames commented on GitHub (Jan 7, 2025):

Also having the same issue here. Quite frustrating to get working.

@ZandercraftGames commented on GitHub (Jan 7, 2025): Also having the same issue here. Quite frustrating to get working.

kerem commented

2026-02-26 07:30:33 +03:00

Author

Owner

@abstract-entity commented on GitHub (Mar 10, 2025):

got the same with latest nginx docker image

@abstract-entity commented on GitHub (Mar 10, 2025): got the same with latest nginx docker image

kerem commented

2026-02-26 07:30:33 +03:00

Author

Owner

@Legendary4226 commented on GitHub (Aug 14, 2025):

In the same annoying situation, like I build a container for Docker and Podman. Depending on the network subnet and the container engine, I can't guess the resolver IP.
I'm just blocked because there is no options. Should be good to define the resolver directive with a default value (for example "host") that preserve the default behavior (auto resolve with /etc/resolv.conf) and also activate the other wanted behavior that is the main subject of this issue.

I will just switch from NGINX to anything else more flexible, like who likes to have nothing working because of a little bit of dust in some config file ?

@Legendary4226 commented on GitHub (Aug 14, 2025): In the same annoying situation, like I build a container for Docker and Podman. Depending on the network subnet and the container engine, I can't guess the resolver IP. I'm just blocked because there is no options. Should be good to define the resolver directive with a default value (for example "host") that preserve the default behavior (auto resolve with /etc/resolv.conf) and also activate the other wanted behavior that is the main subject of this issue. I will just switch from NGINX to anything else more flexible, like who likes to have nothing working because of a little bit of dust in some config file ?

kerem commented

2026-02-26 07:30:33 +03:00

Author

Owner

@yn-alex commented on GitHub (Aug 29, 2025):

Man.. this is a super annoying and totally unnecessary “feature”.
If the backend is dead just let it be dead, and use that http 500 code to tell us.

What is the difference between not starting nginx because the backend is dead and killing it if the backend dies 1 second after nginx goes up?

You would not kill the proxy if the pleb backend is acting up, and nobody does it. But you don’t allow it to start because of the same issue. There is simply no practical and technical reason to not allow the process to start because of this.

We run nginx with over 50 custom locations across multiple services. And it simply won’t start if one is dead or missconfigured (like typing the wrong port there).

@yn-alex commented on GitHub (Aug 29, 2025): Man.. this is a super annoying and totally unnecessary “feature”. If the backend is dead just let it be dead, and use that http 500 code to tell us. What is the difference between not starting nginx because the backend is dead and killing it if the backend dies 1 second after nginx goes up? You would not kill the proxy if the pleb backend is acting up, and nobody does it. But you don’t allow it to start because of the same issue. There is simply no practical and technical reason to not allow the process to start because of this. We run nginx with over 50 custom locations across multiple services. And it simply won’t start if one is dead or missconfigured (like typing the wrong port there).

kerem commented

2026-02-26 07:30:34 +03:00

Author

Owner

@Daredevll commented on GitHub (Oct 27, 2025):

Any info on that? I'm also curious as to why this happens and honestly seems like a bug to me. We've got multiple independent containerized services running and removing one without disabling the proxy pass in NPM renders NPM inoperable, in practice taking down our whole suite of services..

@Daredevll commented on GitHub (Oct 27, 2025): Any info on that? I'm also curious as to why this happens and honestly seems like a bug to me. We've got multiple independent containerized services running and removing one without disabling the proxy pass in NPM renders NPM inoperable, in practice taking down our whole suite of services..

kerem commented

2026-02-26 07:30:34 +03:00

Author

Owner

@tjunussov commented on GitHub (Nov 19, 2025):

Stupid feature, sometimes one small host could be down,
and whole server if rebooted, nginx-proxy-manager wont start,
of course of nginx host check feature, maybe we could do something smart ? if nginx failing to start, we could start at least itself in safe mode ? so user could disable failty host

@tjunussov commented on GitHub (Nov 19, 2025): Stupid feature, sometimes one small host could be down, and whole server if rebooted, nginx-proxy-manager wont start, of course of nginx host check feature, maybe we could do something smart ? if nginx failing to start, we could start at least itself in safe mode ? so user could disable failty host

Rows
Columns

[GH-ISSUE #1807] setup nginx not to crash if host in proxy pass not found #1337

No stop when error on config

https://stackoverflow.com/questions/32845674/setup-nginx-not-to-crash-if-host-in-upstream-is-not-found/32846603#32846603

https://stackoverflow.com/questions/35744650/docker-network-nginx-resolver/37656784#37656784