Nginx-Reverse-Proxy unter Ubuntu einrichten

Ein Reverse-Proxy steht vor einer oder mehreren Backend-Anwendungen und leitet Client-Anfragen an sie weiter. Nginx ist das beliebteste Werkzeug dafür: Es terminiert TLS, routet nach Hostname oder Pfad, ergänzt Caching und Komprimierung und schirmt einen App-Server ab, der nie für das offene Internet gedacht war. Ein typischer Anwendungsfall ist eine Node.js-, Python- oder Java-App auf localhost:3000, die unter einer echten Domain auf den Ports 80/443 verfügbar gemacht wird.

Diese Anleitung richtet Nginx als Reverse-Proxy unter Ubuntu 24.04 LTS ein: Nginx installieren, einen Server-Block schreiben, der an ein Backend weiterleitet, die korrekten Header setzen und anschließend kostenloses HTTPS mit Let’s Encrypt ergänzen. Jeder Befehl und jedes Konfigurationsbeispiel ist produktionsnah und direkt kopierbar.

Voraussetzungen

• Ubuntu-24.04-LTS-Server mit einem Benutzer, der sudo hat.
• Ein Domainname (z. B. app.example.com) mit einem A-Record, der auf die öffentliche IP des Servers zeigt — erforderlich für den HTTPS-Schritt.
• Eine Backend-Anwendung, die bereits lokal lauscht, etwa auf 127.0.0.1:3000.
• Die Ports 80 und 443 sind erreichbar. Falls Sie eine Firewall betreiben, siehe unsere UFW-Firewall-Anleitung.

Schritt 1: Nginx installieren

Aktualisieren Sie den Paketindex und installieren Sie Nginx aus dem Ubuntu-Repository:

sudo apt update
sudo apt install -y nginx

Nginx startet automatisch. Prüfen Sie, dass es läuft und beim Booten aktiviert ist:

systemctl status nginx

Rufen Sie http://ihre-server-ip auf, und Sie sollten die Standardseite „Welcome to nginx“ sehen.

Schritt 2: HTTP und HTTPS durch die Firewall erlauben

Ist UFW aktiv, öffnen Sie die Web-Ports über das mitgelieferte Anwendungsprofil:

sudo ufw allow 'Nginx Full'
sudo ufw status

Nginx Full öffnet sowohl 80 als auch 443. Verwenden Sie Nginx HTTP, wenn Sie vorerst nur Port 80 benötigen.

Schritt 3: Reverse-Proxy-Server-Block erstellen

Ubuntu organisiert Site-Konfigurationen unter /etc/nginx/sites-available/ und aktiviert sie über Symlinks in sites-enabled/. Erstellen Sie eine Konfiguration für Ihre Domain:

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

Fügen Sie Folgendes ein und passen Sie Domain und Backend-Adresse an:

server {
    listen 80;
    listen [::]:80;
    server_name app.example.com;
location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_http_version 1.1;
    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;

    # WebSocket-Unterstuetzung
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

}

Die proxy_set_header-Zeilen sind entscheidend: Ohne Host und X-Forwarded-* sehen Backend-Apps den falschen Hostnamen und glauben, jede Anfrage komme von 127.0.0.1 — das bricht Weiterleitungen, Logging und Rate-Limiting.

Schritt 4: Site aktivieren und neu laden

Aktivieren Sie die Konfiguration per Symlink nach sites-enabled/, prüfen Sie die Syntax und laden Sie dann neu:

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

Die Ausgabe von nginx -t sollte mit syntax is ok und test is successful enden. Führen Sie ihn stets vor dem Neuladen aus — eine fehlerhafte Konfiguration verweigert das Neuladen, statt den laufenden Server lahmzulegen.

Entfernen Sie optional die Standard-Site, damit sie keine nicht zugeordneten Hostnamen abfängt:

sudo rm /etc/nginx/sites-enabled/default
sudo systemctl reload nginx

Schritt 5: Funktion des Proxys prüfen

Rufen Sie Ihre Site über Nginx ab und bestätigen Sie, dass das Backend antwortet:

curl -I http://app.example.com

Sie sollten ein 200 OK (oder was Ihre App zurückgibt) mit einem Server: nginx-Header erhalten. Bei 502 Bad Gateway hat Nginx kein Backend erreicht — prüfen Sie mit ss -tlnp | grep 3000, ob die App tatsächlich auf der Adresse aus proxy_pass lauscht.

Schritt 6: HTTPS mit Let’s Encrypt ergänzen

Installieren Sie Certbot und sein Nginx-Plugin über snap — die vom Projekt unter Ubuntu empfohlene Methode:

sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot

Fordern Sie ein Zertifikat an und installieren Sie es. Certbot passt Ihren Server-Block automatisch an, fügt die TLS-Konfiguration und eine HTTP→HTTPS-Weiterleitung hinzu:

sudo certbot --nginx -d app.example.com

Beantworten Sie die Abfragen (E-Mail, Bedingungen). Certbot installiert einen systemd-Timer, der Zertifikate vor Ablauf erneuert. Bestätigen Sie die Erneuerung mit einem Probelauf:

sudo certbot renew --dry-run

Schritt 7: Sichere Einrichtung bestätigen

Testen Sie den HTTPS-Endpunkt und die Weiterleitung von einfachem HTTP:

curl -I https://app.example.com
curl -I http://app.example.com

Die HTTPS-Anfrage sollte 200 zurückgeben, die HTTP-Anfrage eine 301-Weiterleitung auf die https://-URL.

Fehlerbehebung und typische Stolperfallen

• 502 Bad Gateway — das Backend ist nicht erreichbar oder proxy_pass zeigt auf den falschen Host/Port. Prüfen Sie mit ss -tlnp und den App-Logs.
• Weiterleitungsschleifen — das Backend erzwingt selbst HTTPS, vertraut aber X-Forwarded-Proto nicht. Stellen Sie sicher, dass dieser Header gesetzt ist und die App ihn berücksichtigt.
• Certbot scheitert bei der Validierung — das DNS zeigt noch nicht auf den Server oder Port 80 ist gesperrt. Prüfen Sie A-Record und Firewall.
• WebSocket-Abbrüche — die Header Upgrade und Connection fehlen im location-Block.
• Änderungen ignoriert — Sie haben sites-available bearbeitet, aber der Symlink in sites-enabled zeigt woandershin, oder Sie haben systemctl reload nginx vergessen.

Wie es weitergeht

Ein einzelner Nginx-Reverse-Proxy bedient einen Host gut, aber Produktionslast braucht irgendwann mehrere Backends und Health-Checks. Genau das bietet ein Cloud-Load-Balancer — siehe unsere Anleitung zum Einrichten eines Octavia-Load-Balancers in OpenStack. Damit Nginx selbst über Neustarts und Updates sauber läuft, lesen Sie Verwalten von systemd-Diensten.

Fazit

Sie haben Nginx installiert, einen Reverse-Proxy mit den korrekten Weiterleitungs-Headern konfiguriert, die Weiterleitung an Ihr Backend geprüft und ihn mit einem automatisch erneuerten Let’s-Encrypt-Zertifikat abgesichert. Dieses Muster stellt interne Apps sicher auf einem einzelnen Server bereit. Wenn Sie Hochverfügbarkeit in Cloud-Größenordnung über viele Backends benötigen, betreibt clouditiv verwaltetes Load-Balancing auf einer souveränen, ISO 27001 / BSI C5-zertifizierten Private Cloud mit Ubuntu 24.04 + OpenStack 2025.2 und Ihren Daten in Deutschland. Entdecken Sie unsere On-Premise-Cloud-Lösung.