Nginx Proxy Manager mit Docker installieren

Linux 16 Min. Lesezeit

Auf einem Server können die Ports 80 und 443 jeweils nur von einem Programm gleichzeitig genutzt werden. Wenn Sie mehrere Webanwendungen in Docker ausführen (beispielsweise eine WordPress-Website, ein n8n und eine eigene Anwendung), benötigen Sie einen Reverse-Proxy: Dieser empfängt alle Anfragen, leitet sie anhand der angeforderten Domain an den entsprechenden Container weiter und verwaltet zudem die SSL-Zertifikate.

Der Nginx Proxy Manager (NPM) ist ein solcher Proxy mit einer webbasierten Verwaltungsoberfläche. Die Nginx-Konfigurationsdateien müssen nicht manuell erstellt werden: Sie geben die Domain, den Ziel-Container und das Zertifikat in einigen Feldern ein, und die Let’s-Encrypt-Zertifikate werden vom NPM angefordert und erneuert. Er eignet sich ideal für einen eigenen KVM-VPS, auf dem sich mehrere kleinere Anwendungen eine IP-Adresse teilen.

Wir haben die Schritte im November 2026 auf einem Ubuntu-24.04-System mit den Versionen Docker Engine 29.9.3, Docker Compose 5.7.0 und Nginx Proxy Manager 2.16.0 getestet. Der Testrechner verfügte über keine öffentliche Domain, weshalb wir die Beantragung eines Let’s-Encrypt-Zertifikats nicht vollständig durchführen konnten: Wir stellen die Benutzeroberfläche vor und beschreiben die Funktionsweise anhand der Dokumentation sowie des Quellcodes des Programms, worauf wir in diesem Artikel hinweisen. Die Proxy-Funktion auf dem Server haben wir mit dem Befehl curl unter Angabe des Host-Headers überprüft.

Infografik: Anfragen aus dem Internet gehen über die Ports 80 und 443 des Nginx Proxy Managers ein, der sie anhand der Domain an die Container app1, app2 und WordPress im Docker-Netzwerk namens proxy weiterleitet; MariaDB befindet sich im eigenen Netzwerk des Projekts, Port 81 des Verwaltungsportals ist nur unter der Adresse 127.0.0.1 erreichbar

Bevor Sie beginnen

  • Docker und Compose. Informationen zur Installation finden Sie im Artikel Installation von Docker unter Ubuntu, Debian und AlmaLinux, die Grundlagen zu Compose werden im Artikel Verwendung von Docker Compose erläutert.
  • Die Ports 80 und 443 müssen frei sein. Falls auf dem Server natives Apache oder Nginx läuft, beenden Sie diese Dienste und deaktivieren Sie sie, da der NPM-Container andernfalls nicht startet („address already in use“). Mit dem Befehl sudo ss -ltnp können Sie feststellen, welche Dienste die Ports belegen.
  • DNS. Für die Beantragung eines Zertifikats muss der A-Eintrag der Domains (z. B. app1.pelda.hu) – bzw. bei IPv6 der AAAA-Eintrag – auf die IP-Adresse des Servers verweisen.
  • Firewall. Die Ports 80 und 443 müssen von außen erreichbar sein (siehe: Wie richte ich eine Firewall auf meinem VPS ein?). Docker öffnet die veröffentlichten Ports anhand eigener Regeln, die Vorrang vor den Regeln von ufw und firewalld haben; daher muss der Port des Verwaltungsportals an die lokale Adresse gebunden werden, wie unten dargestellt.

1. Gemeinsames Docker-Netzwerk

NPM und die Anwendungen sind in einem gemeinsamen Docker-Netzwerk miteinander verbunden. Auf diese Weise müssen die Anwendungen keinen einzigen Port auf dem Server veröffentlichen: NPM greift innerhalb des Netzwerks über den Namen des Containers auf sie zu. Einmal einrichten:

docker network create proxy

