[GH-ISSUE #3604] Lack of DNS Resolution/Internet Connection causes NPM panel 'Bad Gateway'

kerem commented

2026-02-26 07:35:22 +03:00

Owner

Originally created by @bluekitedreamer on GitHub (Mar 6, 2024).
Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/3604

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

The NPM portal app backend will not load because of a network failure. I'm running through scenarios to help reduce downtime in the future, one of the scenarios is pulling the internet cord for example (internet outage simulation). Another is DNS resolution failure, which leads to the same result.

When starting the container in such a situation you are presented with various errors. An example of one:

WARNING: Retrying (Retry(total=1, connect=None, read=None, redirect=None, status=None)) after connection broken by 'NewConnectionError('<pip._vendor.urllib3.connection.HTTPSConnection object at 0x7fb598e32f50>: Failed to establish a new connection: [Errno -3] Temporary failure in name resolution')': /simple/certbot-dns-cloudfare/

Nginx Proxy Manager Version

v2.11.1

To Reproduce
Steps to reproduce the behavior:

Have an existing environment setup with successful lets encrypt certificate generation
Pull internet cord OR block internet connection OR block dns resolution
Start the container

Expected behavior

The portal and backend shouldn't need a dependency on the ability to reach out to lets encrypt during startup. If certificates are already generated there is no need to do a check/update during startup that would result in a catastrophic failure, that should instead entail an error down the line that's visible in the portal (could even be a feature improvement to do SMTP alerts on inability to connect to lets encrypt and downed proxy hosts). Users working in airgapped environments with manually loaded certificates would also not be able to start the container.

Screenshots

Operating System

Additional context

Originally created by @bluekitedreamer on GitHub (Mar 6, 2024). Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/3604  **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**  The NPM portal app backend will not load because of a network failure. I'm running through scenarios to help reduce downtime in the future, one of the scenarios is pulling the internet cord for example (internet outage simulation). Another is DNS resolution failure, which leads to the same result. When starting the container in such a situation you are presented with various errors. An example of one: ``` WARNING: Retrying (Retry(total=1, connect=None, read=None, redirect=None, status=None)) after connection broken by 'NewConnectionError('<pip._vendor.urllib3.connection.HTTPSConnection object at 0x7fb598e32f50>: Failed to establish a new connection: [Errno -3] Temporary failure in name resolution')': /simple/certbot-dns-cloudfare/ ``` **Nginx Proxy Manager Version**  v2.11.1 **To Reproduce** Steps to reproduce the behavior: 1. Have an existing environment setup with successful lets encrypt certificate generation 2. Pull internet cord OR block internet connection OR block dns resolution 3. Start the container **Expected behavior**  The portal and backend shouldn't need a dependency on the ability to reach out to lets encrypt during startup. If certificates are already generated there is no need to do a check/update during startup that would result in a catastrophic failure, that should instead entail an error down the line that's visible in the portal (could even be a feature improvement to do SMTP alerts on inability to connect to lets encrypt and downed proxy hosts). Users working in airgapped environments with manually loaded certificates would also not be able to start the container. **Screenshots**  **Operating System**  **Additional context**

kerem

2026-02-26 07:35:22 +03:00

closed this issue
added the
stale

bug
labels

kerem commented

2026-02-26 07:35:22 +03:00

Author

Owner

@doublehelix commented on GitHub (Mar 27, 2024):

I have the same issue.
There seems to be no way to manually configure an IP address for DNS.

The configuration I have is:

Docker PiHole connected to MacVLan.
DHCP Server broadcasts PiHole MacVLan IP for DNS for all clients on the network.
The Nginx Proxy manager in docker tries to use, but CANNOT see the IP address of the PiHole (MacVLan network is not accessible to other docker containers - by design)
I have no way to tell NPM to use an alternate DNS IP.

Even if we have to edit a config file, it would be better than nothing.
An option in the GUI would also be great though!?

@doublehelix commented on GitHub (Mar 27, 2024): I have the same issue. There seems to be no way to manually configure an IP address for DNS. The configuration I have is: - Docker PiHole connected to MacVLan. - DHCP Server broadcasts PiHole MacVLan IP for DNS for all clients on the network. - The Nginx Proxy manager in docker tries to use, but CANNOT see the IP address of the PiHole (MacVLan network is not accessible to other docker containers - by design) - I have no way to tell NPM to use an alternate DNS IP. Even if we have to edit a config file, it would be better than nothing. An option in the GUI would also be great though!?

kerem commented

2026-02-26 07:35:22 +03:00

Author

Owner

@barrelltitor commented on GitHub (Apr 15, 2024):

@doublehelix why not just use the dns option in docker compose? You just add e.g dns: 192.168.1.5 on the same level as container_name, image, etc

@barrelltitor commented on GitHub (Apr 15, 2024): @doublehelix why not just use the dns option in docker compose? You just add e.g `dns: 192.168.1.5` on the same level as container_name, image, etc

kerem commented

2026-02-26 07:35:22 +03:00

Author

Owner

@doublehelix commented on GitHub (Apr 15, 2024):

@doublehelix why not just use the dns option in docker compose? You just add e.g dns: 192.168.1.5 on the same level as container_name, image, etc

Unfortunately that doesn't work due to network isolation within docker containers and networks.
The only solution I've found so far is to network pihole on a macVLan and create a shared bridge that is used by all containers that need to use the DNS services in the pihole container (including nginx).
This has the unfortunate side effect that all docker containers are now networked together. Not ideal, and the opposite of the intention of isolation by default.

The other solution of course is to not host DNS in docker. (Which is the route I ended up taking in the meantime)

@doublehelix commented on GitHub (Apr 15, 2024): > @doublehelix why not just use the dns option in docker compose? You just add e.g `dns: 192.168.1.5` on the same level as container_name, image, etc Unfortunately that doesn't work due to network isolation within docker containers and networks. The only solution I've found so far is to network pihole on a macVLan and create a shared bridge that is used by all containers that need to use the DNS services in the pihole container (including nginx). This has the unfortunate side effect that all docker containers are now networked together. Not ideal, and the opposite of the intention of isolation by default. The other solution of course is to not host DNS in docker. (Which is the route I ended up taking in the meantime)

kerem commented

2026-02-26 07:35:22 +03:00

Author

Owner

@barrelltitor commented on GitHub (Apr 17, 2024):

all docker containers are now networked together.

You can setup firewall rules on that network to:

accept anything to/from the pihole specific IP and ports you need
drop everything else

That way they will not really be networked together, as the connection would be immediately dropped.

@barrelltitor commented on GitHub (Apr 17, 2024): > all docker containers are now networked together. You can setup firewall rules on that network to: - accept anything to/from the pihole specific IP and ports you need - drop everything else That way they will not really be networked together, as the connection would be immediately dropped.

kerem commented

2026-02-26 07:35:22 +03:00

Author

Owner

@github-actions[bot] commented on GitHub (Oct 28, 2024):

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

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

kerem commented

2026-02-26 07:35:22 +03:00

Author

Owner

@github-actions[bot] commented on GitHub (Oct 31, 2025):

Issue was closed due to inactivity.

@github-actions[bot] commented on GitHub (Oct 31, 2025): Issue was closed due to inactivity.

kerem referenced this issue

2026-02-26 08:31:08 +03:00

[PR #2444] [MERGED] Load events configuration from custom file #3568

Rows
Columns

[GH-ISSUE #3604] Lack of DNS Resolution/Internet Connection causes NPM panel 'Bad Gateway' #2388