Nginx UI mit Docker: Nginx per Weboberfläche verwalten, absichern und sichern

Nginx UI ist eine Weboberfläche für den Webserver Nginx: Sites anlegen, Konfigurationen mit Syntaxprüfung bearbeiten, Let's-Encrypt-Zertifikate ausstellen, Logs lesen und Backups ziehen, alles im Browser. Gleichzeitig ist ein solches Panel ein lohnendes Ziel: Wer es übernimmt, kontrolliert den gesamten Webverkehr. Genau das ermöglichte im Frühjahr 2026 die Lücke CVE-2026-33032. Diese Anleitung zeigt den Betrieb mit Docker Compose, die tägliche Arbeit mit Sites, Zertifikaten und Logs und vor allem, wie Sie die Oberfläche absichern und sauber sichern.

Voraussetzungen

Im Test belegte der Container im Leerlauf rund 98 MiB RAM, das Image ist entpackt etwa 455 MB groß. Für einige Sites reicht:

• Linux-Server mit Docker Engine und Docker Compose v2, 1 bis 2 CPU-Kerne, 1 GB RAM (2 GB mit Puffer für Log-Auswertung), 5 GB freier Speicher plus Platz für Ihre Webinhalte.
• Architektur: Laut Docker Hub gibt es Images für amd64, arm64, armv5, armv6, armv7 und riscv64, also auch für Raspberry Pi und ARM-VPS.
• Freie Ports 80 und 443, denn der Container ersetzt den Nginx auf dem Host. Läuft dort bereits ein Webserver, scheitert der Start (siehe Typische Fehler).
• Für Let's Encrypt: eine Domain, deren A- oder AAAA-Eintrag auf den Server zeigt, und Port 80 aus dem Internet erreichbar. Für die Admin-Oberfläche zusätzlich ein eigener Hostname wie admin.example.de, idealerweise nur über VPN erreichbar.

Schritt 1: Projekt prüfen und Compose-Datei anlegen

Das Projekt 0xJacky/nginx-ui steht unter AGPL-3.0 und hatte am 3. Oktober 2026 laut GitHub-API 11.563 Sterne, der letzte Push war am 2. Oktober 2026. Aktuelles Release ist v2.8.2 vom 2. Oktober 2026, die Docker-Tags 2.8.2, v2.8.2 und latest zeigen auf dasselbe Image. Schreiben Sie die Version trotzdem fest, damit ein Neustart nicht unbemerkt aktualisiert.

Eckdaten	Wert
Image	uozi/nginx-ui:2.8.2 (enthält Nginx 1.31.6)
Ports	80 und 443 im Container; die Oberfläche läuft intern auf 9000 und wird über Port 80 ausgeliefert
Volumes	/etc/nginx (Konfiguration), /etc/nginx-ui (app.ini, Datenbank, Geheimnisse), /var/www (Webinhalte)
Wichtige Env	NGINX_UI_SERVER_RUN_MODE, NGINX_UI_IGNORE_DOCKER_SOCKET, NGINX_UI_AUTH_IP_WHITE_LIST

Legen Sie einen Projektordner an, zum Beispiel /opt/nginx-ui, und darin die Datei compose.yaml:

services:
  nginx-ui:
    image: uozi/nginx-ui:${NGINX_UI_VERSION}
    container_name: nginx-ui
    restart: unless-stopped
    environment:
      TZ: ${TZ}
      NGINX_UI_SERVER_RUN_MODE: ${NGINX_UI_SERVER_RUN_MODE}
      # kein Docker-Socket: kein OTA-Containertausch, dafür kein Zugriff auf den Docker-Host
      NGINX_UI_IGNORE_DOCKER_SOCKET: "true"
    ports: ["80:80", "443:443"]
    volumes: ["./nginx:/etc/nginx", "./nginx-ui:/etc/nginx-ui", "./www:/var/www"]

Dazu die .env im selben Ordner:

NGINX_UI_VERSION=2.8.2
TZ=Europe/Berlin
# ohne release schreibt Nginx UI jede SQL-Abfrage ins Log
NGINX_UI_SERVER_RUN_MODE=release

Zwei bewusste Abweichungen vom Beispiel der offiziellen Doku: Der Docker-Socket fehlt, denn er gibt dem Panel faktisch Root-Rechte auf dem Host und wird nur für Updates aus der Oberfläche gebraucht. Und der Run-Mode steht auf release, sonst setzt die generierte app.ini debug und das Log füllt sich mit SQL-Ausgaben.

