Nginx als Reverse Proxy Hub

1. Warum ein zentraler Reverse Proxy sinnvoll ist

Ein Reverse Proxy bündelt Funktionen, die man nicht in jeder einzelnen Anwendung neu konfigurieren möchte: TLS-Terminierung, Hostname-Routing, Redirects, Sicherheitsheader, Rate Limiting und oft auch Basis-Authentifizierung.

Gerade im Homelab oder in kleinen Self-Hosted-Umgebungen ist ein zentraler Proxy ein echter Stabilitätsgewinn:

  • einheitliche Zertifikats- und Header-Strategie,
  • klare Hostnamen pro Dienst,
  • saubere Trennung zwischen Internetkante und internen Backends,
  • bessere Logs und einfacheres Incident Handling.

2. Architektur und Namensmodell

Das wichtigste Designstück ist nicht Nginx selbst, sondern das Namensmodell. Ein zentraler Proxy funktioniert am besten, wenn jede Anwendung eine eindeutige Subdomain besitzt:

  • grafana.example.com
  • git.example.com
  • auth.example.com

Diese Struktur ist robuster als viele Pfad-basierte Konstrukte wie example.com/grafana, weil Anwendungen bei Redirects, Cookies und WebSockets oft deutlich besser mit eigenen Hostnamen umgehen.

Bewährtes Muster:

  • öffentlich erreichbarer Reverse Proxy in einem dedizierten Segment,
  • Backends nur intern erreichbar,
  • DNS zeigt ausschließlich auf den Proxy, nicht direkt auf Applikationen,
  • Firewall-Regeln erlauben nur notwendige Backend-Verbindungen.

3. Eine saubere Nginx-Basiskonfiguration

Gute Nginx-Setups bestehen aus kleinen, wiederverwendbaren Bausteinen: globalen Defaults, separaten Server-Blöcken pro Dienst und klaren Includes für Header, Rate Limits oder Auth. 

server {
    listen 80;
    server_name grafana.example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name grafana.example.com;

    ssl_certificate     /etc/letsencrypt/live/grafana/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/grafana/privkey.pem;

    location / {
        proxy_pass http://192.168.10.40:3000;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Drei Regeln sparen später viel Ärger:

  • Vor jedem Reload: nginx -t.
  • Keine Copy-Paste-Monster: gemeinsame Header und Timeouts in Includes auslagern.
  • Backends explizit dokumentieren: Hostname, Port, Health-URL, Auth-Methode.

4. TLS, Header und sichere Defaults

TLS-Terminierung ist häufig der Hauptgrund für den Einsatz eines Reverse Proxys. Deshalb sollte dieser Bereich besonders sauber umgesetzt sein:

  • HTTP konsequent auf HTTPS umleiten,
  • Zertifikate automatisiert erneuern,
  • Security Header zentral pflegen,
  • interne und externe Vertrauensdomänen bewusst trennen.
add_header X-Frame-Options SAMEORIGIN always;
add_header X-Content-Type-Options nosniff always;
add_header Referrer-Policy no-referrer-when-downgrade always;
add_header Permissions-Policy "interest-cohort=()" always;

HSTS ist sinnvoll, aber nur dann, wenn der betroffene Host wirklich dauerhaft per HTTPS erreichbar bleibt. Für interne Testsysteme oder wechselnde Lab-Domains kann ein zu aggressives HSTS-Setup schnell lästig werden.

5. Anwendungen korrekt anbinden

Nicht jede Anwendung verhält sich hinter einem Proxy gleich. Typische Stolpersteine sind:

  • WebSockets: benötigt passende Upgrade-Header.
  • Große Uploads: client_max_body_size anpassen.
  • Long Polling oder Streams: Timeouts und Buffering prüfen.
  • Apps mit eigener URL-Basis: Basis-URL oder Root-URL in der Anwendung korrekt setzen.
location /api/live/ {
    proxy_pass http://192.168.10.40:3000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

Besonders wichtig ist der Header X-Forwarded-Proto. Ohne ihn erzeugen Anwendungen hinter TLS- Terminierung oft fehlerhafte Redirects oder setzen Cookies nicht korrekt.

6. Schutzmechanismen für exponierte Dienste

Ein Reverse Proxy ist ein guter Ort für Basisschutz, ersetzt aber keine Segmentierung und keine Anwendungs-Härtung. Sinnvolle Maßnahmen am Proxy:

  • Rate Limiting gegen triviale Abuse-Muster,
  • BasicAuth oder SSO-Vorschaltung für Admin-Oberflächen,
  • IP-Allowlisting für besonders sensible Dienste,
  • Fail2ban auf Basis von Nginx-Logs.
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

location /login {
    limit_req zone=login burst=10 nodelay;
    proxy_pass http://192.168.10.50:8080;
}

Für Dienste wie Grafana, Proxmox oder Gitea ist es oft sinnvoller, sie nicht vollständig öffentlich zu machen, sondern nur via VPN oder zusätzlicher Authentifizierung zugänglich zu halten.

7. Betrieb, Updates und Logging

Ein Proxy ist ein Single Point of Visibility und oft auch ein Single Point of Failure. Deshalb gehören Betrieb und Pflege zu den Pflichtaufgaben:

  • Zertifikats-Erneuerung überwachen.
  • Nginx-Konfiguration vor Deployments testen.
  • Access- und Error-Logs zentral sammeln.
  • Reverse Proxy selbst per Blackbox-Checks überwachen.
nginx -t
systemctl reload nginx
journalctl -u nginx --since "-30 min"

Access-Logs sind besonders hilfreich, wenn man sie mit Upstream-Response-Time und Statuscode auswertet. Dann sieht man schnell, ob der Fehler am Backend, an TLS, an einer falschen Host-Zuordnung oder an Timeouts liegt.

8. Troubleshooting

Reverse-Proxy-Probleme lassen sich meist in vier Klassen einteilen: DNS zeigt falsch, TLS ist defekt, Nginx erreicht das Backend nicht oder die Anwendung erwartet andere Header/URLs. Eine feste Prüfreihenfolge hilft:

  1. Zeigt DNS wirklich auf den Proxy?
  2. Ist das Zertifikat gültig und passt zum Hostnamen?
  3. Antwortet das Backend direkt ohne Proxy?
  4. Sieht die Anwendung die korrekten Forwarded-Header?
curl -I https://grafana.example.com
curl -I http://192.168.10.40:3000
openssl s_client -connect grafana.example.com:443 -servername grafana.example.com
nginx -t

Typische Fehlerbilder:

  • 502 Bad Gateway: Backend-Port, DNS-Auflösung oder Firewall zwischen Proxy und App prüfen.
  • Redirect-Loop: meist fehlendes X-Forwarded-Proto oder falsche Base-URL.
  • WebSocket bricht ab: Upgrade-Header oder Timeouts fehlen.
  • Nur große Uploads scheitern: client_max_body_size oder Backend-Limit zu klein.

9. Zusammenfassung

Nginx als zentraler Reverse Proxy ist im Self-Hosted-Umfeld ein sehr wirkungsvoller Baustein. Er schafft Ordnung an der Internetkante, vereinheitlicht TLS und reduziert Konfigurationswildwuchs in den Anwendungen.

Der größte Gewinn entsteht aber nicht durch einzelne Direktiven, sondern durch klares Namensmodell, kleine wiederverwendbare Konfigurationen und sauberen Betrieb mit Logs, Tests und Monitoring.