Nginx Reverse Proxy einrichten: Der komplette Guide

Wer mehrere Webapplikationen auf einem Server betreibt oder Backend-Dienste hinter einem zentralen Einstiegspunkt bündeln möchte, kommt an Nginx als Reverse Proxy kaum vorbei. Nginx ist nicht nur einer der schnellsten Webserver der Welt, sondern eignet sich dank seiner Event-basierten Architektur hervorragend als vorgeschalteter Proxy – für Load Balancing, SSL-Terminierung und den Schutz interner Dienste. In diesem Guide richtest du Schritt für Schritt einen produktionsreifen Nginx Reverse Proxy ein.

Was ist ein Reverse Proxy und warum Nginx?

Ein Reverse Proxy sitzt zwischen dem Client (Browser) und einem oder mehreren Backend-Servern. Er nimmt Anfragen entgegen, leitet sie an den zuständigen Dienst weiter und gibt die Antwort an den Client zurück. Der Client kommuniziert dabei ausschließlich mit dem Proxy – die Backend-Server bleiben verborgen.

Nginx ist dafür aus mehreren Gründen die erste Wahl:

• Performance: Tausende gleichzeitige Verbindungen bei minimalem Ressourcenverbrauch
• Flexibilität: Virtual Hosts, SSL, Rate Limiting und Caching in einer Konfiguration
• Verbreitung: Riesige Community, exzellente Dokumentation, breite Ökosystem-Unterstützung
• Stabilität: Bewährt im Einsatz bei Netflix, Cloudflare und Millionen weiterer Websites

Nginx installieren

Auf einem Ubuntu/Debian-System installierst du Nginx mit:

sudo apt update
sudo apt install nginx -y
sudo systemctl enable nginx
sudo systemctl start nginx

Auf CentOS/RHEL:

sudo dnf install nginx -y
sudo systemctl enable nginx
sudo systemctl start nginx

Prüfe anschließend, ob der Dienst läuft:

sudo systemctl status nginx
nginx -v

Grundlegende Reverse-Proxy-Konfiguration

Angenommen, du betreibst eine Node.js-App auf Port 3000 und möchtest sie über Port 80 erreichbar machen. Erstelle dafür eine neue Konfigurationsdatei:

sudo nano /etc/nginx/sites-available/meine-app

Die einfachste Nginx Reverse Proxy-Konfiguration sieht so aus:

server {
    listen 80;
    server_name meine-app.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;
    }
}

Aktiviere die Seite und teste die Konfiguration:

sudo ln -s /etc/nginx/sites-available/meine-app /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

Die wichtigsten Proxy-Header erklärt

• Host: Übergibt den ursprünglichen Hostnamen an das Backend
• X-Real-IP: Die echte IP-Adresse des Clients
• X-Forwarded-For: Die gesamte Kette von Proxy-IPs
• X-Forwarded-Proto: Ob die Anfrage über HTTP oder HTTPS kam

Ohne diese Header weiß dein Backend nicht, woher die Anfrage tatsächlich stammt – es sieht nur 127.0.0.1.

Virtual Hosts für mehrere Dienste

Die wahre Stärke eines Nginx Reverse Proxy zeigt sich, wenn du mehrere Anwendungen über einen Server bedienst. Jeder Dienst bekommt seinen eigenen Virtual Host (Server-Block):