2. Die Datei „compose.yaml“ von NPM

mkdir -p ~/npm && cd ~/npm
nano compose.yaml
services:
  npm:
    image: jc21/nginx-proxy-manager:2.16.0
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
      - "127.0.0.1:81:81"
    environment:
      TZ: "Europe/Budapest"
    volumes:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt
    networks:
      - proxy

networks:
  proxy:
    external: true
  • Ports: Die Ports 80 (HTTP) und 443 (HTTPS) sind für alle zugänglich; dies ist die Aufgabe des Proxys. Port 81 ist der Port der Verwaltungsoberfläche: Aufgrund der Adresse 127.0.0.1:81:81 ist er nur von innerhalb des Servers erreichbar. In der offiziellen Beschreibung wird '81:81' angegeben; dies würde jedoch bedeuten, dass die Anmeldeseite unabhängig von der Firewall für das gesamte Internet zugänglich wäre.
  • Image: Legen Sie die Version fest (2.16.0) und verwenden Sie nicht das Tag latest, damit die Entscheidung über ein Update bei Ihnen bleibt.
  • Volumes: Im Ordner data befinden sich die Datenbank (SQLite), die Einstellungen und die Protokolle, im Ordner letsencrypt die Zertifikate. Diese beiden Ordner sind Gegenstand der Sicherung.
  • networks: NPM verbindet sich mit dem oben erstellten proxy-Netzwerk; der Eintrag external: true gibt an, dass das Netzwerk nicht von diesem Projekt verwaltet wird.
  • Falls auf dem Server kein IPv6 verfügbar ist, muss gemäß der Dokumentation zusätzlich die Umgebungsvariable DISABLE_IPV6: 'true' gesetzt werden.

Inbetriebnahme und Startprotokoll:

docker compose up -d
docker compose logs -f

Beim ersten Start erstellt NPM die Datenbank und die Schlüssel. Sobald in der Protokolldatei die Zeile „Backend PID … listening on port 3000“ erscheint, ist der Vorgang abgeschlossen; Sie können die Protokolldatei mit Strg+C verlassen.

3. Zugriff auf die Verwaltungsoberfläche über einen SSH-Tunnel

Da Port 81 nur innerhalb des Servers erreichbar ist, können Sie über einen SSH-Tunnel von Ihrem eigenen Rechner aus darauf zugreifen. Führen Sie auf Ihrem eigenen Rechner folgenden Befehl aus (ersetzen Sie den Benutzernamen und die Adresse durch Ihre eigenen Daten):

ssh -L 8181:127.0.0.1:81 felhasznalo@szerver-ip

Solange diese Verbindung besteht, öffnet die Adresse http://localhost:8181 im Browser die NPM-Benutzeroberfläche. Wenn Sie diese häufig nutzen, können Sie den Tunnel auch in die Datei ~/.ssh/config mit der Zeile LocalForward eintragen (siehe: Verwendung der SSH-Konfigurationsdatei). Allgemeine Informationen zur SSH-Verbindung finden Sie im Artikel Wie stelle ich über SSH eine Verbindung zu meinem VPS her?.

4. Erste Anmeldung

Ältere Versionen wurden mit einem Standardkonto gestartet (admin@example.com, Passwort changeme), und viele Anleitungen erwähnen dies auch heute noch. In der Version 2.16.0 gibt es kein solches Konto: Beim ersten Aufruf erscheint die Seite Welcome!, auf der das Administratorkonto angelegt werden muss.

Die Seite Welcome!, die beim ersten Start des Nginx Proxy Managers angezeigt wird, enthält die Felder Full Name, Email address und New Password sowie die Schaltfläche Save

Geben Sie Ihren Namen (Full Name), eine gültige E-Mail-Adresse (Email address) und ein sicheres Passwort (New Password) ein und klicken Sie anschließend auf die Schaltfläche Save. Im Test dauerte das Speichern einige Sekunden, danach wurde die Anmeldeseite angezeigt.