Verifizieren: docker compose config zeigt die aufgelöste Konfiguration mit Ihrer Versionsnummer ohne Fehlermeldung. Der Ordner nginx muss beim ersten Start leer sein oder fehlen, damit das Image seine Standardkonfiguration hineinkopiert.

Schritt 2: Starten und Installationsgeheimnis holen

cd /opt/nginx-ui
docker compose up -d
docker compose ps
cat nginx-ui/.install_secret

Seit einigen Versionen sperrt Nginx UI die Ersteinrichtung mit einem Einmal-Geheimnis. Es steht im Startlog und in der Datei .install_secret, laut Log ist es zehn Minuten gültig. Öffnen Sie http://SERVER-IP/, geben Sie das Geheimnis ein und lassen Sie die Selbstprüfung laufen.

Fehlt in Ihrer Compose-Datei die Variable NGINX_UI_IGNORE_DOCKER_SOCKET, meldet die Prüfung „Docker-Socket existiert nicht“ und blockiert die Installation.

Verifizieren: docker compose ps zeigt den Container als Up, curl -I http://localhost/ liefert 200, und curl -s http://localhost/api/install antwortet vor der Einrichtung mit {"lock":false,...}.

Schritt 3: Administrator anlegen und 2FA aktivieren

Im zweiten Schritt des Assistenten legen Sie E-Mail, Benutzername und Passwort an. Wählen Sie nicht admin als Namen. Achtung: Das Formular akzeptiert höchstens 20 Zeichen Passwortlänge, längere Passwörter lehnt es mit „Passwort darf nicht länger als 20 Zeichen sein“ ab. Nutzen Sie die 20 Zeichen aus einem Passwortmanager voll aus und aktivieren Sie danach unter Benutzerprofil 2FA per TOTP oder Passkey.

Haben Sie das Passwort vergessen, setzt docker exec -it nginx-ui nginx-ui reset-password --config=/etc/nginx-ui/app.ini laut Doku ein neues Zufallspasswort für den ersten Benutzer und schreibt es ins Log.

Verifizieren: curl -s http://localhost/api/install meldet jetzt "lock":true, und unangemeldete API-Aufrufe wie curl -s -o /dev/null -w '%{http_code}' http://localhost/api/sites liefern 403.

Schritt 4: Erste Site anlegen und Konfiguration testen

Unter Verwalte Seiten, Seite hinzufügen führt die Schnelleinrichtung durch vier Schritte. Für eine statische Website legen Sie die Dateien unter ./www/marker ab und tragen als Web-Root /var/www/marker ein.

Nginx UI folgt dem Debian-Schema: Die Datei landet in sites-available, aktiviert wird per Symlink in sites-enabled. Jede Speicherung löst nginx -t und danach ein Reload aus. Im Test haben wir absichtlich ein Semikolon hinter root entfernt. Nginx UI lehnte das Speichern mit nginx: [emerg] invalid number of arguments in "root" directive ab, stellte die alte Datei wieder her, und die Site lief unverändert weiter.

Verifizieren: docker compose exec nginx-ui nginx -t meldet test is successful, und curl -H "Host: marker.example.de" http://localhost/ liefert Ihre Seite aus.

Schritt 5: Let's-Encrypt-Zertifikate und Logs

Im Schritt SSL konfigurieren wählen Sie HTTP-01 (Validierung über Port 80) oder DNS-01 (über die API Ihres DNS-Anbieters, nötig für Wildcards). Nutzen Sie zuerst „Nur prüfen“: Die Vorabprüfung erkennt fehlende DNS-Einträge, bevor Let's Encrypt eine fehlgeschlagene Validierung zählt. Schlägt die Ausstellung fehl, bleibt die Site laut Oberfläche per HTTP erreichbar. Zertifikate erneuert Nginx UI selbstständig, standardmäßig ab 30 Tagen Restlaufzeit.

Wie die ACME-Validierung funktioniert, erklärt Let's-Encrypt-Zertifikate mit Certbot. Unter Nginx-Log finden Sie Zugriffs- und Fehlerprotokolle mit Filter und Live-Ansicht.

Verifizieren: Nach der Ausstellung zeigt Zertifikate den Status und das Ablaufdatum, curl -I https://IHRE-DOMAIN/ antwortet ohne Zertifikatsfehler. Unter Nginx-Log, Zugriffsprotokolle erscheinen Ihre Testaufrufe.

Schritt 6: Oberfläche absichern

