Proxy not forwarding to locally-hosted services

[huntson]

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

[phulstaert]

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?

[huntson]

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.

[phulstaert]

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)

[huntson]

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.

[phulstaert]

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?

[huntson]

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?

[phulstaert]

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

[huntson]

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.

[phulstaert]

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".

[huntson]

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

[github-actions[bot]]

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