Nginx als Reverse Proxy mit TLS bedeutet: Ein Dienst läuft intern auf Ihrem Server, meist nur auf einem lokalen Port, und Nginx nimmt die Anfragen unter Ihrer Domain entgegen, verschlüsselt sie per HTTPS und leitet sie an diesen internen Dienst weiter. Dabei greifen mehrere Bausteine ineinander: Domain, Port, Backend, Nginx-Konfiguration und Zertifikat.

Deshalb folgt diese Anleitung einer festen Reihenfolge: zuerst das Backend prüfen, dann Nginx für HTTP einrichten, danach TLS einbinden, die Umleitung ergänzen und die Konfiguration testen. So lässt sich jeder Fehler einem Schritt zuordnen.

Voraussetzungen

Ein Debian- oder Ubuntu-Server mit sudo-Rechten; für Nginx allein genügen 1 CPU-Kern und 1 GB RAM, der Bedarf richtet sich nach dem Backend
Eine Domain, deren A- bzw. AAAA-Eintrag auf den Server zeigt, und freie Ports 80 und 443
Ein interner Dienst, der lokal auf einem Port läuft, zum Beispiel 127.0.0.1:3000
Ein vorhandenes TLS-Zertifikat, zum Beispiel aus unserer Anleitung Let's Encrypt mit certbot

Wichtig: Ein Reverse Proxy ersetzt Ihren internen Dienst nicht, er sitzt davor. Läuft das Backend nicht sauber, kann Nginx das nicht ausgleichen.

Schritt 1: Backend-Dienst und Zielport prüfen

Bevor Sie Nginx anfassen, prüfen Sie den eigentlichen Zielprozess. Nur wenn dieser Dienst lokal erreichbar ist, lohnt sich die Proxy-Konfiguration.

ss -tulpn | grep 3000

curl -I http://127.0.0.1:3000

Läuft Ihr Dienst auf einem anderen Port, passen Sie den Befehl an. Sie müssen wissen, auf welchem Host und Port das Backend erreichbar ist. Typisch ist 127.0.0.1 oder localhost, keine öffentliche IP.

Verifizieren: ss zeigt einen Prozess im Zustand LISTEN auf dem Zielport, und curl -I liefert eine HTTP-Statuszeile (zum Beispiel HTTP/1.1 200 OK). Klappt das nicht, beheben Sie zuerst das Problem am Dienst selbst.

Schritt 2: Nginx installieren und Grundstatus kontrollieren

Ist Nginx noch nicht installiert, holen Sie das jetzt nach und prüfen danach den Dienststatus.

sudo apt update
sudo apt install nginx

systemctl status nginx
nginx -v

Ist Nginx bereits vorhanden, reicht die Statusprüfung. Notieren Sie die Version aus nginx -v, sie entscheidet in Schritt 4 über die HTTP/2-Schreibweise.

Verifizieren: systemctl status nginx zeigt active (running). Steht dort failed, nennt die Ausgabe den Grund, meist einen belegten Port 80.

Schritt 3: Reverse-Proxy-Server-Block für HTTP einrichten

Richten Sie zuerst die einfache HTTP-Variante ein. Damit prüfen Sie, ob Nginx an das Backend weiterleitet, bevor TLS dazukommt.

sudo nano /etc/nginx/sites-available/example.com

Ein einfacher Startpunkt:

server {
    listen 80;
    server_name example.com www.example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        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;
    }
}

Aktivieren Sie danach die Site, testen Sie die Syntax und laden Sie Nginx neu:

sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/example.com
sudo nginx -t && sudo systemctl reload nginx

Verifizieren: curl -I http://example.com liefert dieselbe Antwort wie curl -I http://127.0.0.1:3000 aus Schritt 1. Erscheint die Nginx-Standardseite, greift noch der Block default oder der server_name passt nicht zur aufgerufenen Domain.

Schritt 4: TLS-Zertifikate einbinden und HTTPS-Block ergänzen

Ergänzen Sie in derselben Datei einen zweiten Server-Block für HTTPS. Dafür brauchen Sie die Zertifikatspfade, bei certbot typischerweise unter /etc/letsencrypt/live/example.com/.

server {
    listen 443 ssl;
    http2 on;
    server_name example.com www.example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:3000;
        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;
    }
}

Die Direktive http2 on; gibt es ab Nginx 1.25.1. Zeigt nginx -v eine ältere Version (Debian 12: 1.22, Ubuntu 24.04: 1.24), lassen Sie diese Zeile weg und schreiben stattdessen listen 443 ssl http2;. Ab 1.25.1 ist diese alte Schreibweise veraltet und erzeugt bei nginx -t eine Warnung.

Nginx beendet hier die TLS-Verbindung und spricht intern unverschlüsselt mit Ihrem Backend. Deshalb sollte das Backend nur auf 127.0.0.1 lauschen.

