Nginx als Reverse Proxy mit TLS einzurichten bedeutet im Kern: Ein Dienst läuft intern auf deinem Server, oft nur auf einem lokalen Port, und Nginx nimmt die eingehenden Webanfragen unter deiner Domain entgegen, verschlüsselt sie per HTTPS und leitet sie an diesen internen Dienst weiter. Für Einsteiger wirkt das oft komplizierter, als es ist, weil mehrere Bausteine gleichzeitig zusammenkommen: Domain, Port, Backend, Nginx-Konfiguration und Zertifikat.

Genau deshalb gehen wir hier in einer festen Reihenfolge vor. Erst prüfen wir, ob das Backend überhaupt sauber läuft. Dann richten wir Nginx für HTTP ein. Erst danach binden wir TLS ein, ergänzen die Umleitung und testen die Konfiguration. So lässt sich jeder Fehler einem klaren Schritt zuordnen.

Voraussetzungen

Ein Debian- oder Ubuntu-Server mit sudo-Rechten
Nginx soll als vorgeschalteter Webserver genutzt werden
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 deinen internen Dienst nicht. Er sitzt davor. Wenn das Backend selbst nicht sauber läuft, kann Nginx das nicht wegzaubern.

Schritt 1: Backend-Dienst und Zielport sauber prüfen

Bevor du Nginx anfasst, prüfst du den eigentlichen Zielprozess. Nur wenn dieser Dienst lokal erreichbar ist, lohnt sich die Proxy-Konfiguration überhaupt.

ss -tulpn | grep 3000

curl -I http://127.0.0.1:3000

Wenn dein Dienst auf einem anderen Port läuft, passt du den Befehl entsprechend an. Entscheidend ist: Du musst wissen, auf welchem Host und Port das Backend erreichbar ist. Typisch ist 127.0.0.1 oder localhost, nicht eine öffentliche IP.

Verifizieren: Der Schritt ist erfolgreich, wenn du den Zielport eindeutig identifizieren kannst und curl lokal eine sinnvolle Antwort vom Backend erhält. Wenn das schon nicht klappt, gehst du zuerst zum Dienst selbst zurück.

Schritt 2: Nginx installieren und Grundstatus kontrollieren

Wenn Nginx noch nicht installiert ist, holst du das jetzt nach. Danach prüfst du sofort, ob der Dienst läuft.

sudo apt update
sudo apt install nginx

systemctl status nginx

Wenn Nginx bereits vorhanden ist, reicht oft die Statusprüfung. Dieser Schritt ist wichtig, weil du sauber trennen willst: Läuft Nginx überhaupt? Erst dann macht die inhaltliche Konfiguration Sinn.

Verifizieren: Der Schritt ist erfolgreich, wenn systemctl status nginx auf active (running) steht oder dir zumindest klar zeigt, warum Nginx gerade nicht aktiv ist.

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

Jetzt baust du zuerst die einfache HTTP-Variante. Damit prüfst du, ob Nginx sauber an das Backend weiterleitet, bevor TLS dazukommt.

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

Ein einfacher Startpunkt sieht so aus:

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;
    }
}

Danach aktivierst du die Site:

sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/example.com

Verifizieren: Der Schritt ist erfolgreich, wenn die Konfigurationsdatei vorhanden ist und der Proxy-Zielport exakt zu deinem Backend passt. Hier musst du vor allem prüfen, dass nicht aus Versehen der falsche Port oder Host eingetragen wurde.

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

Wenn HTTP als Struktur steht, kommt jetzt TLS dazu. Dafür brauchst du die Zertifikatspfade, typischerweise aus certbot unter /etc/letsencrypt/live/DEINE-DOMAIN/.

server {
    listen 443 ssl http2;
    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;
    }
}

Wichtig ist hier weniger, dass du jede Direktive auswendig lernst, sondern dass du den Zusammenhang verstehst: Nginx terminiert TLS und spricht intern weiter mit deinem Backend.

