I'm trying to route traffic to a Grimmory container through Nginx Proxy Manager without publishing Grimmory's application port on the Docker host. Previously, the Compose configuration published port 6060 on 0.0.0.0, which made the service reachable directly from the server's public IP. I want only Nginx Proxy Manager to expose ports 80 and 443, keeping the application itself private.
Nginx Proxy Manager is attached to an external Docker bridge network named `proxy`. Grimmory is attached to both `proxy` and an internal `grimmory_stack` network, while MariaDB is attached only to `grimmory_stack`. The Grimmory container listens on port 6060, and I have removed the host port mapping. I also tried using `expose: 6060`, but Nginx Proxy Manager still returns a 504 gateway timeout.
I have tried configuring the proxy destination as the Grimmory container IP, the container name, `grimmory.network`, and `localhost:6060`. What is the correct Docker and Nginx Proxy Manager configuration for this setup, and how can I troubleshoot whether Grimmory is listening on the correct interface?
3 Answers
The two-network design is reasonable. Grimmory can be on both networks so it can talk to MariaDB through `grimmory_stack` and receive proxy traffic through `proxy`; MariaDB should remain only on the private network. Marking `grimmory_stack` as `internal: true` prevents external access through that network, while the shared proxy network is still needed for Nginx Proxy Manager to connect to Grimmory.
Use the Compose service name, preferably `grimmory`, rather than a hard-coded container IP. Container IPs can change when the service is recreated. Also make sure the proxy network is genuinely the same external network in both Compose projects and verify membership with `docker network inspect proxy`.
A 504 usually means Nginx Proxy Manager is reachable but cannot establish a timely connection to the upstream. Check the basics from inside the proxy container: resolve the name, connect to port 6060, and call the health endpoint. For example: `docker exec -it nginx-proxy-app-1 sh`, then try `wget -qO- http://grimmory:6060/api/v1/healthcheck`.
If name resolution works but the connection is refused or times out, inspect Grimmory’s logs and listening address. If the request works from the proxy container, use `grimmory` and `6060` in the proxy host configuration and avoid adding `http://`, a path, or the host’s IP to the forward hostname field.
Since Nginx Proxy Manager and Grimmory are both connected to the `proxy` network, the proxy host should use `grimmory` as the forward hostname and `6060` as the forward port. Do not use `localhost`, because from inside the Nginx Proxy Manager container that means Nginx Proxy Manager itself. You also do not need a host port mapping or `expose`; containers on the same Docker network can reach each other directly on the application port.
Your Grimmory service should have no `ports:` section, and something like `expose: 6060` is optional documentation rather than a security mechanism. Docker’s internal DNS should resolve the service name, provided both containers were recreated after joining the shared network. From the Nginx Proxy Manager container, test it with `getent hosts grimmory` and `curl http://grimmory:6060/api/v1/healthcheck`. If that curl fails, the problem is Docker connectivity or Grimmory itself rather than the reverse-proxy settings.
The application also needs to listen on `0.0.0.0:6060` inside its container, not only on `127.0.0.1`. Listening on localhost inside the container would make it reachable by the health check from that same container but not by Nginx Proxy Manager. You can inspect this with `docker exec grimmory ss -lntp` or `docker exec grimmory netstat -lntp`, depending on which tools are installed.