[GH-ISSUE #3919] Proxy not forwarding to locally-hosted services

kerem commented

2026-02-26 07:36:02 +03:00

Owner

Originally created by @huntson on GitHub (Aug 8, 2024).
Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/3919

Checklist

Have you pulled and found the error with jc21/nginx-proxy-manager:latest docker image?
- Yes / No
Are you sure you're not using someone else's docker image?
- Yes / No
Have you searched for similar issues (both open and closed)?
- Yes / No

Describe the bug

The Proxy Manager is currently running in a docker. I am unable to get it to forward to services locally hosted dockers the same system. All forwards to other systems work fine however when forwarding to local services in dockers. I've tried local docker IPs plus the port number as well as the local IP of the server plus the port number and no luck.

Nginx Proxy Manager Version

2.11.13

To Reproduce
Steps to reproduce the behavior:
See above. I receive a 504 Gateway Time-out.

Compose command:

services:
  app:
    image: 'docker.io/jc21/nginx-proxy-manager:latest'
    restart: unless-stopped
    ports:
      - '80:80'
      - '81:81'
      - '443:443'
    volumes:
      - /share/ZFS20_DATA/docker/nginx-proxy/data:/data
      - /share/ZFS20_DATA/docker/nginx-proxy/letsencrypt:/etc/letsencrypt

Expected behavior
I'd expect the local service to be loaded.

Screenshots

Operating System
Docker running on QNAP

Additional context

Originally created by @huntson on GitHub (Aug 8, 2024). Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/3919  **Checklist** - Have you pulled and found the error with `jc21/nginx-proxy-manager:latest` docker image? - Yes / No - Are you sure you're not using someone else's docker image? - Yes / No - Have you searched for similar issues (both open and closed)? - Yes / No **Describe the bug**  The Proxy Manager is currently running in a docker. I am unable to get it to forward to services locally hosted dockers the same system. All forwards to other systems work fine however when forwarding to local services in dockers. I've tried local docker IPs plus the port number as well as the local IP of the server plus the port number and no luck. **Nginx Proxy Manager Version**  2.11.13 **To Reproduce** Steps to reproduce the behavior: See above. I receive a 504 Gateway Time-out. Compose command: ``` services: app: image: 'docker.io/jc21/nginx-proxy-manager:latest' restart: unless-stopped ports: - '80:80' - '81:81' - '443:443' volumes: - /share/ZFS20_DATA/docker/nginx-proxy/data:/data - /share/ZFS20_DATA/docker/nginx-proxy/letsencrypt:/etc/letsencrypt ``` **Expected behavior** I'd expect the local service to be loaded. **Screenshots**  **Operating System** Docker running on QNAP **Additional context**

kerem added the

stale

bug

labels

2026-02-26 07:36:02 +03:00

kerem commented

2026-02-26 07:36:02 +03:00

Author

Owner

@phulstaert commented on GitHub (Aug 8, 2024):

This is very limited information to help you with.

I can confirm that this is not a nginx-proxy-manager issue; since this use case works with my setup. I use it at multiple locations like this.

I would suggest to post the following information:

What QNAP NAS are you using and does it have multiple network interfaces that are bonded together? (I have a Synology NAS where bonded ethernet ports prevent docker containers to talk to each other) - this is not the case on a "simple" VM.
docker-compose (or command if you don't use docker compose) how the nginx-proxy-manager is set up. That way we can see what network it is connected to, what exposed ports there are, etc...
docker-compose (or command if you don't use docker compose) of the service you try to reach. Are they in the same network? (ex: a common reverse_proxy network?)
does the reverse proxy work on external (other machines) services - or only when they are on the same machine?

@phulstaert commented on GitHub (Aug 8, 2024): This is very limited information to help you with. I can confirm that this is not a nginx-proxy-manager issue; since this use case works with my setup. I use it at multiple locations like this. I would suggest to post the following information: - What QNAP NAS are you using and does it have multiple network interfaces that are bonded together? (I have a Synology NAS where bonded ethernet ports prevent docker containers to talk to each other) - this is not the case on a "simple" VM. - docker-compose (or command if you don't use docker compose) how the nginx-proxy-manager is set up. That way we can see what network it is connected to, what exposed ports there are, etc... - docker-compose (or command if you don't use docker compose) of the service you try to reach. Are they in the same network? (ex: a common reverse_proxy network?) - does the reverse proxy work on external (other machines) services - or only when they are on the same machine?

kerem commented

2026-02-26 07:36:02 +03:00

Author

Owner

@huntson commented on GitHub (Aug 8, 2024):

I appreciate you sharing what additional information you need:

I am using a TS-h1887RP with one NIC being used.

In my original post I did have the docker-compose command however I'm not sure where it is. I have updated the original and will be pasting it here.

services:
  app:
    image: 'docker.io/jc21/nginx-proxy-manager:latest'
    restart: unless-stopped
    ports:
      - '80:80'
      - '81:81'
      - '443:443'
    volumes:
      - /share/ZFS20_DATA/docker/nginx-proxy/data:/data
      - /share/ZFS20_DATA/docker/nginx-proxy/letsencrypt:/etc/letsencrypt

Here is the compose command of the service I am attempting to reach. As far as I understand/know, they are on their own networks.

services:
  homarr:
    container_name: homarr
    image: ghcr.io/ajnart/homarr:latest
    restart: unless-stopped
    volumes:
      - /share/ZFS20_DATA/docker/homarr/configs:/app/data/configs
      - /share/ZFS20_DATA/docker/homarr/icons:/app/public/icons
      - /share/ZFS20_DATA/docker/homarr/data:/data
      - /var/run/docker.sock:/var/run/docker.sock:ro

    ports:
      - '4755:7575'
      
    environment:
      TZ: America/New_York

As stated in the original, the reverse proxy works well on external services - only services on the same machine, specifically docker services on the same machine, are problematic.

@huntson commented on GitHub (Aug 8, 2024): I appreciate you sharing what additional information you need: I am using a TS-h1887RP with one NIC being used. In my original post I did have the docker-compose command however I'm not sure where it is. I have updated the original and will be pasting it here. ``` services: app: image: 'docker.io/jc21/nginx-proxy-manager:latest' restart: unless-stopped ports: - '80:80' - '81:81' - '443:443' volumes: - /share/ZFS20_DATA/docker/nginx-proxy/data:/data - /share/ZFS20_DATA/docker/nginx-proxy/letsencrypt:/etc/letsencrypt ``` Here is the compose command of the service I am attempting to reach. As far as I understand/know, they are on their own networks. ``` services: homarr: container_name: homarr image: ghcr.io/ajnart/homarr:latest restart: unless-stopped volumes: - /share/ZFS20_DATA/docker/homarr/configs:/app/data/configs - /share/ZFS20_DATA/docker/homarr/icons:/app/public/icons - /share/ZFS20_DATA/docker/homarr/data:/data - /var/run/docker.sock:/var/run/docker.sock:ro ports: - '4755:7575' environment: TZ: America/New_York ``` As stated in the original, the reverse proxy works well on external services - only services on the same machine, specifically docker services on the same machine, are problematic.

kerem commented

2026-02-26 07:36:02 +03:00

Author

Owner

@phulstaert commented on GitHub (Aug 8, 2024):

To be clear, I'm just a user, not a contributor of this application.

Have you checked this?

Have you tried if you can ping from one container to another? (ex: start an alpine image or something like that)

@phulstaert commented on GitHub (Aug 8, 2024): To be clear, I'm just a user, not a contributor of this application. Have you checked [this](https://www.qnap.com/en/how-to/tutorial/article/how-to-debug-and-fix-common-container-issues-in-container-station#Checking-the-QNAP-System-Configuration-F582455BBDE7)? Have you tried if you can ping from one container to another? (ex: start an alpine image or something like that)

kerem commented

2026-02-26 07:36:03 +03:00

Author

Owner

@huntson commented on GitHub (Aug 8, 2024):

To be clear, I'm just a user, not a contributor of this application.

Have you checked this?

Have you tried if you can ping from one container to another? (ex: start an alpine image or something like that)

Now we're getting somewhere. It appears there is a limited set of containers that cannot be reached via ping from my nginx proxy container. That being said everything is set to allow so I'm a bit at a loss as to how this has happened. While I realize container support is not what I'm here for, any thoughts would be helpful.

@huntson commented on GitHub (Aug 8, 2024): > To be clear, I'm just a user, not a contributor of this application. > > Have you checked [this](https://www.qnap.com/en/how-to/tutorial/article/how-to-debug-and-fix-common-container-issues-in-container-station#Checking-the-QNAP-System-Configuration-F582455BBDE7)? > > Have you tried if you can ping from one container to another? (ex: start an alpine image or something like that) Now we're getting somewhere. It appears there is a limited set of containers that cannot be reached via ping from my nginx proxy container. That being said everything is set to allow so I'm a bit at a loss as to how this has happened. While I realize container support is not what I'm here for, any thoughts would be helpful.

kerem commented

2026-02-26 07:36:03 +03:00

Author

Owner

@phulstaert commented on GitHub (Aug 8, 2024):

It is good that there are both containers that are reachable and containers that are not reachable. This gives us something to compare. I'm also no expert in these kind of things, but hey, maybe we find something together :-)

Personally I would do the following:

check if the containers that are reachable also cannot reach the unreachable containers. This would confirm it is a configuration issue on the docker level, and not specifically a nginx-proxy-manager issue.
check if there is no firewall in between. (no ping can still mean that ICMP traffic is not getting through.
check if you see something special in the docker networks (what if you add the nginx-proxy-manager network to the unreachable container?)
check if you see some kind of deviation in the ip adresses and ranges docker assigns.
do a traceroute to check you are not going to the default gateway and "outside" the docker environment.
did you try comparing pinging to the ip vs docker container name?

@phulstaert commented on GitHub (Aug 8, 2024): It is good that there are both containers that are reachable and containers that are not reachable. This gives us something to compare. I'm also no expert in these kind of things, but hey, maybe we find something together :-) Personally I would do the following: - check if the containers that are reachable also cannot reach the unreachable containers. This would confirm it is a configuration issue on the docker level, and not specifically a nginx-proxy-manager issue. - check if there is no firewall in between. (no ping can still mean that ICMP traffic is not getting through. - check if you see something special in the docker networks (what if you add the nginx-proxy-manager network to the unreachable container?) - check if you see some kind of deviation in the ip adresses and ranges docker assigns. - do a traceroute to check you are not going to the default gateway and "outside" the docker environment. - did you try comparing pinging to the ip vs docker container name?

kerem commented

2026-02-26 07:36:03 +03:00

Author

Owner

@huntson commented on GitHub (Aug 9, 2024):

I was able to add a second interface to both containers which got them talking to each other. Oddly enough I have another issue now. Generally speaking, if I go to the ip:port of the server, it auto-redirects to ip:port/auth/login?redirectAfterLogin=/board. When going to the FQDN of the proxy it redirects to FQDN/redirect.html?count=0.38129492248640207. Not sure why that is.

What is the best way of having fqdn.com redirect to fqdn.com/board OR proxy to ip:port/board?

@huntson commented on GitHub (Aug 9, 2024): I was able to add a second interface to both containers which got them talking to each other. Oddly enough I have another issue now. Generally speaking, if I go to the ip:port of the server, it auto-redirects to ip:port/auth/login?redirectAfterLogin=/board. When going to the FQDN of the proxy it redirects to FQDN/redirect.html?count=0.38129492248640207. Not sure why that is. What is the best way of having fqdn.com redirect to fqdn.com/board OR proxy to ip:port/board?

kerem commented

2026-02-26 07:36:03 +03:00

Author

Owner

@phulstaert commented on GitHub (Aug 9, 2024):

This is far beyond nginx-proxy-manager, but i'll give a general idea how this works and what could be the culprit.

When you go to a website, the server will get the request and for example notice you are not logged in.
It will not react with a content and a HTTP 200 code, but with a redirect (HTTP 302 or HTTP 303 - it should be 303 but a lot of software uses 302; but this does not really matter since they both "do" the same) to a certain page. (often BASE_URL/login). This is however something the application itself does.

When on the login page, you enter your credentials and if they are wrong, you stay on the same page (with an error); if they are correct a SID cookie is set and you are redirected (again HTTP 302/303) to the main page. Now the main page sees that you are logged in, so it will present you with the main page and will not do a redirect to the login page.

In your case, the application does something that you do not expect.

See if you need to configure the domain in the application
See in the network tab of the browser or the logging of the application what redirects are happening.
Search for this specific issue on the internet for that specific piece of software. (chances are you are not the first one).

Although you CAN configure redirects in nginx-proxy-manager, this is more suited for a 301 (permanently moved) or a valid 302 (Found) use case. (ex: if you go to "https://support.company.xyz", you get redirected to "https://jira.company.xyz/tickets/new?type=guest").
Nginx is not suited to do any checking of passwords to see if you can log in or not. This is up to the application itself.

Does this makes sence to you? My explanation is a bit long, so maybe not that good :-D

@phulstaert commented on GitHub (Aug 9, 2024): This is far beyond nginx-proxy-manager, but i'll give a general idea how this works and what could be the culprit. When you go to a website, the server will get the request and for example notice you are not logged in. It will not react with a content and a HTTP 200 code, but with a redirect (HTTP 302 or HTTP 303 - it should be 303 but a lot of software uses 302; but this does not really matter since they both "do" the same) to a certain page. (often BASE_URL/login). This is however something the application itself does. When on the login page, you enter your credentials and if they are wrong, you stay on the same page (with an error); if they are correct a SID cookie is set and you are redirected (again HTTP 302/303) to the main page. Now the main page sees that you are logged in, so it will present you with the main page and will not do a redirect to the login page. In your case, the application does something that you do not expect. - See if you need to configure the domain in the application - See in the network tab of the browser or the logging of the application what redirects are happening. - Search for this specific issue on the internet for that specific piece of software. (chances are you are not the first one). Although you CAN configure redirects in nginx-proxy-manager, this is more suited for a 301 (permanently moved) or a valid 302 (Found) use case. (ex: if you go to "https://support.company.xyz", you get redirected to "https://jira.company.xyz/tickets/new?type=guest"). Nginx is not suited to do any checking of passwords to see if you can log in or not. This is up to the application itself. Does this makes sence to you? My explanation is a bit long, so maybe not that good :-D

kerem commented

2026-02-26 07:36:03 +03:00

Author

Owner

@huntson commented on GitHub (Aug 9, 2024):

I wholeheartedly disagree that this is beyond nginx-proxy-manager. It's quite possible I posed this incorrectly however when using the reverse proxy manager built into my NAS, supposedly based on Squid, fqdn redirects to ip:port for this container and the service loads properly.

interestingly enough things seem to be working today so I'll have to do more research using some of the techniques that you mentioned in order to figure this out.

@huntson commented on GitHub (Aug 9, 2024): I wholeheartedly disagree that this is beyond nginx-proxy-manager. It's quite possible I posed this incorrectly however when using the reverse proxy manager built into my NAS, supposedly based on Squid, fqdn redirects to ip:port for this container and the service loads properly. interestingly enough things seem to be working today so I'll have to do more research using some of the techniques that you mentioned in order to figure this out.

kerem commented

2026-02-26 07:36:03 +03:00

Author

Owner

@phulstaert commented on GitHub (Aug 9, 2024):

I might have been a bit unclear too. When you see the new url, NPM passes it trough. As I understand, you see a redirect url, so this is happing correctly.

What I mean is that it is not up to NPM to decide what url to forward to. That is a function of the application.

An analogy would be "the postal service has nothing to do with what is IN a letter". They are just the messenger.
NPM is a messenger and it passes through a message coming from an application. Even a redirect is in essence "just a message".

@phulstaert commented on GitHub (Aug 9, 2024): I might have been a bit unclear too. When you see the new url, NPM passes it trough. As I understand, you see a redirect url, so this is happing correctly. What I mean is that it is not up to NPM to decide what url to forward to. That is a function of the application. An analogy would be "the postal service has nothing to do with what is IN a letter". They are just the messenger. NPM is a messenger and it passes through a message coming from an application. Even a redirect is in essence "just a message".

kerem commented

2026-02-26 07:36:03 +03:00

Author

Owner

@huntson commented on GitHub (Aug 14, 2024):

Nonetheless, is there a way to do a 'slash' redirect? For example, I want this to proxy service.domain.com to :port/bob.

@huntson commented on GitHub (Aug 14, 2024): Nonetheless, is there a way to do a 'slash' redirect? For example, I want this to proxy service.domain.com to <ip>:port/bob.

kerem commented

2026-02-26 07:36:03 +03:00

Author

Owner

@github-actions[bot] commented on GitHub (Feb 14, 2025):

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

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

Rows
Columns

[GH-ISSUE #3919] Proxy not forwarding to locally-hosted services #2568