Die E-Mail-Adresse wird nicht nur für die Anmeldung benötigt: Laut dem Quellcode des Programms registriert sich NPM mit dieser Adresse bei Let’s Encrypt, wenn ein Zertifikat angefordert wird, und akzeptiert dabei automatisch die Nutzungsbedingungen von Let’s Encrypt. Sollte bei der Zertifikatsanforderung eine Fehlermeldung wegen einer ungültigen E-Mail-Adresse angezeigt werden, korrigieren Sie diese bitte in Ihrem Konto (oben rechts, durch Klicken auf Ihren Namen: Edit Profile).

Nach der Anmeldung zeigt die Startseite (Dashboard) die Anzahl der gespeicherten Einträge an:

Startseite (Dashboard) des Nginx Proxy Managers: 2 Proxy-Hosts, 0 Umleitungs-Hosts, 0 Streams, 0 404-Hosts

Die Benutzeroberfläche wird standardmäßig auf Englisch angezeigt. Über das Globus-Symbol in der oberen rechten Ecke können Sie die Sprache auf Ungarisch (Magyar) umstellen; in diesem Artikel zitieren wir die englischen Bezeichnungen. Im selben Menü (durch Anklicken Ihres Namens) finden Sie auch Two-Factor Auth: Da die Benutzeroberfläche vollständigen Zugriff auf den Webverkehr des Servers gewährt, empfiehlt es sich, die Zwei-Faktor-Authentifizierung zu aktivieren.

5. Zwei Testanwendungen

Starten Sie versuchsweise zwei kleine Anwendungen im proxy-Netzwerk: einen Nginx-Server mit einer einfachen Seite (app1) und das traefik/whoami-Image (app2), das anzeigt, welche Anfrage eingegangen ist.

mkdir -p ~/apps/app1 && cd ~/apps
echo "<h1>Das ist app1</h1>" > app1/index.html
nano compose.yaml
services:
  app1:
    image: nginx:alpine
    restart: unless-stopped
    volumes:
      - ./app1:/usr/share/nginx/html:ro
    networks:
      - proxy

  app2:
    image: traefik/whoami
    restart: unless-stopped
    networks:
      - proxy

networks:
  proxy:
    external: true
docker compose up -d

Bei keinem der Dienste gibt es einen ports-Bereich: Die Container sind über keinen Port des Servers erreichbar, sondern ausschließlich im proxy-Netzwerk über NPM. Die Mitglieder des Netzwerks werden mit dem Befehl docker network inspect proxy angezeigt.

6. Hinzufügen eines Proxy-Hosts

Wählen Sie im oberen Menü den Punkt „Hosts“ › „Proxy Hosts“ und anschließend die Schaltfläche „Add Proxy Host“. Auf der Registerkarte „Details“:

  • Domain Names: Die Domain, an die die Anfragen gesendet werden (app1.pelda.hu). Drücken Sie nach der Eingabe die Eingabetaste; es können mehrere Domains angegeben werden.
  • Scheme: http. Die Container kommunizieren im internen Netzwerk meist über reines HTTP, HTTPS wird von NPM verwaltet.
  • Forward Hostname / IP: Der Name des Containers im gemeinsamen Netzwerk (app1).
  • Forward Port: Der interne Port des Containers, auf dem die Anwendung lauscht (bei Nginx und whoami ist dies Port 80); es handelt sich nicht um einen veröffentlichten Port.
  • Block Common Exploits: Filtert einige häufige Angriffsmuster heraus; diese Funktion kann aktiviert werden.
  • Websockets Support: Aktivieren Sie diese Option, wenn Ihre Anwendung WebSockets verwendet (z. B. Echtzeit-Oberflächen und Chats).

Das Fenster Add Proxy Host, Registerkarte Details: Domainnamen app1.pelda.hu, Schema http, Weiterleitungs-Hostname app1, Weiterleitungs-Port 80, Zugriffsliste Publicly Accessible, Option Block Common Exploits aktiviert