CVE-2026-33032 (CVSS 9.8) zeigt, warum: Laut GitHub-Advisory prüfte der MCP-Endpunkt /mcp_message nur die IP-Whitelist, und eine leere Whitelist bedeutete „alle erlaubt“. Angreifer konnten ohne Login Konfigurationen ändern und Nginx neu starten. Laut NVD betroffen sind Versionen bis 2.3.5. Kurz zuvor erlaubte CVE-2026-27944 den unangemeldeten Download kompletter Backups samt Schlüssel, laut Advisory behoben in 2.3.3. Hintergründe zur aktiven Ausnutzung stehen in unserer Meldung zur Auth-Bypass-Lücke in nginx-ui. In unserem Test mit 2.8.1 und 2.8.2 antworteten /mcp_message, /mcp und /api/backup ohne Anmeldung mit 403. Darauf allein sollten Sie sich nicht verlassen:

• Version prüfen: docker compose exec nginx-ui nginx-ui --version, Releases abonnieren und Sicherheitsupdates zeitnah einspielen.
• Nicht öffentlich exponieren: Im offiziellen Image ist die Oberfläche der Default-Server auf Port 80 und antwortet auf jeden Hostnamen. Tragen Sie in nginx/conf.d/nginx-ui.conf bei server_name Ihren Admin-Hostnamen ein und legen Sie einen Default-Server an, der unbekannte Anfragen verwirft. Erreichbarkeit zusätzlich per Firewall oder VPN beschränken, wie in Linux-Server mit UFW und Fail2ban absichern beschrieben.
• 2FA erzwingen: TOTP oder Passkey für jedes Konto, Login-Sperre greift laut Doku nach 10 Fehlversuchen in 10 Minuten.
• IP-Whitelist mit Bedacht: NGINX_UI_AUTH_IP_WHITE_LIST sperrte im Test alle anderen Adressen mit 403, auch die Websites. Hinter dem Docker-Portmapping sah Nginx UI aber jeden Client als Bridge-Gateway 172.18.0.1. Eine Whitelist mit echten Client-Adressen greift so nicht, nutzen Sie dafür die Firewall des Hosts.
• Geheimnisse schützen: app.ini enthält JWT-, Crypto- und Node-Secret. Mit dem Node-Secret ist laut Doku API-Zugriff ohne Passwort möglich. Ordner nginx-ui und alle Backups gehören deshalb nicht in falsche Hände. Für Automatisierung besser Zugriffstokens mit Scope api:read oder api:write und Ablaufdatum anlegen.

# Admin-Hostname setzen und unbekannte Hosts verwerfen
sed -i 's/server_name  localhost;.*/server_name  admin.example.de;/' nginx/conf.d/nginx-ui.conf
printf 'server {\n    listen 80 default_server;\n    server_name _;\n    return 444;\n}\n' > nginx/conf.d/00-default.conf
docker compose exec nginx-ui nginx -t && docker compose exec nginx-ui nginx -s reload

Verifizieren: curl -I http://SERVER-IP/ endet mit „Empty reply from server“, curl -I -H "Host: admin.example.de" http://SERVER-IP/ liefert 200. Beides blieb im Test auch nach docker compose restart so.

Schritt 7: Backup und Restore

Unter Backup-Verwaltung, Sicherung erstellt „Backup erstellen“ ein ZIP mit signiertem Manifest sowie verschlüsselten Archiven der Nginx- und der Nginx-UI-Konfiguration. Das Sicherheitstoken zur Entschlüsselung zeigt Nginx UI genau einmal an. Webinhalte unter /var/www gehören laut Beschreibung nicht dazu. Automatische Sicherungen mit Zeitplan, auch auf S3, richten Sie unter Automatische Sicherung ein; eigene Zielordner müssen laut Doku in GrantedAccessPath freigegeben sein.

Im Test haben wir die Marker-Site gelöscht und das Backup eingespielt. Mit falschem Token brach der Restore mit Failed to decrypt file: Invalid padding in decrypted data ab, mit korrektem Token meldete die API "hash_match":true, die Site war samt Symlink zurück und die Anmeldung blieb gültig. Ergänzend sichern Sie die drei Ordner bei gestopptem Container:

cd /opt/nginx-ui
docker compose stop
sudo tar czf /backup/nginx-ui-$(date +%F).tgz nginx nginx-ui www
docker compose start
# Restore: Ordner ersetzen und neu starten
docker compose down
sudo rm -rf nginx nginx-ui www
sudo tar xzf /backup/nginx-ui-DATUM.tgz
docker compose up -d

Verifizieren: Nach dem Restore liefert curl -H "Host: marker.example.de" http://localhost/ wieder die Markerseite, /api/install meldet "lock":true und der bisherige Login funktioniert. Genau so lief es im Test.

