[GH-ISSUE #555] Unable to reverse proxy to localhost #468

New issue

Closed

opened 2026-02-26 06:32:57 +03:00 by kerem · 25 comments

kerem commented 2026-02-26 06:32:57 +03:00

Owner

Copy link

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

Checklist

• Please read the setup instructions
• Please read the FAQ

What is troubling you?

I have Nginx Proxy Manager as my 1st point of entry into my Virtual Private Server for 80,443 which then routes out to the various containers I have running on the same server. I have the Forward Hostname / IP set to the IP address of my VPS and the port of the container.

Since Docker exposes all the container ports to the open internet, I want to bind my containers ports to localhost to not have a bunch of ports exposed on my VPS: ie. Port configuration 127.0.0.1:3001 -> 80/tcp

Unfortunately, when I do this, I am no longer able to reverse proxy to my containers. On my VPS, I can verify I am able to access 127.0.0.1:3000 but the reverse proxy no longer works.
I've even tried setting the Forward Hostname/IP and port to 127.0.0.1: but that results in a 502 error.

I figure this is because the nginx reverse proxy container cannot access localhost in that way, but even using the IP address of my VPS no longer works.

Does anyone have a solution?

Originally created by @gururise on GitHub (Aug 12, 2020). Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/555 **Checklist** - Please read the [setup instructions](https://nginxproxymanager.com/setup/) - Please read the [FAQ](https://nginxproxymanager.com/faq/) **What is troubling you?** I have Nginx Proxy Manager as my 1st point of entry into my Virtual Private Server for 80,443 which then routes out to the various containers I have running on the same server. I have the Forward Hostname / IP set to the IP address of my VPS and the port of the container. Since Docker exposes all the container ports to the open internet, I want to bind my containers ports to localhost to not have a bunch of ports exposed on my VPS: ie. Port configuration 127.0.0.1:3001 -> 80/tcp Unfortunately, when I do this, I am no longer able to reverse proxy to my containers. On my VPS, I can verify I am able to access 127.0.0.1:3000 but the reverse proxy no longer works. I've even tried setting the Forward Hostname/IP and port to 127.0.0.1:<PORT> but that results in a 502 error. I figure this is because the nginx reverse proxy container cannot access localhost in that way, but even using the IP address of my VPS no longer works. Does anyone have a solution?

kerem 2026-02-26 06:32:57 +03:00

• closed this issue
• added the
  stale
  product-support
  labels

kerem commented 2026-02-26 06:32:58 +03:00

Author

Owner

Copy link

@gururise commented on GitHub (Aug 15, 2020):

I think I found a solution:

1. Create new docker network
2. Create new container for the service you want to reverse proxy, and only expose the necessary port (ie. no port forwarding).
3. Add nginx-reverse-proxy container and the newly created container to the new network.
4. The host field can now use the IP that is assigned to the container.

Seems to work, is there any problem or security issues with doing it this way?

<!-- gh-comment-id:674342603 --> @gururise commented on GitHub (Aug 15, 2020): I think I found a solution: 1. Create new docker network 2. Create new container for the service you want to reverse proxy, and only expose the necessary port (ie. no port forwarding). 3. Add nginx-reverse-proxy container and the newly created container to the new network. 4. The host field can now use the IP that is assigned to the container. Seems to work, is there any problem or security issues with doing it this way?

kerem commented 2026-02-26 06:32:58 +03:00

Author

Owner

Copy link

@LivingWithHippos commented on GitHub (Aug 20, 2020):

Thanks I was looking for this. I wanted to use my docker containers from a subdomain, without exposing any ports.
Security wise it should be ok because this is also how linuxserver.io letsencrypt container works (but you lose all the sweet nginx manager ui) but I'm still a beginner at this so I wouldn't trust this 100%.

For anyone wanting to do this, e.g. redirecting whoogle.mydomain.tld to your whoogle container, without exposing any port to the network:

1. create a docker network, either by hand or by specifying it in a docker-compose.yml file or by using a default network ( if your docker-compose.yml is in a folder called ngix-manager, _default is appended to it for the network name -> ngix-manager_default, check with docker network ls your networks), also all the services in the same docker-compose.yml or in the same folder get linked to the same network

2. add all the containers you want to manage from nginx manager to the same network (don;t forget nginx manager own network) by appending this into their docker-compose.yml:

version: '2'
services:
  whoogle:
    .....
    networks:
      - ngix-manager_default

networks:
  ngix-manager_default:
    external: true

N.B. : remove all the ports since we don't want to expose them, but note them down

3. Spin up with docker-compose up -d your containers

4. Create a new proxy host in nginx manager, add your subdomain, in forward hostname put your service name (whoogle here) and in forward port the port you noted in step 2 (5000 for whoogle). Add you SSL settings and you're done.

<!-- gh-comment-id:677893307 --> @LivingWithHippos commented on GitHub (Aug 20, 2020): Thanks I was looking for this. I wanted to use my docker containers from a subdomain, without exposing any ports. Security wise it should be ok because this is also how linuxserver.io letsencrypt container works (but you lose all the sweet nginx manager ui) but I'm still a beginner at this so I wouldn't trust this 100%. For anyone wanting to do this, e.g. redirecting `whoogle.mydomain.tld` to your whoogle container, without exposing any port to the network: 1. create a docker network, either by hand or by specifying it in a `docker-compose.yml` file or by using a default network ( if your `docker-compose.yml` is in a folder called ngix-manager, _default is appended to it for the network name -> ngix-manager_default, check with `docker network ls` your networks), also all the services in the same docker-compose.yml or in the same folder get linked to the same network 2. add all the containers you want to manage from nginx manager to the same network (don;t forget nginx manager own network) by appending this into their docker-compose.yml: ``` version: '2' services: whoogle: ..... networks: - ngix-manager_default networks: ngix-manager_default: external: true ``` **N.B. :** remove all the `ports` since we don't want to expose them, but note them down 3. Spin up with `docker-compose up -d` your containers 4. Create a new proxy host in nginx manager, add your subdomain, in forward hostname put your service name (whoogle here) and in forward port the port you noted in step 2 (5000 for whoogle). Add you SSL settings and you're done.

kerem commented 2026-02-26 06:32:58 +03:00

Author

Owner

Copy link

@redtripleAAA commented on GitHub (Aug 30, 2020):

Are you guys having talking about the same issue I just reported?
https://github.com/jc21/nginx-proxy-manager/issues/588

<!-- gh-comment-id:683388041 --> @redtripleAAA commented on GitHub (Aug 30, 2020): Are you guys having talking about the same issue I just reported? https://github.com/jc21/nginx-proxy-manager/issues/588

kerem commented 2026-02-26 06:32:58 +03:00

Author

Owner

Copy link

@gabn88 commented on GitHub (Nov 3, 2020):

@LivingWithHippos @jc21 Thank you sooo much! Have been struggling 2 days to set this up using the nginx-proxy docker image in combination with the letsencrypt-nginx-proxy-companion... And I'm sure I added the network too, but somehow it didn't work. Even with a dozen restarts, etc... Was almost wondering if it was the WSL2 setup breaking things. And now with nginx-proxy-manager in combination with this post it WORKS 🎉 🙇‍♂️

EDIT: Don't mean to blame any other packet with this post. jwilder/nginx-proxy is also a great package. Just like etsencrypt-nginx-proxy-companion. But this packages makes it easier to quickly test some settings!

<!-- gh-comment-id:721340979 --> @gabn88 commented on GitHub (Nov 3, 2020): @LivingWithHippos @jc21 Thank you sooo much! Have been struggling 2 days to set this up using the nginx-proxy docker image in combination with the letsencrypt-nginx-proxy-companion... And I'm sure I added the network too, but somehow it didn't work. Even with a dozen restarts, etc... Was almost wondering if it was the WSL2 setup breaking things. And now with nginx-proxy-manager in combination with this post it WORKS 🎉 🙇‍♂️ EDIT: Don't mean to blame any other packet with this post. jwilder/nginx-proxy is also a great package. Just like etsencrypt-nginx-proxy-companion. But this packages makes it easier to quickly test some settings!

kerem commented 2026-02-26 06:32:58 +03:00

Author

Owner

Copy link

@Sp33dFr34k commented on GitHub (Dec 29, 2020):

I am able to see the login page, but I am unable to actually login (no message, just clears the form) when I try to access Docker containers which are running on the localhost. It works fine when I'm not restricting them with any IP's, but as soon as I do, I see the login screen, but it will not let me login anymore. Tested with Portainer and NPM itself. Running 2.7.1. As soon as I set access back to public again it works. In the IP's I have declared my external IP, my internal range, and I've tried including the Docker network IP's, still doesn't work. Am I missing something?

<!-- gh-comment-id:752276203 --> @Sp33dFr34k commented on GitHub (Dec 29, 2020): I am able to see the login page, but I am unable to actually login (no message, just clears the form) when I try to access Docker containers which are running on the localhost. It works fine when I'm not restricting them with any IP's, but as soon as I do, I see the login screen, but it will not let me login anymore. Tested with Portainer and NPM itself. Running 2.7.1. As soon as I set access back to public again it works. In the IP's I have declared my external IP, my internal range, and I've tried including the Docker network IP's, still doesn't work. Am I missing something?

kerem commented 2026-02-26 06:32:58 +03:00

Author

Owner

Copy link

@ZacKeilholz commented on GitHub (Jan 23, 2021):

@LivingWithHippos @jc21 Thank you sooo much! Have been struggling 2 days to set this up using the nginx-proxy docker image in combination with the letsencrypt-nginx-proxy-companion... And I'm sure I added the network too, but somehow it didn't work. Even with a dozen restarts, etc... Was almost wondering if it was the WSL2 setup breaking things. And now with nginx-proxy-manager in combination with this post it WORKS 🎉 🙇‍♂️

EDIT: Don't mean to blame any other packet with this post. jwilder/nginx-proxy is also a great package. Just like etsencrypt-nginx-proxy-companion. But this packages makes it easier to quickly test some settings!

I'm also using WSL2... I was having a ton of issues/could not get this to work until I defined a network in docker-compose, and applied it to the service, and NPM. I've since deleted the defined network and everything works fine, whereas I was getting 502 errors before.

@LivingWithHippos I'm also a super newb, but I believe instead of trying to remember all of these ports you've removed, you can use expose:

expose:
  - 1234 
  - 56
  - 78

And this is actually a way of documenting the special ports your services need in docker-compose without actually exposing it to the host machine.

<!-- gh-comment-id:766197048 --> @ZacKeilholz commented on GitHub (Jan 23, 2021): > @LivingWithHippos @jc21 Thank you sooo much! Have been struggling 2 days to set this up using the nginx-proxy docker image in combination with the letsencrypt-nginx-proxy-companion... And I'm sure I added the network too, but somehow it didn't work. Even with a dozen restarts, etc... Was almost wondering if it was the WSL2 setup breaking things. And now with nginx-proxy-manager in combination with this post it WORKS 🎉 🙇‍♂️ > > EDIT: Don't mean to blame any other packet with this post. jwilder/nginx-proxy is also a great package. Just like etsencrypt-nginx-proxy-companion. But this packages makes it easier to quickly test some settings! I'm also using WSL2... I was having a ton of issues/could not get this to work until I defined a network in docker-compose, and applied it to the service, and NPM. I've since deleted the defined network and everything works fine, whereas I was getting 502 errors before. @LivingWithHippos I'm also a super newb, but I believe instead of trying to remember all of these ports you've removed, you can use expose: ``` expose: - 1234 - 56 - 78 ``` And this is actually a way of documenting the special ports your services need in docker-compose without actually exposing it to the host machine.

kerem commented 2026-02-26 06:32:58 +03:00

Author

Owner

Copy link

@LivingWithHippos commented on GitHub (Jan 24, 2021):

@ZacKeilholz I started simply commenting out the ports, it's even faster when you use already-made compose files, but it's nice to know expose.

    #ports:
    #  - 8080:2368

Another trick I started using is adding a separate network for the backend service that doesn't need exposition to the proxy.

version: '3.1'

services:
  ghost:
    image: ghost:3-alpine
    ...
    networks:
      - ngix-manager_default
      - backend

  mysql:
    image: mysql:5
    ...
    networks:
      - backend

networks:
  ngix-manager_default:
    external: true
  backend:
    name: ghost_backend
    driver: bridge

<!-- gh-comment-id:766317392 --> @LivingWithHippos commented on GitHub (Jan 24, 2021): @ZacKeilholz I started simply commenting out the ports, it's even faster when you use already-made compose files, but it's nice to know expose. ```yaml #ports: # - 8080:2368 ``` Another trick I started using is adding a separate network for the backend service that doesn't need exposition to the proxy. ```yaml version: '3.1' services: ghost: image: ghost:3-alpine ... networks: - ngix-manager_default - backend mysql: image: mysql:5 ... networks: - backend networks: ngix-manager_default: external: true backend: name: ghost_backend driver: bridge ```

kerem commented 2026-02-26 06:32:58 +03:00

Author

Owner

Copy link

@alexhorner commented on GitHub (Feb 11, 2021):

Hi there,

Whilst adding all of your containers to a network in an option, what would be the best thing to do in a situation where a non-dockerised service is running on the host and exposing a port bound to 127.0.0.1?

An example of such a service could be a server management panel which binds to 127.0.0.1:10000 which I would then like to proxy to a subdomain via NGINX proxy manager.

<!-- gh-comment-id:777790101 --> @alexhorner commented on GitHub (Feb 11, 2021): Hi there, Whilst adding all of your containers to a network in an option, what would be the best thing to do in a situation where a non-dockerised service is running on the host and exposing a port bound to 127.0.0.1? An example of such a service could be a server management panel which binds to 127.0.0.1:10000 which I would then like to proxy to a subdomain via NGINX proxy manager.

kerem commented 2026-02-26 06:32:58 +03:00

Author

Owner

Copy link

@LivingWithHippos commented on GitHub (Feb 11, 2021):

Hi there,

Whilst adding all of your containers to a network in an option, what would be the best thing to do in a situation where a non-dockerised service is running on the host and exposing a port bound to 127.0.0.1?

An example of such a service could be a server management panel which binds to 127.0.0.1:10000 which I would then like to proxy to a subdomain via NGINX proxy manager.

That's just the normal use of nginx proxy manager, you put the subdomain you want and 127.0.0.1:10000 as redirect destination

<!-- gh-comment-id:777792049 --> @LivingWithHippos commented on GitHub (Feb 11, 2021): > Hi there, > > Whilst adding all of your containers to a network in an option, what would be the best thing to do in a situation where a non-dockerised service is running on the host and exposing a port bound to 127.0.0.1? > > An example of such a service could be a server management panel which binds to 127.0.0.1:10000 which I would then like to proxy to a subdomain via NGINX proxy manager. That's just the normal use of nginx proxy manager, you put the subdomain you want and 127.0.0.1:10000 as redirect destination

kerem commented 2026-02-26 06:32:58 +03:00

Author

Owner

Copy link

@alexhorner commented on GitHub (Feb 11, 2021):

Hi there,
Whilst adding all of your containers to a network in an option, what would be the best thing to do in a situation where a non-dockerised service is running on the host and exposing a port bound to 127.0.0.1?
An example of such a service could be a server management panel which binds to 127.0.0.1:10000 which I would then like to proxy to a subdomain via NGINX proxy manager.

That's just the normal use of nginx proxy manager, you put the subdomain you want and 127.0.0.1:10000 as redirect destination

As a simple to reproduce test, I have installed Apache2 on the host machine outside of docker using apt-get, and configured it for 0.0.0.0:8080

If I got to mydomain.com:8080 I am able to sucessfully access the Apache web server, however when proxying http://127.0.0.1:8080 | HTTP only | Public in NGINX proxy manager, the status is Online but I get a 502 Bad Gateway error upon access.

Is this a misconfiguration on my behalf or is something not working?

<!-- gh-comment-id:777799101 --> @alexhorner commented on GitHub (Feb 11, 2021): > > > > Hi there, > > Whilst adding all of your containers to a network in an option, what would be the best thing to do in a situation where a non-dockerised service is running on the host and exposing a port bound to 127.0.0.1? > > An example of such a service could be a server management panel which binds to 127.0.0.1:10000 which I would then like to proxy to a subdomain via NGINX proxy manager. > > That's just the normal use of nginx proxy manager, you put the subdomain you want and 127.0.0.1:10000 as redirect destination As a simple to reproduce test, I have installed Apache2 on the host machine outside of docker using apt-get, and configured it for 0.0.0.0:8080 If I got to mydomain.com:8080 I am able to sucessfully access the Apache web server, however when proxying `http://127.0.0.1:8080 | HTTP only | Public` in NGINX proxy manager, the status is Online but I get a 502 Bad Gateway error upon access. Is this a misconfiguration on my behalf or is something not working?

kerem commented 2026-02-26 06:32:58 +03:00

Author

Owner

Copy link

@LivingWithHippos commented on GitHub (Feb 11, 2021):

My bad, the point of adding nginx to the same network of the service you want to proxy still stands. To let docker see local host you have to play with the network mode. Using network_mode=host won't isolate the docker network from the host network. It works only for Linux. You can also look up host.docker.internal:host-gateway

Untested

<!-- gh-comment-id:777852747 --> @LivingWithHippos commented on GitHub (Feb 11, 2021): My bad, the point of adding nginx to the same network of the service you want to proxy still stands. To let docker see local host you have to play with the network mode. Using network_mode=host won't isolate the docker network from the host network. It works only for Linux. You can also look up host.docker.internal:host-gateway Untested

kerem commented 2026-02-26 06:32:58 +03:00

Author

Owner

Copy link

@alexhorner commented on GitHub (Feb 11, 2021):

I'll give this a try. My only concern is I don't know how secure this would be. I assume if I use host networking, the system firewall will work against the container and allow me to block any ports that should not be exposed on the hosts IP, as I believe internally 3000 is used by nginx proxy manager.

I shall test this tomorrow and reply with my findings, thanks for the suggestion!

<!-- gh-comment-id:777854265 --> @alexhorner commented on GitHub (Feb 11, 2021): I'll give this a try. My only concern is I don't know how secure this would be. I assume if I use host networking, the system firewall will work against the container and allow me to block any ports that should not be exposed on the hosts IP, as I believe internally 3000 is used by nginx proxy manager. I shall test this tomorrow and reply with my findings, thanks for the suggestion!

kerem commented 2026-02-26 06:32:58 +03:00

Author

Owner

Copy link

@alexhorner commented on GitHub (Feb 12, 2021):

I have now tested this and the system firewall properly protects all of the internal ports of NPM, and I am also able to use services proxied through it. Seems all good, will update this issue if I notice any... issues 😂

<!-- gh-comment-id:778356966 --> @alexhorner commented on GitHub (Feb 12, 2021): I have now tested this and the system firewall properly protects all of the internal ports of NPM, and I am also able to use services proxied through it. Seems all good, will update this issue if I notice any... issues 😂

kerem commented 2026-02-26 06:32:58 +03:00

Author

Owner

Copy link

@phocks commented on GitHub (Oct 21, 2022):

In my case I was trying to forward proxy to the host machine that nginx-proxy-manager was running on but using an ssh forward port tunnel. The trick that worked for me was to use the public address of the host and make sure GatewayPorts is set to clientspecified in the sshd config /etc/ssh/sshd_config and had to make sure my host and port was accessible from the internet.

https://superuser.com/a/591963/373302

Probably not the best way to do it, but it worked.

<!-- gh-comment-id:1286356844 --> @phocks commented on GitHub (Oct 21, 2022): In my case I was trying to forward proxy to the host machine that nginx-proxy-manager was running on but using an ssh forward port tunnel. The trick that worked for me was to use the public address of the host and make sure `GatewayPorts` is set to `clientspecified` in the sshd config `/etc/ssh/sshd_config` and had to make sure my host and port was accessible from the internet. https://superuser.com/a/591963/373302 Probably not the best way to do it, but it worked.

kerem commented 2026-02-26 06:32:58 +03:00

Author

Owner

Copy link

@skironDotNet commented on GitHub (Nov 25, 2022):

I think the "problem" is understanding, so when you try to forward 127.0.0.1, what you are telling NPM is to use localhost OF THE NPM CONTAINER and nothing is hosted there, but you are thinking to forward localhost of the host machine. Try this to confirm thinking docker exec -it <npm-container> bash and then curl 127.0.0.1:port you'll see there is nothing there.
I have no answer how to access host's localhost inside of npm container. Obviously docker networking must be involved

<!-- gh-comment-id:1327136602 --> @skironDotNet commented on GitHub (Nov 25, 2022): I think the "problem" is understanding, so when you try to forward 127.0.0.1, what you are telling NPM is to use localhost OF THE NPM CONTAINER and nothing is hosted there, but you are thinking to forward localhost of the host machine. Try this to confirm thinking `docker exec -it <npm-container> bash` and then `curl 127.0.0.1:port` you'll see there is nothing there. I have no answer how to access host's localhost inside of npm container. Obviously docker networking must be involved

kerem commented 2026-02-26 06:32:58 +03:00

Author

Owner

Copy link

@alexhorner commented on GitHub (Nov 25, 2022):

I think the "problem" is understanding, so when you try to forward 127.0.0.1, what you are telling NPM is to use localhost OF THE NPM CONTAINER and nothing is hosted there, but you are thinking to forward localhost of the host machine. Try this to confirm thinking docker exec -it <npm-container> bash and then curl 127.0.0.1:port you'll see there is nothing there.
I have no answer how to access host's localhost inside of npm container. Obviously docker networking must be involved

Hello, I am now two years older and wiser since I last replied to this issue.

The way to do it on Windows and macOS is to use the domain host.docker.internal to access services on the host machine.

As of the time of this reply, host.docker.internal is not supported on Linux hosts, so my previous reply of using host networking mode is the only workaround I'm aware of.

I no longer use NPM, I have learned it is mostly always easier to just write the NGINX config myself. It's really not as scary as people think, and quite easy to learn, and a lot more reliable and flexible.

<!-- gh-comment-id:1327140950 --> @alexhorner commented on GitHub (Nov 25, 2022): > I think the "problem" is understanding, so when you try to forward 127.0.0.1, what you are telling NPM is to use localhost OF THE NPM CONTAINER and nothing is hosted there, but you are thinking to forward localhost of the host machine. Try this to confirm thinking `docker exec -it <npm-container> bash` and then `curl 127.0.0.1:port` you'll see there is nothing there. > I have no answer how to access host's localhost inside of npm container. Obviously docker networking must be involved Hello, I am now two years older and wiser since I last replied to this issue. The way to do it on Windows and macOS is to use the domain `host.docker.internal` to access services on the host machine. As of the time of this reply, `host.docker.internal` is not supported on Linux hosts, so my previous reply of using host networking mode is the only workaround I'm aware of. I no longer use NPM, I have learned it is mostly always easier to just write the NGINX config myself. It's really not as scary as people think, and quite easy to learn, and a lot more reliable and flexible.

kerem commented 2026-02-26 06:32:58 +03:00

Author

Owner

Copy link

@skironDotNet commented on GitHub (Nov 25, 2022):

I was answering for other noobs like me who host from VPS :) Another info. Let say we have a domain.net
when we run containers in default port 8080:80 then we expose 8080 to the public because bind is to 0.0.0.0 so can access domain.net:8080 (I know this if funny basics to the gurus) so one may want to run docker port 127.0.0.1:8080:80 to bind to host's internal network thus prevent exposing domain.net:8080 the desired thing, and we are going back to original "Unable to reverse proxy to localhost". So in order not to expose a port to the public and to be able to host via NPM, we can run a container bind to docker0 and by default this is 172.17.0.1 so can run a container port 172.17.0.1:8080:80, this way we bind to docker0 that is not exposed to the public (at least should not be) but then NPM can access it, so we create forward proxy for 172.17.0.1:8080

But if run UFW you must add port 8080 otherwise NPM still won't be able to connect, and this is strange because "normally" docker containers ignore UFW firewall

hope this will help someone at least to understand the basics of networking (I'm still learning :/)

<!-- gh-comment-id:1327162608 --> @skironDotNet commented on GitHub (Nov 25, 2022): I was answering for other noobs like me who host from VPS :) Another info. Let say we have a domain.net when we run containers in default port 8080:80 then we expose 8080 to the public because bind is to 0.0.0.0 so can access domain.net:8080 (I know this if funny basics to the gurus) so one may want to run docker port 127.0.0.1:8080:80 to bind to host's internal network thus prevent exposing domain.net:8080 the desired thing, and we are going back to original "Unable to reverse proxy to localhost". So in order not to expose a port to the public and to be able to host via NPM, we can run a container bind to **docker0** and by default this is 172.17.0.1 so can run a container port 172.17.0.1:8080:80, this way we bind to docker0 that is not exposed to the public (at least should not be) but then NPM can access it, so we create forward proxy for 172.17.0.1:8080 But if run UFW you must add port 8080 otherwise NPM still won't be able to connect, and this is strange because "normally" docker containers ignore UFW firewall hope this will help someone at least to understand the basics of networking (I'm still learning :/)

kerem commented 2026-02-26 06:32:58 +03:00

Author

Owner

Copy link

@alexhorner commented on GitHub (Nov 25, 2022):

I was answering for other noobs like me who host from VPS :) Another info. Let say we have a domain.net
when we run containers in default port 8080:80 then we expose 8080 to the public because bind is to 0.0.0.0 so can access domain.net:8080 (I know this if funny basics to the gurus) so one may want to run docker port 127.0.0.1:8080:80 to bind to host's internal network thus prevent exposing domain.net:8080 the desired thing, and we are going back to original "Unable to reverse proxy to localhost". So in order not to expose a port to the public and to be able to host via NPM, we can run a container bind to docker0 and by default this is 172.17.0.1 so can run a container port 172.17.0.1:8080:80, this way we bind to docker0 that is not exposed to the public (at least should not be) but then NPM can access it, so we create forward proxy for 172.17.0.1:8080

But if run UFW you must add port 8080 otherwise NPM still won't be able to connect, and this is strange because "normally" docker containers ignore UFW firewall

hope this will help someone at least to understand the basics of networking (I'm still learning :/)

I can't exactly say this is a method I have tested before, but binding to 127.0.0.1 definitely is, and I'd still recommend host networking mode when doing that personally.

Less complex, pretty sure it doesn't have negative implications when compared to the other method you laid out. I'd love to know if it does though.

<!-- gh-comment-id:1327189533 --> @alexhorner commented on GitHub (Nov 25, 2022): > I was answering for other noobs like me who host from VPS :) Another info. Let say we have a domain.net > when we run containers in default port 8080:80 then we expose 8080 to the public because bind is to 0.0.0.0 so can access domain.net:8080 (I know this if funny basics to the gurus) so one may want to run docker port 127.0.0.1:8080:80 to bind to host's internal network thus prevent exposing domain.net:8080 the desired thing, and we are going back to original "Unable to reverse proxy to localhost". So in order not to expose a port to the public and to be able to host via NPM, we can run a container bind to **docker0** and by default this is 172.17.0.1 so can run a container port 172.17.0.1:8080:80, this way we bind to docker0 that is not exposed to the public (at least should not be) but then NPM can access it, so we create forward proxy for 172.17.0.1:8080 > > But if run UFW you must add port 8080 otherwise NPM still won't be able to connect, and this is strange because "normally" docker containers ignore UFW firewall > > hope this will help someone at least to understand the basics of networking (I'm still learning :/) I can't exactly say this is a method I have tested before, but binding to 127.0.0.1 definitely is, and I'd still recommend host networking mode when doing that personally. Less complex, pretty sure it doesn't have negative implications when compared to the other method you laid out. I'd love to know if it does though.

kerem commented 2026-02-26 06:32:58 +03:00

Author

Owner

Copy link

@noize-e commented on GitHub (Mar 31, 2023):

I like the NPM interface and the easy security certification setup with Let's Encrypt so I didn't want to get rid of it. So the following steps describe the solution that worked for me.

1. Create a new network in docker: docker network create npmnet
2. Add the npmnet network as the default one in the docker-compose.yml file from NPM and every service managed by it.

version: '3'

# ...service parameters

networks:
  default:
    external: true
    name: npmnet

3. Dont forget to remove even the ports or the expose attributes from the same file.
4. Restart NPM and all the other services:

docker compose down && docke compose up -d ;

5. Inspect the network to verify that the services are linked

docker network inspect npmnet

You will see something like

[
    {
        "Name": "npmnet",
        ...
        "Containers": {
            "....": {
                "Name": "service-1",
                "EndpointID": "...",
                "MacAddress": "...",
                "IPv4Address": "172.20.0.2/16",
                "IPv6Address": ""
            },
            "....": {
                "Name": "service-2",
                "EndpointID": "...",
                "MacAddress": "...",
                "IPv4Address": "172.20.0.3/16",
                "IPv6Address": ""
            },
            "....": {
                "Name": "npm",
                "EndpointID": "...",
                "MacAddress": "...",
                "IPv4Address": "172.20.0.5/16",
                "IPv6Address": ""
            }
        },
        ...
    }
]

As you can see each service has assigned an IP in the same subnetwork. You can verify it by accessing the NPM container and ping any service in the same network.
6. Now, log in to the NPM's dashboard and for every proxy already setup change the Forward Hostname / IP* to the one defined in the npmnet network, for example for service-1 the IP should be 172.20.0.3 and the Forward Port * to 80.

That's it, the services are isolated to only the bridge docker network.

Note! Just to ensure everything is set up correctly I would run a port scan with nmap.

<!-- gh-comment-id:1491263462 --> @noize-e commented on GitHub (Mar 31, 2023): I like the NPM interface and the easy security certification setup with Let's Encrypt so I didn't want to get rid of it. So the following steps describe the solution that worked for me. 1. Create a new network in docker: `docker network create npmnet` 2. Add the __npmnet__ network as the default one in the `docker-compose.yml` file from NPM and every service managed by it. ```yaml version: '3' # ...service parameters networks: default: external: true name: npmnet ``` 3. Dont forget to remove even the __`ports`__ or the __`expose`__ attributes from the same file. 4. Restart NPM and all the other services: ```bash docker compose down && docke compose up -d ; ``` 5. Inspect the network to verify that the services are linked ```bash docker network inspect npmnet ``` You will see something like ```json [ { "Name": "npmnet", ... "Containers": { "....": { "Name": "service-1", "EndpointID": "...", "MacAddress": "...", "IPv4Address": "172.20.0.2/16", "IPv6Address": "" }, "....": { "Name": "service-2", "EndpointID": "...", "MacAddress": "...", "IPv4Address": "172.20.0.3/16", "IPv6Address": "" }, "....": { "Name": "npm", "EndpointID": "...", "MacAddress": "...", "IPv4Address": "172.20.0.5/16", "IPv6Address": "" } }, ... } ] ``` As you can see each service has assigned an IP in the same subnetwork. You can verify it by accessing the NPM container and ping any service in the same network. 6. Now, log in to the NPM's dashboard and for every proxy already setup change the `Forward Hostname / IP*` to the one defined in the __npmnet__ network, for example for __`service-1`__ the IP should be __`172.20.0.3`__ and the `Forward Port *` to __`80`__. That's it, the services are isolated to only the bridge docker network. > __Note!__ Just to ensure everything is set up correctly I would run a port scan with nmap.

kerem commented 2026-02-26 06:32:58 +03:00

Author

Owner

Copy link

@AlanMW commented on GitHub (Nov 6, 2023):

I've had everything working smoothly for months but am now getting a 504 error and a upstream timed out (110: Connection timed out) while connecting to upstream error. Previously I was just directing NPM to my computers IP:Port, but now all of a sudden it doesn't work. host.docker.internal does work for local containers, but what about containers that are on different machines on the same network? For some reason NPM doesn't see any other computers on my local network.

<!-- gh-comment-id:1794330290 --> @AlanMW commented on GitHub (Nov 6, 2023): I've had everything working smoothly for months but am now getting a 504 error and a `upstream timed out (110: Connection timed out) while connecting to upstream` error. Previously I was just directing NPM to my computers IP:Port, but now all of a sudden it doesn't work. `host.docker.internal` does work for local containers, but what about containers that are on different machines on the same network? For some reason NPM doesn't see any other computers on my local network.

kerem commented 2026-02-26 06:32:58 +03:00

Author

Owner

Copy link

@Xav-v commented on GitHub (Mar 14, 2024):

Just a small tip I'm using now. Probably not the best, but at least I could re-configure easily IPs at once for many hosts.

Creating a file under data/nginx/custom/http_top.conf:
map $host $server { default "172.17.0.1"; }
map $host $otherhost { default "xx.xx.xx.xx"; }

Then using $server or $otherhost as the variable of each "Forward Hostname / IP".
Same applies in case you have a distant IP (e.g using with Tailscale IPs without any issue)

<!-- gh-comment-id:1997209165 --> @Xav-v commented on GitHub (Mar 14, 2024): Just a small tip I'm using now. Probably not the best, but at least I could re-configure easily IPs at once for many hosts. Creating a file under `data/nginx/custom/http_top.conf`: `map $host $server { default "172.17.0.1"; }` `map $host $otherhost { default "xx.xx.xx.xx"; }` Then using `$server` or `$otherhost` as the variable of each "Forward Hostname / IP". Same applies in case you have a distant IP (e.g using with Tailscale IPs without any issue)

kerem commented 2026-02-26 06:32:58 +03:00

Author

Owner

Copy link

@nikhilweee commented on GitHub (Jun 2, 2024):

Just came here to say that @LivingWithHippos's solution worked like a charm, except when I was setting up Immich where I had to add the default network in addition to NPM's default network in immich-server's network section.

version: '2'
services:
  whoogle:
    .....
    networks:
      - default # had to add this
      - ngix-manager_default

networks:
  ngix-manager_default:
    external: true

<!-- gh-comment-id:2144048660 --> @nikhilweee commented on GitHub (Jun 2, 2024): Just came here to say that @LivingWithHippos's [solution](https://github.com/NginxProxyManager/nginx-proxy-manager/issues/555#issuecomment-677893307) worked like a charm, except when I was setting up [Immich](https://github.com/immich-app/immich) where I had to add the `default` network in addition to NPM's default network in `immich-server`'s network section. ```yaml version: '2' services: whoogle: ..... networks: - default # had to add this - ngix-manager_default networks: ngix-manager_default: external: true ```

kerem commented 2026-02-26 06:32:58 +03:00

Author

Owner

Copy link

@tooty-1135 commented on GitHub (Jun 5, 2024):

just addnetwork_mode: host in docker-compose.yml

version: '3.8'
services:
  app:
    ports:
      ...

    # add this
    network_mode: host

and run ufw allow 81

it works for me

<!-- gh-comment-id:2148712102 --> @tooty-1135 commented on GitHub (Jun 5, 2024): just add`network_mode: host` in docker-compose.yml ```yml version: '3.8' services: app: ports: ... # add this network_mode: host ``` and run `ufw allow 81` it works for me

kerem commented 2026-02-26 06:32:58 +03:00

Author

Owner

Copy link

@github-actions[bot] commented on GitHub (Dec 19, 2024):

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

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

kerem commented 2026-02-26 06:32:58 +03:00

Author

Owner

Copy link

@github-actions[bot] commented on GitHub (Jan 2, 2026):

Issue was closed due to inactivity.

<!-- gh-comment-id:3704340235 --> @github-actions[bot] commented on GitHub (Jan 2, 2026): Issue was closed due to inactivity.

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#468

No description provided.