Fügen Sie nach dem Speichern (Save) die zweite Anwendung auf dieselbe Weise hinzu (app2.pelda.hu, app2, 80).

Die Liste Proxy-Hosts enthält drei Einträge: app1.pelda.hu, app2.pelda.hu und wp.pelda.hu, mit der Zieladresse, HTTP-Only-SSL, in der Spalte Zugriff bei einem Eintrag die Zugriffsliste Nur mit Passwort und alle Einträge im Status Online

Der Status Online bedeutet lediglich, dass die Nginx-Konfiguration gültig ist, nicht jedoch, dass der Zielcontainer antwortet. Im Test wurden sowohl ein Eintrag, der auf einen falschen Port (app1:8080) verwies, als auch ein Eintrag, der auf einen nicht existierenden Container verwies, als „Online“ angezeigt; der Browser erhielt jedoch bei beiden Fällen den Fehler 502 Bad Gateway. Die übrigen Einträge funktionierten unterdessen einwandfrei.

Testen ohne DNS

Bevor Sie die DNS-Einstellungen ändern, können Sie den Proxy auf dem Server auch mit dem Befehl curl testen: Der Schalter -H "Host: ..." übermittelt die Domain, die auch der Browser senden würde.

curl -s -H "Host: app1.pelda.hu" http://127.0.0.1/
curl -s -H "Host: app2.pelda.hu" http://127.0.0.1/ | head -3

Die Ausgabe von curl auf dem Server: app1.pelda.hu liefert die Seite „Das ist app1“, app2.pelda.hu liefert die Antwort von whoami mit Passwort; ohne Passwort wird der Statuscode 401 zurückgegeben; darunter sind die Ports des NPM-Containers aufgeführt

Auf dem Bild ist die app2 bereits durch die unten dargestellte Zugriffsliste geschützt, weshalb ohne Passwort der Statuscode 401 zurückgegeben wurde.

Sie können dies auf Ihrem eigenen Rechner im Browser testen, indem Sie die Domain zusammen mit der IP-Adresse des Servers in die Datei hosts eintragen (unter Linux und macOS in /etc/hosts, unter Windows in C:\Windows\System32\drivers\etc\hosts).

Wenn eine Domain aufgerufen wird, für die kein Proxy-Host vorhanden ist (oder die IP-Adresse direkt eingegeben wird), zeigt NPM seine eigene „Congratulations“-Seite an. Dies können Sie unter Settings › Default Site auf die Optionen 404 Page, No Response (444), Redirect oder Custom HTML ändern; auf einem Produktionsserver sind die 404-Seite oder der Abschluss ohne Antwort (444) die übliche Vorgehensweise.

Einbindung eines bestehenden Compose-Projekts

Sie können eine bereits laufende Anwendung einbinden, indem Sie deren Webdienst in der Datei compose.yaml zusätzlich mit dem proxy-Netzwerk verbinden und den Abschnitt ports löschen. Am Beispiel von WordPress und MariaDB wird dies im Artikel Verwendung von Docker Compose im Abschnitt über den Reverse-Proxy erläutert. Die Datenbank sollte im eigenen Netzwerk des Projekts verbleiben: Im Test konnte der Name db vom Proxy aus gar nicht aufgelöst werden.

In das Feld Forward Hostname sollten Sie in diesem Fall den vollständigen Namen des Containers eingeben (im Test wordpress-wordpress-1, wie vom Befehl docker compose ps ausgegeben). Der Kurzname des Dienstes (wordpress) funktionierte zwar ebenfalls, doch wenn es im proxy-Netzwerk zwei Projekte mit identisch benannten Diensten gibt, ist der Kurzname nicht eindeutig.

