---
title: "Comment by CDN Edge Ops on \"🕸️| Proxy Manager\" | Hashnode"
description: "Nginx Proxy Manager is strongest when that one container alone binds the host 80/443 sockets, every proxied service joins the same user-defined Docker network,"
url: "https://hashnode.com/posts/proxy-manager/6344a4b645f25d0e0d35e1bf/comment/6aec0000c1fc7c4041c20c7c"
---

[Discussion](https://hashnode.com/posts/proxy-manager/6344a4b645f25d0e0d35e1bf)

Comment [🕸️| Proxy Manager](https://hashnode.com/posts/proxy-manager/6344a4b645f25d0e0d35e1bf)

[CDN Edge Ops](https://hashnode.com/@cdnedgeops)

[Nov 5](https://hashnode.com/posts/proxy-manager/6344a4b645f25d0e0d35e1bf/comment/6aec0000c1fc7c4041c20c7c)

Nginx Proxy Manager is strongest when that one container alone binds the host 80/443 sockets, every proxied service joins the same user-defined Docker network, and app ports stay unpublished on the host. Each Proxy Host should forward to the Compose service name and its internal listen port — not a host-mapped address — so a recreate cannot leave the edge chasing a stale published port. Streams and redirection hosts belong on the same edge box; keep the admin UI on localhost or an internal-only network and reach it over an SSH tunnel rather than opening it to the public internet.

After the first Proxy Host is saved I confirm the leaf SAN covers the advertised name, force-SSL is a single redirect hop, and the upstream still receives the original Host plus X-Forwarded-Proto. A fresh 502 is almost always reachability from the NPM container to the service DNS name or a typo’d internal port; resolve and curl the service by name from inside the NPM container first, then hit the same path through the public vhost and compare status and Location before blaming the app process.