Why we put internal web apps behind Nginx Proxy Manager instead of port forwards

A lot of the small offices we pick up have a firewall with a pile of port forwards on it. 8443 goes to one server, 8080 to another, 9000 to a third, and nobody remembers which is which. Each of those services faces the internet with its own TLS settings, or none. A reverse proxy cleans that up. You get one public IP, only ports 80 and 443 open, routing by hostname, and certificates managed in one place. We use Nginx Proxy Manager (NPM) for a lot of this because it puts a usable GUI on top of plain nginx, which helps when the next tech to touch it isn't an nginx person. Below is how we set it up, plus the client IP and redirect loop problems that catch everyone.

Getting NPM running

services:
  npm:
    image: jc21/nginx-proxy-manager:latest
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
      - "81:81"     # admin UI - do NOT expose this publicly
    volumes:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt

Once it's in production, pin a specific image version so an update doesn't surprise you. Port 81 is the admin UI, so restrict it with the host firewall to your management network or VPN. Log in, change the default credentials right away, and back up the data and letsencrypt folders.

One proxy host per app

For each app, create a proxy host with the public hostname and the internal scheme, IP and port (for example http://10.10.50.20:8080), and turn on "Block common exploits." Turn on WebSockets support for anything with live updates, like dashboards, remote consoles or chat. NPM routes on the Host header, so dozens of apps can share the same IP and port 443.

Lock the backends down as well. The app servers should only accept connections from the proxy's IP. Otherwise anyone on the internal network can walk right around whatever the proxy enforces.

Certificates, HTTP-01 or DNS-01

With HTTP-01, Let's Encrypt connects to http://hostname/.well-known/acme-challenge/. Port 80 has to be reachable from the internet and the DNS record has to point at the proxy. It's simple, but you get no wildcards, and it won't work for hostnames that are internal-only.

With DNS-01, NPM creates a TXT record through your DNS provider's API. That works for wildcards (*.example.com), for internal-only hosts, and when port 80 is blocked. The cost is an API token sitting on the proxy, so scope it to DNS edit on the specific zone.

Then turn on "Force SSL," and once you're sure everything works over HTTPS, turn on HSTS too.

Getting the real client IP to the backend

Skip this and every request in the app's logs comes from the proxy's IP. That wrecks your auditing and rate limiting, and tools like fail2ban will end up banning the proxy, which means banning everyone behind it. NPM sends X-Forwarded-For, X-Real-IP and X-Forwarded-Proto by default. The backend has to be told to trust those headers only from the proxy. If the backend runs nginx, it looks like this.

# On the backend server, in the http or server block
set_real_ip_from 10.10.50.5;      # the NPM host's IP
real_ip_header   X-Forwarded-For;
real_ip_recursive on;

If something else sits in front of NPM, such as a CDN or cloud proxy, NPM also needs set_real_ip_from entries for that provider's published ranges and the provider's client IP header. Add them in the proxy host's Advanced tab or a custom include. Never trust X-Forwarded-For from just anywhere, because clients can set it to whatever they like.

Apps that aren't behind nginx have their own setting, usually called "trusted proxies" (Laravel, Nextcloud, and many Node and Python frameworks). Set it to the proxy IP, not to "everything."

The "too many redirects" loop

The browser talks HTTPS to NPM, and NPM usually talks plain HTTP to the backend. An app that enforces HTTPS sees a plain HTTP request and redirects to HTTPS. The browser comes back through the proxy, the app sees HTTP again, and around it goes until the browser gives up with "too many redirects." You fix it by making the app honor X-Forwarded-Proto: https from the trusted proxy. A few examples:

• In Nextcloud, set overwriteprotocol to https and fill in trusted_proxies in config.php.
• In Django, set SECURE_PROXY_SSL_HEADER = ("HTTP_X_FORWARDED_PROTO", "https").
• In Laravel, configure the TrustProxies middleware with the proxy IP.
• For anything else, set the app's "base URL" or "external URL" to https://app.example.com.

# Certificate and redirect chain from outside your network
curl -sI http://app.example.com | head -n 5
curl -svI https://app.example.com 2>&1 | grep -Ei "subject|expire|HTTP/"

# Confirm only 80/443 are open on the public IP (run from outside)
nmap -Pn -p 1-10000 192.0.2.10

Once it's set up right, the proxy is about the most boring box we run, and I mean that as a compliment.