- Nginx Proxy Manager (NPM) verwaltet Reverse-Proxy-Regeln und Let’s-Encrypt-Zertifikate über eine Weboberfläche statt über Konfigurationsdateien – ideal für Einsteiger im Homelab.
- Die Admin-Oberfläche läuft standardmäßig auf Port 81, nicht auf 80 oder 443 – das verwechseln viele beim ersten Aufruf.
- Let’s Encrypt verkürzt die Laufzeit von TLS-Zertifikaten in den nächsten Jahren drastisch. Wer bisher Zertifikate von Hand erneuert hat, kommt an der Automatisierung künftig kaum noch vorbei.
- Die Standard-Zugangsdaten nach der Installation solltest du als allerersten Schritt ändern – nicht „irgendwann später“.
Wer im Homelab mehr als zwei oder drei Dienste laufen hat – etwa eine Nextcloud, einen Mediaserver und ein Dashboard – kennt das Problem: Jeder Dienst hängt an einem eigenen Port, und man merkt sich ständig, ob es nun :8080 oder :9000 war. Ein Reverse Proxy löst das: Er sitzt vor allen Diensten, nimmt Anfragen unter einer sauberen Adresse wie cloud.meinedomain.de entgegen und leitet sie intern an den richtigen Dienst weiter. Nach außen sieht man nur noch eine Adresse und ein gültiges Schloss-Symbol im Browser.
Genau dafür gibt es Nginx Proxy Manager (NPM) – ein Docker-Container mit grafischer Oberfläche, der Reverse-Proxy-Regeln, automatische Zertifikate und Zugriffslisten verwaltet, ohne dass du eine einzige Konfigurationsdatei von Hand bearbeiten musst.
Was steckt technisch hinter Nginx Proxy Manager?
Der Name ist etwas irreführend: Unter der Haube läuft nicht das reine Nginx, sondern OpenResty – eine Erweiterung von Nginx um die Skriptsprache Lua. Das erklärt, warum NPM Dinge kann, die ein einfaches Nginx nicht ohne weiteres bietet, etwa die dynamische Verwaltung der Proxy-Regeln über die Oberfläche statt über statische Textdateien. Für die tägliche Nutzung macht das keinen Unterschied, ist aber gut zu wissen, wenn du später mal tiefer in die Fehlersuche musst.
Das Projekt liegt heute unter der GitHub-Organisation NginxProxyManager (ursprünglich beim Nutzer jc21 gestartet) und befindet sich weiterhin in der 2.x-Reihe. Ein für Version 3 geplantes komplettes Rewrite mit neuem Unterbau ist seit Jahren angekündigt, aber ohne verlässlichen Termin – v2 gilt offiziell als nicht mehr aktiv weiterentwickelt, wird aber weiterhin mit wichtigen Fehlerbehebungen versorgt. Für den produktiven Einsatz ist sie nach wie vor die empfohlene Wahl.
Installation per Docker Compose
Vorausgesetzt, Docker läuft bereits auf deinem Server, reicht eine kurze docker-compose.yml:
services:
npm:
image: 'jc21/nginx-proxy-manager:latest'
restart: unless-stopped
ports:
- '80:80'
- '443:443'
- '81:81'
volumes:
- ./data:/data
- ./letsencrypt:/etc/letsencrypt
Nach docker compose up -d ist die Oberfläche unter http://deine-server-ip:81 erreichbar – bewusst nicht auf Port 80 oder 443, weil diese ja für den eigentlichen Proxy-Betrieb reserviert bleiben.
Erster Login: Sofort das Passwort ändern
Standardmäßig meldest du dich beim allerersten Start mit admin@example.com und dem Passwort changeme an. Automatisierte Scanner im Internet probieren genau diese Kombination binnen Sekunden nach Erscheinen eines neuen Dienstes durch – das Ändern der Zugangsdaten gehört deshalb an den Anfang, nicht ans Ende der Einrichtung. Alternativ lassen sich beim Start über die Umgebungsvariablen INITIAL_ADMIN_EMAIL und INITIAL_ADMIN_PASSWORD direkt eigene Zugangsdaten setzen, sodass der unsichere Standard-Account gar nicht erst aktiv wird. Ob die Standardwerte in der aktuellen Version überhaupt noch existieren oder bereits entfernt wurden, war zum Zeitpunkt dieses Artikels nicht abschließend zu klären – sicherheitshalber solltest du in jedem Fall direkt nach dem ersten Login prüfen und ändern.
Einen Proxy Host anlegen
Unter „Proxy Hosts“ trägst du für jeden Dienst ein: die gewünschte Domain (z. B. cloud.meinedomain.de), die interne IP-Adresse und den Port deines Containers sowie im Reiter „SSL“ das gewünschte Zertifikat. NPM übernimmt danach automatisch die komplette Umleitung inklusive Verschlüsselung – ohne dass du eine Zeile Nginx-Konfiguration selbst schreibst.
Let’s-Encrypt-Zertifikate: HTTP-01 vs. DNS-01
NPM stellt kostenlose Zertifikate über Let’s Encrypt automatisch aus und erneuert sie im Hintergrund über Certbot, sobald die Restlaufzeit unter 30 Tage fällt – geprüft wird das stündlich. Dabei gibt es zwei Wege, den Domainbesitz nachzuweisen:
- HTTP-01-Challenge: Let’s Encrypt ruft kurz eine Datei auf deinem Server ab. Dafür muss Port 80 von außen erreichbar sein. Für Wildcard-Zertifikate (also ein Zertifikat, das gleich
*.meinedomain.deabdeckt) reicht das nicht. - DNS-01-Challenge: Der Nachweis läuft über einen DNS-Eintrag, den NPM automatisch bei deinem Domain-Anbieter setzt. Das ist zwingend nötig für Wildcard-Zertifikate und funktioniert auch dann, wenn dein Server hinter CGNAT sitzt oder du gar keinen Port nach außen öffnen willst. NPM bringt dafür eine eingebaute Liste unterstützter DNS-Anbieter mit, im Homelab-Umfeld ist Cloudflare die gängigste Wahl.
Die verbreitete Annahme, für Let’s-Encrypt-Zertifikate müsse Port 80 dauerhaft offen sein, stimmt also nur für die HTTP-01-Variante.
Warum automatische Erneuerung bald Pflicht wird
Ein Punkt, der aktuell an Bedeutung gewinnt: Let’s Encrypt verkürzt die Zertifikatslaufzeiten schrittweise drastisch. Seit dem 13. Mai 2026 gibt es optional bereits 45-Tage-Zertifikate für Early Adopter, ab dem 10. Februar 2027 wird das Standardprofil auf 64 Tage umgestellt, und ab dem 16. Februar 2028 sind verbindlich nur noch 45 Tage mit einer Wiederverwendungs-Frist von 7 Stunden für die Domain-Prüfung vorgesehen. Hintergrund ist eine branchenweite Entscheidung des CA/Browser-Forums, die die maximale Zertifikatslaufzeit stufenweise senkt – Let’s Encrypt zieht das rund ein Jahr früher durch als vom Forum vorgegeben. Wer Zertifikate bislang gelegentlich von Hand erneuert hat, wird das bei diesen Zyklen kaum noch praktikabel finden. Die automatische Erneuerung, wie sie NPM von Haus aus mitbringt, wird damit vom netten Extra zum notwendigen Feature.
Dranbleiben: Updates und Sicherheit
NPM befindet sich, Stand August 2026, ungefähr bei Version 2.15.x (die genaue Patch-Version solltest du vor dem eigenen Einsatz auf der GitHub-Releases-Seite des Projekts prüfen). Aktuelle Releases schließen regelmäßig Sicherheitslücken in OpenResty sowie zuletzt eine Rechteausweitungs-Lücke, bei der authentifizierte Nutzer ihr eigenes Rollen-Feld manipulieren konnten. Das zeigt: NPM ist kein Werkzeug zum einmaligen Einrichten und Vergessen, sondern will wie jeder nach außen erreichbare Dienst regelmäßig aktualisiert werden. Wer noch einen älteren Raspberry Pi mit 32-Bit-Betriebssystem (armv7/armhf) betreibt, sollte zudem wissen, dass diese Architekturen seit Version 2.14.0 nicht mehr unterstützt werden.
GEEKOM iX12 Lüfterloser Mini PC
Ein Reverse Proxy sollte rund um die Uhr laufen – ein lüfterloser Mini-PC wie dieser ist dafür genau die richtige Hardware-Basis.
NPM oder doch eine Alternative?
NPM ist nicht die einzige Möglichkeit, Dienste hinter einer sauberen Adresse zu verstecken. Welches Werkzeug passt, hängt vom eigenen Setup ab:
| Werkzeug | Bedienung | Ideal für |
|---|---|---|
| Nginx Proxy Manager | Grafische Oberfläche, kein Umgang mit Konfigurationsdateien nötig | Einsteiger mit wenigen, eher statischen Diensten |
| Traefik | Erkennt neue Docker-Container automatisch über Labels | Wer viele Container hat, die häufig wechseln |
| Caddy | Konfiguration als Textdatei, automatisches HTTPS out of the box | Wer Konfigurationsdateien einer Oberfläche vorzieht |
Für Homelabs hinter CGNAT (also einer Internetanbindung ohne öffentliche IP-Adresse, bei der eine klassische Portfreigabe gar nicht möglich ist) lohnt sich zusätzlich ein Blick auf Cloudflare Tunnel oder das neuere Pangolin, die statt einer offenen Portfreigabe einen ausgehenden Tunnel zum jeweiligen Anbieter aufbauen. Das sprengt den Rahmen dieses Artikels, ist aber als Stichwort für die eigene Weiterrecherche wert, falls eine Portfreigabe bei dir nicht infrage kommt.
Fazit
Nginx Proxy Manager bleibt für die meisten Homelabs der pragmatischste Einstieg in Reverse Proxying: Weboberfläche statt Konfigurationsdateien, automatische Zertifikate inklusive Wildcard-Unterstützung über DNS-01, und ein aktiv gepflegtes Projekt trotz des ausstehenden großen Rewrites. Wichtig ist nur, die Hausaufgaben nicht zu vergessen: Standard-Zugangsdaten sofort ändern, Container aktuell halten – und sich schon jetzt darauf einstellen, dass Zertifikate in den kommenden Jahren deutlich kürzer laufen werden.