Schritt 8: Update und Rollback

Erhöhen Sie NGINX_UI_VERSION in der .env, ziehen Sie vorher ein Ordner-Backup und starten Sie neu:

docker compose pull
docker compose up -d
docker compose exec nginx-ui nginx-ui --version

Der Sprung von 2.8.1 auf 2.8.2 und zurück lief im Test ohne Fehlermeldung, Sites und Login blieben erhalten. Bei größeren Sprüngen migriert Nginx UI die SQLite-Datenbank, ein Rückweg ist dann nur über das vorher gezogene Ordner-Backup sicher. Backups ohne signiertes Manifest (Legacy) lehnt die aktuelle Version ab.

Verifizieren: Die Versionsausgabe zeigt die neue Nummer, nginx -t ist erfolgreich und alle Sites antworten.

Typische Fehler

• Bind for :::80 failed: port is already allocated: Ein anderer Dienst belegt Port 80. Stoppen Sie ihn und starten Sie mit docker compose up -d --force-recreate. Im Test startete ein einfaches erneutes up -d den Container zwar als Up, aber ohne Portfreigabe; erst --force-recreate half.
• Oberfläche nach Neustart nicht erreichbar: Eine von Hand bearbeitete, fehlerhafte Datei unter /etc/nginx bringt Nginx zum Absturz, und damit verschwindet auch die Oberfläche, obwohl der Container Up meldet. Das Log zeigt in Schleife nginx: [emerg] ... mit Datei und Zeile. Datei korrigieren oder entfernen, Nginx startet dann von selbst.

Häufige Fragen

Kann Nginx UI einen vorhandenen Nginx auf dem Host verwalten?

Nicht mit diesem Image, es ersetzt den Host-Nginx. Dafür gibt es das Installationsskript für Linux.

Brauche ich zusätzlich einen Reverse Proxy?

Nein, der Container ist selbst der Reverse Proxy. Steht ein weiterer Proxy davor, muss dessen Adresse in TrustedProxies stehen, Grundlagen erklärt Nginx als Reverse Proxy mit TLS.

Wie entferne ich Nginx UI wieder?

docker compose down stoppt und entfernt den Container. Erst das Löschen der Ordner nginx, nginx-ui und www entfernt Konfiguration, Zertifikate, Datenbank und Webinhalte endgültig. Ziehen Sie davor ein Backup, denn dieser Schritt ist nicht rückgängig zu machen.

Testumfang

Getestet haben wir am 3. Oktober 2026 auf einem abgeschotteten Docker-Testhost mit uozi/nginx-ui 2.8.1 und 2.8.2: Start, Ersteinrichtung mit Installationsgeheimnis, Site-Anlage mit nginx -t, provozierte Fehler (fehlerhafte Konfiguration, Portkonflikt), Härtung per Default-Server, IP-Whitelist, eingebautes Backup samt Restore, Ordner-Backup samt Restore sowie Update und Rollback. Die Ausstellung echter Let's-Encrypt-Zertifikate, 2FA-Einrichtung, automatische Sicherungen und S3 konnten wir im Testnetz ohne öffentliche Domain nicht durchspielen und stützen uns dabei auf Oberfläche und Dokumentation.

Fazit

Nginx UI nimmt viel Handarbeit ab und verhindert dank nginx -t mit Rücksprung, dass ein Tippfehler alle Sites lahmlegt. Behandeln Sie das Panel wie einen SSH-Zugang: aktuell halten, nur über VPN oder eigenen Hostnamen erreichbar machen, 2FA einschalten. Wer zusätzlich die drei Ordner sichert und den Restore geübt hat, kann Nginx UI auch in KMU solide betreiben.

Weiterführende Anleitungen und Quellen

• nginx-ui: Kritische Auth-Bypass-Lücke CVE-2026-33032
• Let's-Encrypt-Zertifikate mit Certbot einrichten
• Linux-Server mit UFW und Fail2ban absichern
• GitHub: 0xJacky/nginx-ui und Release v2.8.2
• Nginx UI Doku: Getting Started (Docker)
• Nginx UI Doku: Auth (IPWhiteList, TrustedProxies) und Backup-Konfiguration
• GitHub Advisory GHSA-h6c2-x2m2-mwhf (CVE-2026-33032) und NVD CVE-2026-33032
• GitHub Advisory GHSA-g9w5-qffc-6762 (CVE-2026-27944)
• Docker Hub: uozi/nginx-ui