Die Datei wp-config.php des offiziellen WordPress-Docker-Images überwacht den vom Proxy gesendeten X-Forwarded-Proto-Header, sodass auch hinter einer HTTPS-Verbindung keine Weiterleitungsschleife entsteht; im Test leitete WordPress bei einer Anfrage mit dem Header X-Forwarded-Proto: https bereits auf die Adresse https:// weiter. Bei anderen Anwendungen sollten Sie in der Dokumentation nachsehen, wie der Betrieb hinter einem Proxy einzurichten ist (häufig handelt es sich um eine Einstellung für einen „trusted proxy“ oder eine „base URL“).

7. SSL-Zertifikat mit Let’s Encrypt

Sie können das Zertifikat auf der Registerkarte „SSL“ des Bearbeitungsfensters des Proxy-Hosts anfordern (in der Liste öffnen Sie es über ⋮ › Edit am Ende der Zeile):

  1. SSL Certificate: Wählen Sie die Option Request a new Certificate.
  2. Aktivieren Sie den Schalter Force SSL (leitet HTTP-Anfragen auf HTTPS um) sowie den Schalter HTTP/2 Support.
  3. Save.

Im Fenster Add Proxy Host unter dem Reiter SSL: SSL Certificate: Request a new Certificate; Force SSL und HTTP/2 Support aktiviert; HSTS Enabled und Use DNS Challenge deaktiviert

Wir konnten diesen Schritt nicht testen, da der Testserver über keine öffentliche Domain verfügte; die folgenden Angaben basieren auf der Dokumentation und dem Quellcode. Standardmäßig fordert NPM ein Zertifikat mittels der HTTP-01-Prüfung an: Let’s Encrypt sucht den Server über den Port 80 unter dem Domainnamen. Daher wird das Zertifikat erst ausgestellt, wenn die DNS-Einträge der Domain bereits auf den Server verweisen und Port 80 von außen erreichbar ist. Ist eine dieser Voraussetzungen nicht erfüllt, bricht die Anfrage mit einem Fehler ab. Die Zertifikate werden von NPM automatisch erneuert: Im Test erschienen beim Start im Protokoll die Zeilen „Let’s Encrypt Renewal Timer initialized“ und „Renewing SSL certs expiring within 30 days“.

Aktivieren Sie den Schalter HSTS Enabled nur, wenn Sie sicher sind, dass die Seite dauerhaft über HTTPS erreichbar bleibt: Die Browser versuchen danach eine Zeit lang gar nicht erst, die Seite über HTTP zu öffnen.

Zertifikate können Sie separat im Menü Certificates verwalten. Die Schaltfläche Add Certificate bietet die Optionen Let’s Encrypt via HTTP, Let’s Encrypt via DNS und Custom Certificate (Hochladen eines eigenen, beispielsweise gekauften Zertifikats). Im HTTP-Fenster überprüft die Schaltfläche Test laut Quellcode mithilfe eines externen Dienstes, ob die Domain von außen erreichbar ist, bevor eine Anfrage an Let’s Encrypt gestellt wird; es empfiehlt sich, diesen Test vor der Anfrage durchzuführen.

DNS-Überprüfung und Wildcard-Zertifikat

Falls Port 80 nicht geöffnet werden kann oder ein Wildcard-Zertifikat (*.pelda.hu) erforderlich ist, aktivieren Sie bitte den Schalter Use DNS Challenge. In diesem Fall erstellt NPM über die API des DNS-Anbieters einen TXT-Eintrag, den Let’s Encrypt anschließend überprüft. Bei der HTTP-Überprüfung können keine Wildcards beantragt werden; dies wird auf der Oberfläche auch ausdrücklich angezeigt: „Wildcards not permitted for this type“.

Auf der Registerkarte SSL ist der Schalter Use DNS Challenge aktiviert: DNS-Anbieter Cloudflare, im Feld Credentials File Content der Beispiel-API-Token, darunter der Hinweis, dass die Daten unverschlüsselt gespeichert werden, sowie das Feld Propagation Seconds