Verifizieren: sudo ls -l /etc/letsencrypt/live/example.com/ zeigt fullchain.pem und privkey.pem, und sudo openssl x509 -in /etc/letsencrypt/live/example.com/fullchain.pem -noout -subject -enddate nennt Ihre Domain und ein Ablaufdatum in der Zukunft.

Schritt 5: HTTP auf HTTPS umleiten

Steht HTTPS, leiten Sie Aufrufe über Port 80 auf HTTPS um. Ersetzen Sie dazu den HTTP-Block aus Schritt 3 vollständig durch diesen Block. Bleiben beide stehen, meldet nginx -t „conflicting server name“ und nur einer der Blöcke greift.

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

Die Datei enthält danach genau zwei Server-Blöcke: diesen Umleitungsblock für Port 80 und den HTTPS-Block aus Schritt 4.

Verifizieren: grep -c "listen 80" /etc/nginx/sites-available/example.com gibt 1 aus.

Schritt 6: Nginx-Konfiguration testen und neu laden

Testen Sie Änderungen, bevor Sie sie aktivieren. nginx -t meldet Syntax- und Pfadfehler, bevor ein laufender Webserver ausfällt.

sudo nginx -t

sudo systemctl reload nginx

Schlägt nginx -t fehl, laden Sie nicht neu. Korrigieren Sie zuerst den gemeldeten Fehler und testen Sie erneut.

Verifizieren: nginx -t meldet syntax is ok und test is successful, danach zeigt systemctl status nginx weiterhin active (running).

Schritt 7: Proxy-Verhalten und Zertifikat live prüfen

Jetzt folgt der Gesamttest über die Domain.

curl -I http://example.com

curl -I https://example.com

Achten Sie auf Folgendes:

HTTP antwortet mit 301 und einem Location-Header auf die HTTPS-Adresse
HTTPS liefert eine gültige Antwort ohne Zertifikatsfehler
Der ausgelieferte Inhalt stammt tatsächlich von Ihrem Backend

Stimmt etwas nicht, helfen die Logs unter /var/log/nginx/error.log weiter. Grundlagen dazu im Artikel Logs lesen mit journalctl und /var/log.

Verifizieren: Der HTTP-Aufruf endet mit 301, der HTTPS-Aufruf mit dem Status Ihres Backends (zum Beispiel 200), und curl meldet keinen Zertifikatsfehler.

Troubleshooting

502 Bad Gateway: Nginx erreicht Ihr Backend nicht. Prüfen Sie Zielport, Backend-Dienst und lokale Erreichbarkeit mit curl.
nginx -t meldet Zertifikatsfehler: Meist stimmen die Pfade nicht oder das Zertifikat existiert dort nicht mehr.
Warnung „the listen ... http2 directive is deprecated“: Ihre Nginx-Version ist 1.25.1 oder neuer. Verwenden Sie listen 443 ssl; plus http2 on;.
Warnung „conflicting server name“: Zwei Blöcke auf demselben Port nennen denselben server_name, oft der alte HTTP-Block aus Schritt 3. Entfernen Sie den doppelten Block.
HTTP bleibt unverschlüsselt: Die Umleitung auf Port 80 fehlt oder ein anderer Server-Block greift.
Der Dienst läuft, aber Antworten sehen falsch aus: Prüfen Sie Header wie X-Forwarded-Proto und Host, wenn Ihre Anwendung Reverse-Proxy-Informationen erwartet.

Häufige Fragen

Warum prüfe ich zuerst das Backend und nicht direkt Nginx?

Ein Reverse Proxy kann nur weiterleiten, was dahinter funktioniert. Ist das Backend ausgefallen, suchen Sie sonst am falschen Ende.

Wofür ist proxy_pass zuständig?

Damit legen Sie fest, an welchen internen Dienst Nginx eine Anfrage weitergibt.

Warum brauche ich trotzdem noch certbot oder ein Zertifikat?

Nginx beendet die HTTPS-Verbindung nach außen. Dafür braucht Nginx ein gültiges Zertifikat und den passenden privaten Schlüssel.

Was ist der Unterschied zwischen reload und restart?

reload lädt die Konfiguration neu, ohne bestehende Verbindungen hart zu trennen. Für normale Konfigurationsänderungen ist das der richtige Weg.

Fazit

Ein funktionierender Nginx-Reverse-Proxy mit TLS besteht aus einer Kette: laufendes Backend, korrekter Proxy-Block, gültige Zertifikatspfade und ein erfolgreicher Test mit nginx -t. Halten Sie diese Reihenfolge ein, lässt sich jeder Fehler schnell eingrenzen.

Als Ergänzung passen Let's Encrypt mit certbot und Logs lesen mit journalctl und /var/log.

Weiterführende Anleitungen und Quellen

Quellen: Nginx Documentation, Nginx-Modul ngx_http_v2_module, Certbot Documentation, Certbot EFF Instructions.