Verifizieren: Der Schritt ist erfolgreich, wenn die Pfade zu fullchain.pem und privkey.pem wirklich existieren und genau zu deiner Domain gehören. Falsche Pfade sind einer der häufigsten Gründe für einen kaputten Reload.

Schritt 5: HTTP auf HTTPS umleiten

Wenn HTTPS steht, willst du normale Aufrufe über Port 80 in der Regel sauber auf HTTPS umleiten.

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

Damit bekommt jeder unverschlüsselte Aufruf sofort eine klare Weiterleitung auf die verschlüsselte Variante.

Verifizieren: Der Schritt ist erfolgreich, wenn ein HTTP-Aufruf deiner Domain nicht mehr den eigentlichen Inhalt direkt liefert, sondern sauber auf die HTTPS-Adresse weiterleitet.

Schritt 6: Nginx-Konfiguration testen und neu laden

Bevor du Änderungen aktivierst, testest du sie. Dieser Schritt ist Pflicht, weil Nginx dir damit Syntax- und Pfadfehler meldet, bevor du einen laufenden Webserver beschädigst.

sudo nginx -t

sudo systemctl reload nginx

Wenn nginx -t fehlschlägt, lädst du nicht neu. Erst den gemeldeten Fehler korrigieren, dann erneut testen.

Verifizieren: Der Schritt ist erfolgreich, wenn nginx -t ausdrücklich erfolgreich meldet und der Reload ohne Fehler durchläuft.

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

Jetzt kommt der eigentliche Gesamttest. Du prüfst nicht mehr nur einzelne Dateien, sondern das Ergebnis für einen echten Aufruf über die Domain.

curl -I http://example.com

curl -I https://example.com

Worauf du achtest:

HTTP sollte auf HTTPS umleiten
HTTPS sollte eine gültige Antwort liefern
Der ausgelieferte Inhalt sollte tatsächlich von deinem Backend stammen

Wenn etwas nicht stimmt, helfen dir die Logs weiter. Dafür passt unser Grundlagenartikel Logs lesen mit journalctl und /var/log.

Verifizieren: Der Schritt ist erfolgreich, wenn beide Prüfungen logisch zusammenpassen: HTTP leitet weiter, HTTPS liefert Inhalte und das Zertifikat gehört sichtbar zur richtigen Domain.

Troubleshooting

502 Bad Gateway: Nginx erreicht dein Backend nicht. Prüfe Zielport, Backend-Dienst und lokale Erreichbarkeit mit curl.
nginx -t meldet Zertifikatsfehler: Meist stimmen die Pfade nicht oder das Zertifikat existiert dort nicht mehr.
HTTP bleibt unverschlüsselt: Dann fehlt oft die Weiterleitung auf Port 80 oder der falsche Server-Block greift.
Der Dienst läuft, aber Antworten sehen falsch aus: Prüfe Header wie X-Forwarded-Proto und Host, wenn deine Anwendung Reverse-Proxy-Informationen erwartet.

Häufige Fragen

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

Weil ein Reverse Proxy nur weiterleiten kann, was dahinter überhaupt funktioniert. Wenn das Backend tot ist, suchst du sonst am falschen Ende.

Wofür ist proxy_pass zuständig?

Damit sagst du Nginx, an welchen internen Dienst eine Anfrage weitergegeben werden soll.

Warum brauche ich trotzdem noch certbot oder ein Zertifikat?

Weil Nginx die HTTPS-Verbindung nach außen terminiert. 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 den Dienst hart neu zu starten. Für normale Config-Änderungen ist das meist der sauberere Weg.

Fazit

Ein funktionierender Nginx-Reverse-Proxy mit TLS ist keine einzelne magische Konfigurationsdatei, sondern eine klare Kette aus funktionierendem Backend, sauberem Proxy-Block, korrekten Zertifikatspfaden und einem erfolgreichen Testlauf. Wenn du diese Reihenfolge einhältst, wird Fehlersuche deutlich einfacher und das Setup viel verlässlicher.

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

Weiterführende Anleitungen und Quellen

Quellen: Nginx Documentation, Certbot Documentation, Certbot EFF Instructions.