In der Liste DNS Provider waren im Test 88 Anbieter vertreten, darunter Cloudflare, DigitalOcean, Hetzner, OVH, Amazon Route 53 sowie der Standard RFC 2136 (für eigene DNS-Server). In das Feld Credentials File Content werden die API-Zugangsdaten des Anbieters eingegeben; das Feld zeigt ein Beispiel für die Ausfüllung an. NPM warnt davor, dass diese Daten unverschlüsselt in der Datenbank und in einer Datei gespeichert werden („This data will be stored as plaintext in the database and in a file!“); geben Sie daher bitte nur ein API-Token an, das auf die DNS-Einträge der jeweiligen Zone beschränkt ist, und nicht den Schlüssel für das gesamte Konto. Das Feld Propagation Seconds kann leer gelassen werden; sollten die Einträge vom Anbieter nur langsam veröffentlicht werden, erhöhen Sie diesen Wert.

Falls Sie NPM nicht verwenden, können Sie das Let’s-Encrypt-Zertifikat auch direkt beantragen; siehe: Beantragung eines Let’s-Encrypt-Zertifikats mit Certbot.

8. Zugriffslisten (Access Lists)

Sie können den Zugriff auf eine Anwendung anhand eines Passworts oder einer IP-Adresse einschränken, beispielsweise auf ein Admin-Panel oder eine noch nicht fertiggestellte Testseite. Erstellen Sie im Menü Access Lists mit der Schaltfläche Add Access List eine Liste:

  • Details: Name der Liste (Name). Ist Satisfy Any aktiviert, reicht entweder das Passwort oder die zugelassene IP-Adresse aus; ist diese Option deaktiviert, sind beide erforderlich. Pass Auth to Upstream leitet den Passwort-Header auch an die Anwendung weiter.
  • Authorizations: Kombinationen aus Benutzername und Passwort (Username, Password, Add).
  • Rules: Allow- und Deny-Regeln für IP-Adressen oder Adressbereiche (z. B. 192.168.1.0/24) in der angegebenen Reihenfolge. Wenn mindestens eine Regel vorhanden ist, wird am Ende der Liste automatisch eine „deny all“-Regel hinzugefügt.

Im Fenster Add Access List, Registerkarte Authorizations: Username teszt, Password ausgefüllt, Schaltfläche Add

Wählen Sie nach dem Speichern im Feld Access List des Proxy-Hosts die Liste anstelle von Publicly Accessible aus. Im Test gab die so geschützte Seite app2.pelda.hu ohne Passwort den Statuscode 401 zurück, während sie mit dem korrekten Benutzernamen und Passwort (curl -u teszt:jelszo ...) die Antwort von whoami lieferte. Das Passwort wird über HTTP unverschlüsselt übertragen; verwenden Sie daher den Passwortschutz nur in Verbindung mit einem SSL-Zertifikat.

9. Streams: TCP- und UDP-Weiterleitung

Im Menü „Hosts › Streams“ können Sie Nicht-Web-Datenverkehr (beispielsweise einen Port eines Datenbank- oder Spielservers) an einen Container weiterleiten. Dies haben wir nicht getestet. Laut Dokumentation muss der Stream-Port auch in der compose.yaml-Datei des NPM veröffentlicht werden (beispielsweise - "5432:5432"), andernfalls erreicht die Anfrage das NPM gar nicht. Machen Sie eine Datenbank nur dann auf diese Weise zugänglich, wenn ein Zugriff von außen tatsächlich erforderlich ist; in den meisten Fällen ist ein SSH-Tunnel sicherer.

