[GH-ISSUE #2197] Host not working when using container's name with Podman #1574

New issue

Open

opened 2026-02-26 07:31:37 +03:00 by kerem · 12 comments

kerem commented 2026-02-26 07:31:37 +03:00

Owner

Copy link

Originally created by @matheusfenolio on GitHub (Aug 12, 2022).
Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/2197

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'm trying to add a host using the name of the container, and when I open the URL, a 502 bad gateway appears. I tried using Docker, and it worked, but with Podman, it only works with container's IP.

Nginx Proxy Manager Version
v2.9.18

To Reproduce
Steps to reproduce the behavior:

1. Create the container to forward: podman run --name web --network nginx-proxy-manager_default -d nginx:latest
2. Add the host with:
   -Forward Hostname / IP: web
   -Port: 80
3. Try to access service.

Expected behavior
The Nginx welcome page should appear

Screenshots

Operating System
Tried on

• Ubuntu 20.04 - Podman 3.2.2
• Ubuntu 22.04 - Podman 3.2.2 and Podman 4.2
• Fedora 36 - Podman 4.1

Additional context
docker-compose.yml
version: '3'
services:
app:
image: 'jc21/nginx-proxy-manager:latest'
restart: unless-stopped
ports:
- '80:80'
- '81:81'
- '443:443'
volumes:
- ./data:/data
- ./letsencrypt:/etc/letsencrypt

Originally created by @matheusfenolio on GitHub (Aug 12, 2022). Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/2197 **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'm trying to add a host using the name of the container, and when I open the URL, a 502 bad gateway appears. I tried using Docker, and it worked, but with Podman, it only works with container's IP. **Nginx Proxy Manager Version** v2.9.18 **To Reproduce** Steps to reproduce the behavior: 1. Create the container to forward: podman run --name web --network nginx-proxy-manager_default -d nginx:latest 2. Add the host with: -Forward Hostname / IP: web -Port: 80 3. Try to access service. **Expected behavior** The Nginx welcome page should appear **Screenshots**      **Operating System** Tried on - Ubuntu 20.04 - Podman 3.2.2 - Ubuntu 22.04 - Podman 3.2.2 and Podman 4.2 - Fedora 36 - Podman 4.1 **Additional context** docker-compose.yml version: '3' services: app: image: 'jc21/nginx-proxy-manager:latest' restart: unless-stopped ports: - '80:80' - '81:81' - '443:443' volumes: - ./data:/data - ./letsencrypt:/etc/letsencrypt

kerem added the

bug

label 2026-02-26 07:31:37 +03:00

kerem commented 2026-02-26 07:31:37 +03:00

Author

Owner

Copy link

@the1ts commented on GitHub (Aug 13, 2022):

Don't think this is an NPM issue, there is lots of talk of podman issues around DNS after the default network change that was done for Podman 4 which was released in May of this year. Seems although CNI was left as the network stack if network was already setup, the DNS plugin was no longer used by default so this is the symptom. Try adding the DNS plugin to Podman for the old CNI network you probably have or remove the exisiting old network and upgrade to the new default network type which does have DNS builtin.

<!-- gh-comment-id:1214239467 --> @the1ts commented on GitHub (Aug 13, 2022): Don't think this is an NPM issue, there is lots of talk of podman issues around DNS after the default network change that was done for Podman 4 which was released in May of this year. Seems although CNI was left as the network stack if network was already setup, the DNS plugin was no longer used by default so this is the symptom. Try adding the DNS plugin to Podman for the old CNI network you probably have or remove the exisiting old network and upgrade to the new default network type which does have DNS builtin.

kerem commented 2026-02-26 07:31:37 +03:00

Author

Owner

Copy link

@matheusfenolio commented on GitHub (Sep 9, 2022):

I'll give it a shot! I saw some issues about it, but I thought it was fixed since I'm able to connect two containers only using the container name.

<!-- gh-comment-id:1242264034 --> @matheusfenolio commented on GitHub (Sep 9, 2022): I'll give it a shot! I saw some issues about it, but I thought it was fixed since I'm able to connect two containers only using the container name.

kerem commented 2026-02-26 07:31:37 +03:00

Author

Owner

Copy link

@BrandonG777 commented on GitHub (Mar 29, 2023):

whats strange is DNS works properly from command line, and even for creating subfolder proxies but not hostname proxies. hostnames will intermittently resolve which has me scratching my head even more.

<!-- gh-comment-id:1489117663 --> @BrandonG777 commented on GitHub (Mar 29, 2023): whats strange is DNS works properly from command line, and even for creating subfolder proxies but not hostname proxies. hostnames will intermittently resolve which has me scratching my head even more.

kerem commented 2026-02-26 07:31:37 +03:00

Author

Owner

Copy link

@BrandonG777 commented on GitHub (Mar 30, 2023):

Even using CNI network backend DNS is still intermittent. cannot replicate the issue at command line

<!-- gh-comment-id:1490332605 --> @BrandonG777 commented on GitHub (Mar 30, 2023): Even using CNI network backend DNS is still intermittent. cannot replicate the issue at command line

kerem commented 2026-02-26 07:31:37 +03:00

Author

Owner

Copy link

@the1ts commented on GitHub (Mar 30, 2023):

Sorry, I don't use podman or npm anymore, but there is a good reason why command line and nginx work differently. DNS for the command line is done via podman or whatever is setting up the container. Nginx is setup to use /data/nginx/resolv.conf. This from memory gets set at first start and perhaps is incorrect or has multiple servers in it, hence intermittent.

<!-- gh-comment-id:1490370041 --> @the1ts commented on GitHub (Mar 30, 2023): Sorry, I don't use podman or npm anymore, but there is a good reason why command line and nginx work differently. DNS for the command line is done via podman or whatever is setting up the container. Nginx is setup to use /data/nginx/resolv.conf. This from memory gets set at first start and perhaps is incorrect or has multiple servers in it, hence intermittent.

kerem commented 2026-02-26 07:31:37 +03:00

Author

Owner

Copy link

@BrandonG777 commented on GitHub (Mar 30, 2023):

Well thanks for the reply anyway, you ultimately pointed me in the right direction. /data/nginx/resolv.conf no longer exist and didn't seem to have any affect on resolving this issue. However /etc/resolv.conf contained the podman host address and then my real host system dns entires. It appears that nginx was doing some sort of round robin selection of which DNS server it was going to use for lookup. Since this only affects host proxies and not subfolder location proxies I added a resolver entry to my host proxy custom config and that is working for me. I noticed the swag container uses 127.0.0.11 in it's resolver config which doesn't seem to work with this container. Maybe they are doing adding some sort of port forwarding or adding a package to make this work? Seems like that solution would work well for this container as well.

<!-- gh-comment-id:1490826482 --> @BrandonG777 commented on GitHub (Mar 30, 2023): Well thanks for the reply anyway, you ultimately pointed me in the right direction. /data/nginx/resolv.conf no longer exist and didn't seem to have any affect on resolving this issue. However /etc/resolv.conf contained the podman host address and then my real host system dns entires. It appears that nginx was doing some sort of round robin selection of which DNS server it was going to use for lookup. Since this only affects host proxies and not subfolder location proxies I added a resolver entry to my host proxy custom config and that is working for me. I noticed the swag container uses 127.0.0.11 in it's resolver config which doesn't seem to work with this container. Maybe they are doing adding some sort of port forwarding or adding a package to make this work? Seems like that solution would work well for this container as well.

kerem commented 2026-02-26 07:31:37 +03:00

Author

Owner

Copy link

@fuzzyfox commented on GitHub (Jul 19, 2023):

I believe I have tracked this down to a combination how nginx appears to handle the DNS resolution when it has multiple resolvers specified, and podman DNS resolution.

The issues can be resolved by manually altering the /etc/nginx/conf.d/include/resolvers.conf to only include the podman resolver ip, and no other ips. In my case:

# from
resolver 10.89.0.1 8.8.8.8 ipv6=off valid=10s;
# to
resolver 10.89.0.1 ipv6=off valid=10s;

This resolved my issues, obviously this wont stick through a container restart right now due to how this file is generated so as a more resilient interim solution I've added the updated resolvers line to the custom configs for proxies https://nginxproxymanager.com/advanced-config/#custom-nginx-configurations. Ideally I'd put it into the custom http.conf, however as nginx does not allow redeclaring directives, this wont work right now.

My proposal would be to allow a custom resolver config to be used on boot-up, and if it doesn't exist, then generate the file as it is right now.

<!-- gh-comment-id:1642139593 --> @fuzzyfox commented on GitHub (Jul 19, 2023): I believe I have tracked this down to a combination how nginx appears to handle the DNS resolution when it has multiple resolvers specified, and podman DNS resolution. The issues can be resolved by manually altering the `/etc/nginx/conf.d/include/resolvers.conf` to only include the podman resolver ip, and no other ips. In my case: ```nginx # from resolver 10.89.0.1 8.8.8.8 ipv6=off valid=10s; # to resolver 10.89.0.1 ipv6=off valid=10s; ``` This resolved my issues, obviously this wont stick through a container restart right now due to [how this file is generated](https://github.com/NginxProxyManager/nginx-proxy-manager/blob/f91f0ee8db0a72ffb6a8a059474cb5d48ecff2c1/docker/rootfs/etc/s6-overlay/s6-rc.d/prepare/40-dynamic.sh ) so as a more resilient interim solution I've added the updated resolvers line to the custom configs for proxies <https://nginxproxymanager.com/advanced-config/#custom-nginx-configurations>. Ideally I'd put it into the custom `http.conf`, however as nginx does not allow redeclaring directives, this wont work right now. My proposal would be to allow a custom resolver config to be used on boot-up, and if it doesn't exist, then generate the file as it is right now.

kerem commented 2026-02-26 07:31:37 +03:00

Author

Owner

Copy link

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

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

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

kerem commented 2026-02-26 07:31:37 +03:00

Author

Owner

Copy link

@patrickklaeren commented on GitHub (Aug 23, 2024):

I believe I have this exact error running Portainer and using the hostname, the exact same as in the original description above.

<!-- gh-comment-id:2307603594 --> @patrickklaeren commented on GitHub (Aug 23, 2024): I believe I have this exact error running Portainer and using the hostname, the exact same as in the original description above.

kerem commented 2026-02-26 07:31:38 +03:00

Author

Owner

Copy link

@github-actions[bot] commented on GitHub (Mar 29, 2025):

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

<!-- gh-comment-id:2763016702 --> @github-actions[bot] commented on GitHub (Mar 29, 2025): Issue is now considered stale. If you want to keep it open, please comment :+1:

kerem commented 2026-02-26 07:31:38 +03:00

Author

Owner

Copy link

@perryk commented on GitHub (Sep 3, 2025):

Just adding a comment to keep this issue open.

Same issue persists in latest NPM and Podman.

Mentioned also in #2608

<!-- gh-comment-id:3248671375 --> @perryk commented on GitHub (Sep 3, 2025): Just adding a comment to keep this issue open. Same issue persists in latest NPM and Podman. Mentioned also in #2608

kerem commented 2026-02-26 07:31:38 +03:00

Author

Owner

Copy link

@Raul824 commented on GitHub (Feb 9, 2026):

Am facing similar issue on PikaOS.

NPM Version 2.13.7
podman version 5.7.0

Output of curl command from host machine

*   Trying 192.168.1.110:8096...
* Established connection to 192.168.1.110 (192.168.1.110 port 8096) from 192.168.1.110 port 43224 
* using HTTP/1.x
> GET / HTTP/1.1
> Host: 192.168.1.110:8096
> User-Agent: curl/8.18.0
> Accept: */*
> 
* Request completely sent off
< HTTP/1.1 302 Found
< Content-Length: 0
< Date: Mon, 09 Feb 2026 15:14:39 GMT
< Server: Kestrel
< Location: web/
< 
* Connection #0 to host 192.168.1.110:8096 left intact```

Output of curl from inside the pod of npm.

```curl -v http://192.168.1.110:8096
*   Trying 192.168.1.110:8096...
* connect to 192.168.1.110 port 8096 failed: Connection refused
* Failed to connect to 192.168.1.110 port 8096 after 0 ms: Couldn't connect to server
* Closing connection 0
curl: (7) Failed to connect to 192.168.1.110 port 8096 after 0 ms: Couldn't connect to server```

<!-- gh-comment-id:3872334902 --> @Raul824 commented on GitHub (Feb 9, 2026): Am facing similar issue on PikaOS. NPM Version 2.13.7 podman version 5.7.0 Output of curl command from host machine ```curl -v http://192.168.1.110:8096 * Trying 192.168.1.110:8096... * Established connection to 192.168.1.110 (192.168.1.110 port 8096) from 192.168.1.110 port 43224 * using HTTP/1.x > GET / HTTP/1.1 > Host: 192.168.1.110:8096 > User-Agent: curl/8.18.0 > Accept: */* > * Request completely sent off < HTTP/1.1 302 Found < Content-Length: 0 < Date: Mon, 09 Feb 2026 15:14:39 GMT < Server: Kestrel < Location: web/ < * Connection #0 to host 192.168.1.110:8096 left intact``` Output of curl from inside the pod of npm. ```curl -v http://192.168.1.110:8096 * Trying 192.168.1.110:8096... * connect to 192.168.1.110 port 8096 failed: Connection refused * Failed to connect to 192.168.1.110 port 8096 after 0 ms: Couldn't connect to server * Closing connection 0 curl: (7) Failed to connect to 192.168.1.110 port 8096 after 0 ms: Couldn't connect to server```

kerem referenced this issue 2026-02-26 08:30:44 +03:00

[PR #1574] [MERGED] v2.9.12 #3461

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

develop

dependabot/npm_and_yarn/backend/liquidjs-10.25.7

dependabot/npm_and_yarn/frontend/prod-minor-updates-2a16bf3987

dependabot/npm_and_yarn/frontend/dev-patch-updates-754666cf41

dependabot/npm_and_yarn/backend/basic-ftp-5.3.0

dependabot/npm_and_yarn/test/follow-redirects-1.16.0

dependabot/npm_and_yarn/test/axios-1.15.0

dependabot/npm_and_yarn/frontend/lodash-4.18.1

dependabot/npm_and_yarn/backend/lodash-4.18.1

dependabot/npm_and_yarn/test/lodash-4.18.1

dependabot/npm_and_yarn/frontend/vite-7.3.2

dependabot/npm_and_yarn/backend/prod-minor-updates-5ec19a7f21

dependabot/npm_and_yarn/frontend/lodash-es-4.18.1

dependabot/npm_and_yarn/frontend/happy-dom-20.8.9

dependabot/npm_and_yarn/backend/path-to-regexp-8.4.0

dependabot/npm_and_yarn/frontend/picomatch-4.0.4

dependabot/npm_and_yarn/backend/picomatch-2.3.2

dependabot/npm_and_yarn/frontend/yaml-1.10.3

dependabot/npm_and_yarn/test/flatted-3.4.2

dependabot/npm_and_yarn/test/tar-7.5.11

dependabot/npm_and_yarn/frontend/immutable-5.1.5

master

dependabot/npm_and_yarn/test/glob-10.5.0

dependabot/npm_and_yarn/frontend/mdast-util-to-hast-13.2.1

dependabot/npm_and_yarn/test/form-data-4.0.4

v3-abandoned

bump-freedns

openidc

ssl-passthrough-hosts

static-content

v2.14.0

v2.13.7

v2.13.6

v2.13.5

v2.13.4

v2.13.3

v2.13.2

v2.13.1

v2.13.0

v2.12.6

v2.12.5

v2.12.4

v2.12.3

v2.12.2

v2.12.1

v2.12.0

v2.11.3

v2.11.2

v2.11.1

v2.11.0

v2.10.4

v2.10.3

v2.10.2

v2.10.1

v2.10.0

v2.9.22

v2.9.21

v2.9.20

v2.9.19

v2.9.18

v2.9.17

v2.9.16

v2.9.15

v2.9.14

v2.9.13

v2.9.12

v2.9.11

v2.9.10

v2.9.9

v2.9.8

v2.9.7

v2.9.6

v2.9.5

v2.9.4

v2.9.3

v2.9.2

v2.9.1

v2.9.0

v2.8.1

v2.8.0

v2.7.3

v2.7.2

v2.7.1

v2.7.0

v2.6.2

v2.6.1

v2.6.0

v2.5.0

v2.4.0

v2.3.1

v2.3.0

v2.2.4

v2.2.3

v2.2.2

v2.2.1

v2.2.0

v2.1.2

v2.1.1

v2.1.0

2.0.14

2.0.13

2.0.12

2.0.11

2.0.10

2.0.9

2.0.8

2.0.7

2.0.6

2.0.5

2.0.4

2.0.3

2.0.2

2.0.0

v2.0.0

1.1.2

1.1.1

1.0.1

Labels

Clear labels   

awaiting feedback

  

bug

  

cannot reproduce

  

dns provider request

  

duplicate

  

enhancement

  

enhancement

  

enhancement

  

good first issue

  

help wanted

  

invalid

  

need more info

  

no certbot plugin available

  

product-support

  

pull-request

Mirrored from GitHub Pull Request

  

question

  

stale

  

troll

  

upstream issue

  

v2

  

v2

  

v2

  

v3

  

wontfix

No labels

awaiting feedback

bug

cannot reproduce

dns provider request

duplicate

enhancement

enhancement

enhancement

good first issue

help wanted

invalid

need more info

no certbot plugin available

product-support

pull-request

question

stale

troll

upstream issue

v2

v2

v2

v3

wontfix

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/nginx-proxy-manager-NginxProxyManager#1574

No description provided.