# /etc/nginx/sites-available/api
server {
    listen 80;
    server_name api.example.com;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

# /etc/nginx/sites-available/dashboard
server {
    listen 80;
    server_name dashboard.example.com;

    location / {
        proxy_pass http://127.0.0.1:4200;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

Nginx entscheidet anhand des server_name, welcher Block die Anfrage verarbeitet. So laufen beliebig viele Dienste hinter einer einzigen IP-Adresse.

SSL-Terminierung mit Let's Encrypt

In der Produktion ist HTTPS Pflicht. Die SSL-Terminierung am Reverse Proxy hat den Vorteil, dass sich deine Backend-Dienste nicht um Zertifikate kümmern müssen.

Zertifikat erstellen

sudo apt install certbot python3-certbot-nginx -y
sudo certbot --nginx -d meine-app.example.com

Resultierende Konfiguration

Certbot passt deine Konfiguration automatisch an. Das Ergebnis sieht ungefähr so aus:

server {
    listen 443 ssl http2;
    server_name meine-app.example.com;

    ssl_certificate /etc/letsencrypt/live/meine-app.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/meine-app.example.com/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;

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

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

Richte die automatische Erneuerung ein:

sudo certbot renew --dry-run

Der Cronjob wird von Certbot automatisch unter /etc/cron.d/certbot oder als systemd-Timer angelegt.

Rate Limiting gegen Missbrauch

Rate Limiting schützt deine Backend-Dienste vor Überlastung und Brute-Force-Angriffen. Die Konfiguration erfolgt in zwei Schritten:

# In der http-Ebene (/etc/nginx/nginx.conf)
http {
    limit_req_zone $binary_remote_addr zone=general:10m rate=10r/s;
    limit_req_zone $binary_remote_addr zone=login:10m rate=1r/s;

    # ... weitere Konfiguration
}

# Im Server-Block
server {
    listen 443 ssl http2;
    server_name meine-app.example.com;

    # Allgemeines Rate Limiting
    location / {
        limit_req zone=general burst=20 nodelay;
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    # Strengeres Limiting für Login-Endpunkte
    location /api/login {
        limit_req zone=login burst=3 nodelay;
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

• rate=10r/s: Maximal 10 Anfragen pro Sekunde pro IP
• burst=20: Bis zu 20 Anfragen dürfen kurzzeitig „vorarbeiten"
• nodelay: Burst-Anfragen werden sofort verarbeitet, nicht verzögert

Best Practices für die Produktion

Timeouts richtig setzen

location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_connect_timeout 5s;
    proxy_send_timeout 60s;
    proxy_read_timeout 60s;
    send_timeout 60s;
}

Security-Header hinzufügen

server {
    # ... SSL und Proxy-Konfiguration

    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-XSS-Protection "1; mode=block" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
}

WebSocket-Support

Falls deine Anwendung WebSockets nutzt (z. B. Chat-Apps oder Live-Dashboards):

location /ws/ {
    proxy_pass http://127.0.0.1:3000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;
    proxy_read_timeout 86400s;
}

Logging und Debugging

Konfiguriere separate Access- und Error-Logs pro Virtual Host:

server {
    access_log /var/log/nginx/meine-app.access.log;
    error_log /var/log/nginx/meine-app.error.log warn;

    # ...
}

Bei Problemen hilft ein temporärer Debug-Modus:

sudo nginx -t          # Konfiguration auf Syntaxfehler prüfen
sudo tail -f /var/log/nginx/meine-app.error.log   # Fehler live beobachten
curl -I https://meine-app.example.com              # Header prüfen

Checkliste vor dem Go-Live

• ✅ nginx -t gibt syntax is ok zurück
• ✅ SSL-Zertifikate sind gültig und erneuern sich automatisch
• ✅ HTTP leitet auf HTTPS weiter (301-Redirect)
• ✅ Security-Header sind gesetzt (prüfbar via securityheaders.com)
• ✅ Rate Limiting ist aktiv, insbesondere für Login- und API-Endpunkte
• ✅ Logs sind konfiguriert und werden rotiert (logrotate)
• ✅ Firewall erlaubt nur Port 80 und 443

Fazit

Ein Nginx Reverse Proxy ist das Schweizer Taschenmesser der modernen Server-Architektur. Mit wenigen Konfigurationszeilen bündelst du mehrere Dienste hinter einer Adresse, terminierst SSL zentral und schützt deine Backends vor direktem Zugriff und Überlastung. Die in diesem Guide gezeigten Konfigurationen – von der Grundeinrichtung über Virtual Hosts und SSL-Terminierung bis hin zu Rate Limiting und Security-Headern – bilden eine solide Basis für produktionsreife Setups.

Starte mit der einfachen Proxy-Konfiguration, füge SSL über Let's Encrypt hinzu und erweitere schrittweise um Härtungsmaßnahmen. Und das Wichtigste: Teste jede Änderung mit nginx -t, bevor du sie live schaltest. So baust du dir eine robuste, performante und sichere Infrastruktur – ohne unnötige Komplexität.