10. Schutz der Verwaltungsoberfläche

  • Bitte veröffentlichen Sie den Port 81 nicht. Mit der oben genannten Einstellung 127.0.0.1:81:81 ist die Anmeldeseite von außen nicht erreichbar, sondern nur über einen SSH-Tunnel. Dass dies tatsächlich der Fall ist, zeigt auf dem Server der Befehl sudo ss -ltnp | grep ':81 ': Im Test wurde die Adresse 127.0.0.1:81 angezeigt, nicht 0.0.0.0:81.
  • Sicheres Passwort und Zwei-Faktor-Authentifizierung für das Konto (Two-Factor Auth).
  • Ein eigenes Konto für jeden. Im Menü Users können Sie weitere Benutzer hinzufügen; geben Sie das Administratorkonto nicht weiter und erteilen Sie das Recht Administrator nur denjenigen, die es tatsächlich benötigen.
  • Über den Schutz von SSH wird im Artikel Sicherheitseinstellungen des SSH-Servers berichtet, da der Verwaltungsbereich fortan über SSH erreichbar ist.

11. Backup

Der gesamte NPM-Status befindet sich in den Ordnern data und letsencrypt. Sichern Sie diese zusammen mit der Datei compose.yaml bei einem kurzen Stopp des Dienstes:

cd ~/npm
docker compose stop
sudo tar czf ~/npm-mentes-$(date +%F).tar.gz -C ~/npm data letsencrypt compose.yaml
docker compose start

Die Ordner gehören dem Benutzer „root“, daher ist die Verwendung von sudo erforderlich. Im Test dauerte der Ausfall nur wenige Sekunden; während dieser Zeit sind auch die über den Proxy bereitgestellten Seiten nicht erreichbar. Planen Sie die Sicherung daher bei stark frequentierten Seiten für eine ruhige Zeit ein. Entpacken Sie bei der Wiederherstellung das Backup in das Verzeichnis ~/npm eines neuen Servers, richten Sie das proxy-Netzwerk ein und starten Sie den Dienst mit dem Befehl docker compose up -d. Kopieren Sie das Backup außerdem auf einen weiteren Rechner.

Die Sicherung enthält auch die privaten Schlüssel der Zertifikate sowie die API-Token des DNS-Anbieters: Gehen Sie entsprechend damit um.

12. Aktualisierung

Erstellen Sie vor dem Update eine Sicherungskopie und lesen Sie die Release-Hinweise zur neuen Version auf der GitHub-Seite des Projekts. Ändern Sie anschließend den Eintrag für das Image in der Datei compose.yaml auf die neue Version (beispielsweise von jc21/nginx-proxy-manager:2.16.0 auf die aktuellere Version) und führen Sie dann Folgendes aus:

cd ~/npm
docker compose pull
docker compose up -d

Die Datenbankänderungen werden von NPM beim Start automatisch vorgenommen (im Protokoll erscheinen sie als Zeilen mit dem Text „Migrating Up…“). Das Löschen des alten Images wird im Artikel Löschen von Docker-Images, Containern und Volumes behandelt.

Häufige Fehler

  • 502 Bad Gateway: NPM kann den Zielcontainer nicht erreichen. Bitte überprüfen Sie, ob der Container läuft (docker compose ps), ob er sich im proxy-Netzwerk befindet (docker network inspect proxy) und ob der Forward Port dem internen Port des Containers entspricht.
  • Die Zertifikatsanforderung schlägt fehl: Die DNS-Einträge der Domain verweisen noch nicht auf den Server (die Übertragung der Änderung kann mehrere Stunden dauern) oder Port 80 ist von außen nicht erreichbar. Falls Sie Port 80 nicht öffnen können, nutzen Sie bitte die DNS-Prüfung.
  • Der NPM-Container startet nicht, „address already in use“: Ein anderes Programm belegt Port 80 oder 443; mit dem Befehl sudo ss -ltnp können Sie feststellen, welches Programm dies ist.
  • Weiterleitungsschleife hinter HTTPS: Die Anwendung erkennt nicht, dass der Zugriff über HTTPS erfolgt. Richten Sie in der Anwendung den Betrieb hinter einem Proxy ein (siehe oben).
Zurück: Linux-Artikel (76)