nginx Reverse Proxy: Vollständige Einrichtungsanleitung

Ein nginx Reverse Proxy ist ein nginx-Server, der eingehende Anfragen im Namen einer oder mehrerer Backend-Anwendungen entgegennimmt, jede Anfrage an das passende Backend weiterleitet und die Antwort an den Client zurückgibt. Diese Anleitung liefert Ihnen eine vollständige, direkt kopierbare nginx-Reverse-Proxy-Konfiguration: einen kompletten Server-Block mit proxy_pass und weitergeleiteten Headern, Upstream-Lastverteilung, SSL-Terminierung, WebSocket-Unterstützung, Puffer- und Timeout-Optimierung, gzip, pfadbasiertes Routing sowie Lösungen für die 502- und 504-Fehler, an denen die meisten scheitern.

Am Ende verfügen Sie über eine lauffähige nginx-Reverse-Proxy-Einrichtung, ein klares Verständnis dafür, wie die Teile zusammenwirken, und eine ehrliche Einschätzung, ab wann ein nginx Reverse Proxy nicht mehr das richtige Werkzeug ist und ein Forward Proxy oder Residential Proxy übernimmt.

DataImpulse ist ein ethischer Proxy-Anbieter mit mehr als 90 Millionen Residential-, Mobile- und Datacenter-IP-Adressen in 195 Ländern. Das nutzungsbasierte Modell beginnt bei 1 Dollar pro GB und umfasst Traffic ohne Ablaufdatum. Es wird für Web Scraping, Anzeigenverifizierung, Preisüberwachung, Marktforschung und Multi-Account-Management eingesetzt.

Ist nginx ein Reverse Proxy und wie funktioniert er?

Ja, nginx zählt zu den am weitesten verbreiteten Reverse Proxies, und Reverse Proxying ist eine Kernfunktion statt eines Zusatzes. Ein Reverse Proxy steht vor Ihren Backend-Servern, nimmt Client-Verbindungen unter einem öffentlichen Hostnamen an und leitet jede Anfrage an eine interne Anwendung weiter, die der Client nie direkt sieht.

Um die beweglichen Teile übersichtlich zu halten, verwendet dieser Leitfaden ein einfaches benanntes Modell. Nennen wir es das 5-Ebenen-Modell für nginx Reverse Proxies, und jede funktionierende Konfiguration unten besteht lediglich aus diesen übereinander angeordneten Ebenen:

• Listener. Die Direktive listen und server_name bestimmen, für welche Anfragen dieser Block zuständig ist (Port 80, Port 443, welcher Hostname).
• Location-Routing. location-Blöcke teilen eingehende Pfade auf, sodass /api/, /static/ und / jeweils an unterschiedliche Ziele gehen können.
• Upstream. Der upstream-Block benennt den Pool von Backend-Servern und die Methode der Lastverteilung.
• Header. proxy_set_header-Zeilen bewahren den ursprünglichen Host und die Client-IP, damit das Backend die tatsächliche Anfrage statt nginx sieht.
• TLS. ssl_certificate auf listen 443 terminiert HTTPS bei nginx, sodass Backends intern reines HTTP verwenden können.

Wenn Sie noch zwischen den beiden Proxy-Richtungen wählen, erklärt unser Beitrag zu Reverse Proxy vs. Forward Proxy das Konzept ausführlich. Dieser Artikel behandelt nur den Reverse-Fall. Für die ausgehende clientseitige Einrichtung lesen Sie den ergänzenden Leitfaden zu nginx Forward Proxy .

Was benötigen Sie, bevor Sie beginnen?

Sie benötigen einen Linux-Server mit installiertem nginx, mindestens eine Backend-Anwendung, die auf einem lokalen Port lauscht, und für HTTPS ein TLS-Zertifikat. Reverse Proxying verwendet ausschließlich den Standard-Build von nginx, daher sind weder eigene Module noch eine Neukompilierung nötig.

Vergewissern Sie sich vor Änderungen, dass nginx vorhanden und Ihre Konfiguration gültig ist:

nginx -v
sudo nginx -t

Der Test nginx -t analysiert die gesamte Konfiguration und meldet Syntaxfehler mit Datei- und Zeilennummer. Führen Sie ihn nach jeder Änderung in dieser Anleitung aus, denn nginx lädt eine defekte Konfiguration nicht neu und lässt die alte weiterlaufen. Legen Sie Ihre Reverse-Proxy-Server-Blöcke je nach Distribution in /etc/nginx/conf.d/ oder /etc/nginx/sites-available/ ab und laden Sie mit sudo nginx -s reload neu, sobald der Test erfolgreich ist. Halten Sie auch die Backend-Adresse bereit, etwa eine Node- oder Python-App auf 127.0.0.1:3000, denn darauf zeigt proxy_pass.

Wie richten Sie einen nginx Reverse Proxy Schritt für Schritt ein?

Beginnen Sie mit einem einzelnen Server-Block, der auf Port 80 lauscht, jede Anfrage mit proxy_pass an ein Backend weiterleitet und die weitergeleiteten Header setzt. Ergänzen Sie anschließend Lastverteilung, TLS, WebSockets, Pufferung und gzip. Dieser erste Block ist die minimal funktionierende nginx-Reverse-Proxy-Einrichtung:

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

Diese vier proxy_set_header-Zeilen sind nicht optional. Ohne sie sieht das Backend nginx als Client, protokolliert die falsche IP und kann fehlerhafte Weiterleitungs-URLs erzeugen. Host bewahrt den angeforderten Hostnamen, X-Real-IP und X-Forwarded-For übertragen die echte Client-Adresse, und X-Forwarded-Proto teilt der App mit, ob die ursprüngliche Anfrage HTTP oder HTTPS war.

Upstream-Lastverteilung hinzufügen. Um mehrere Backend-Instanzen vorzuschalten, definieren Sie einen upstream-Block und richten proxy_pass auf dessen Namen. Die Methode least_conn sendet jede Anfrage an die Instanz mit den wenigsten aktiven Verbindungen:

upstream app_backend {
    least_conn;
    server 10.0.0.11:3000;
    server 10.0.0.12:3000;
    server 10.0.0.13:3000 backup;
}

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

    location / {
        proxy_pass http://app_backend;
        proxy_set_header Host              $host;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Der backup-Server erhält nur Traffic, wenn die primären Server ausgefallen sind. Verwenden Sie ip_hash statt least_conn, wenn für Sticky Sessions derselbe Client am selben Backend bleiben soll.

SSL auf Port 443 terminieren. Reverse Proxies in der Produktion sollten HTTPS bereitstellen und reines HTTP umleiten. nginx übernimmt TLS, sodass Ihre Backends intern reines HTTP verwenden können:

server {
    listen 443 ssl;
    server_name app.example.com;

    ssl_certificate     /etc/letsencrypt/live/app.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/app.example.com/privkey.pem;
    ssl_protocols       TLSv1.2 TLSv1.3;

    location / {
        proxy_pass http://app_backend;
        proxy_set_header Host              $host;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

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

WebSockets unterstützen. WebSocket-Verbindungen beginnen als HTTP und führen dann ein Upgrade durch. nginx muss deshalb die Header Upgrade und Connection weitergeben und HTTP/1.1 verwenden. Geben Sie Echtzeitpfaden eine eigene location:

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

Das lange proxy_read_timeout verhindert, dass inaktive Sockets mitten in der Sitzung geschlossen werden, eine häufige Ursache abgebrochener Live-Verbindungen.

Pufferung und Timeouts abstimmen. Die Standardwerte sind vorsichtig gewählt. Langsame Backends profitieren von expliziten Werten, damit nginx eine Verbindung nicht schließt, bevor die App antwortet:

location / {
    proxy_pass http://app_backend;
    proxy_connect_timeout 5s;
    proxy_send_timeout    60s;
    proxy_read_timeout    60s;
    proxy_buffering       on;
    proxy_buffers         16 16k;
    proxy_buffer_size     32k;
}

gzip aktivieren. Das Komprimieren weitergeleiteter Antworten senkt die Bandbreite für Text-Assets. Platzieren Sie dies im http-Block, damit es für die gesamte Website gilt:

gzip on;
gzip_types text/plain text/css application/json application/javascript;
gzip_min_length 1024;
gzip_comp_level 5;

Nach Pfad routen. Ein Reverse Proxy kann mehrere Dienste vorschalten, indem er verschiedene location-Präfixe verschiedenen Upstreams zuordnet und statische Dateien direkt von der Festplatte ausliefert, ohne ein Backend zu berühren:

server {
    listen 80;
    server_name example.com;

    location /api/ {
        proxy_pass http://api_backend;
        proxy_set_header Host $host;
    }

    location /static/ {
        root /var/www/assets;
    }

    location / {
        proxy_pass http://web_backend;
        proxy_set_header Host $host;
    }
}

Wie überprüfen Sie, ob der nginx Reverse Proxy funktioniert?

Laden Sie nginx neu, senden Sie dann eine Anfrage an den öffentlichen Hostnamen und bestätigen Sie, dass die Antwort von Ihrem Backend statt von einer nginx-Standardseite kommt. Testen Sie die Konfiguration zuerst, damit ein Tippfehler die Website nicht lahmlegt:

sudo nginx -t && sudo nginx -s reload
curl -I http://app.example.com

Ein 200 oder eine erwartete Weiterleitung in den Antwort-Headern bedeutet, dass das Routing funktioniert. Um nachzuweisen, dass das Backend die weitergeleiteten Header erhält, prüfen Sie sein Zugriffsprotokoll oder einen Echo-Endpunkt und bestätigen Sie, dass es die echte Client-IP aus X-Forwarded-For statt 127.0.0.1 sieht. Sie können DNS auch umgehen, den Proxy direkt ansprechen und dabei den Hostnamen vortäuschen:

curl -H "Host: app.example.com" http://127.0.0.1

Führen Sie für HTTPS curl -I https://app.example.com aus und prüfen Sie, ob das Zertifikat akzeptiert und die Anfrage nicht herabgestuft wird. Wenn das Backend Links oder Weiterleitungen mit dem falschen Schema erzeugt, fehlt fast immer der Header X-Forwarded-Proto und es liegt kein TLS-Fehler vor.

Wie beheben Sie 502- und 504-Fehler?

Ein 502 Bad Gateway bedeutet, dass nginx den Upstream erreicht hat, aber eine ungültige oder abgelehnte Antwort erhielt. Ein 504 Gateway Timeout bedeutet, dass der Upstream die Verbindung akzeptierte, aber nicht rechtzeitig antwortete. Beides sind Upstream-Probleme, keine nginx-Bugs, und das Fehlerprotokoll nennt die genaue Ursache. Beobachten Sie es live, während Sie die Anfrage reproduzieren:

sudo tail -f /var/log/nginx/error.log
# [error] connect() failed (111: Connection refused) while connecting to upstream

Arbeiten Sie die üblichen Ursachen der Reihe nach durch:

• 502, Verbindung abgelehnt. Das Backend läuft nicht oder lauscht auf einer anderen Adresse beziehungsweise einem anderen Port als dem proxy_pass-Ziel. Bestätigen Sie dies direkt auf dem Server mit curl http://127.0.0.1:3000.
• 502, SELinux oder Firewall. Auf Systemen der RHEL-Familie hindert SELinux nginx daran, ausgehende Verbindungen zu öffnen, bis Sie setsebool -P httpd_can_network_connect 1 ausführen.
• 504, langsames Backend. Die App benötigt länger als proxy_read_timeout für ihre Antwort. Erhöhen Sie den Timeout für diese location oder beheben Sie die langsame Abfrage, statt das Problem global zu kaschieren.
• 502, große Header. Ein Backend, das große Antwort-Header sendet, kann die Proxy-Puffer überlaufen lassen. Erhöhen Sie proxy_buffer_size und proxy_buffers.
• Falscher Upstream ausgewählt. Wenn ein Server in einem Upstream-Pool ausfällt, markiert nginx ihn als fehlerhaft und versucht den nächsten. Sporadische 502-Fehler deuten daher oft auf ein einzelnes fehlerhaftes Backend hin.

Welcher Reverse Proxy passt, und wann benötigen Sie einen anderen Proxy?

Verwenden Sie einen nginx Reverse Proxy, wenn Sie TLS terminieren, Last verteilen oder Pfade vor Ihren eigenen Servern routen. Greifen Sie zu einem Forward Proxy oder Residential Proxy, wenn die Aufgabe ausgehende Anfragen von vielen IPs erfordert. nginx eignet sich hervorragend für eingehenden Traffic und ist nicht für ausgehenden Traffic ausgelegt. Hier ist die Entscheidungsmatrix:

• Verwenden Sie einen nginx Reverse Proxy, wenn Sie das Backend hosten, einen öffentlichen HTTPS-Endpunkt für mehrere interne Dienste wünschen, Lastverteilung über Instanzen benötigen oder Caching und gzip am Edge einsetzen möchten.
• Vermeiden Sie nginx als Ihren Proxy, wenn das Ziel ausgehende Anfragen sind, die scheinbar aus vielen unterschiedlichen IPs oder Ländern stammen müssen, denn ein Reverse Proxy geht über die einzelne Server-IP nach außen und kann Adressen nicht rotieren.

Bei Reverse Proxies im Besonderen gehen nginx, Caddy und HAProxy unterschiedliche Kompromisse ein:

Für umfangreiche ausgehende Automatisierung behandelt unser Leitfaden zu Best Practices für Web Scraping guide Rotation und Ratenkontrolle. Datacenter Proxies oder Mobile Proxies suit jobs where cost oder carrier IPs matter more than residential fidelity.

Welche Einschränkungen und Risiken hat ein nginx Reverse Proxy?

An nginx reverse proxy is powerful for inbound traffic but has real limits: it cannot rotate outbound IPs, misconfigured headers leak oder hide the client, and it adds an operational component you must patch and monitor. Knowing these keeps expectations honest.

• Eine Exit-IP. Jede ausgehende Anfrage vom Proxy verlässt den Server über dessen eigene IP. Ein Reverse Proxy hilft daher nicht bei Aufgaben, die viele Quelladressen benötigen.
• Header-Fehler bleiben unbemerkt. Wenn X-Forwarded-For fehlt, bleibt die echte Client-IP Ihrer App und ihrer Ratenbegrenzung verborgen. Wenn X-Forwarded-Proto fehlt, funktionieren HTTPS-Weiterleitungen nicht. nginx warnt Sie nicht.
• TLS- und Zertifikatspflege. Certificates expire, so you own renewal and reloads, usually through certbot and a cron job oder systemd timer.
• Ein neuer Ausfallpunkt. Der Proxy liegt nun im kritischen Pfad. Fällt er aus, ist jedes Backend dahinter nicht erreichbar. Deshalb sind Zustandsprüfungen und Monitoring wichtig.
• Kein Werkzeug für ausgehende Anonymität. Ein Reverse Proxy ist nicht dafür ausgelegt, die Herkunft von Anfragen zu verschleiern. Das ist die Aufgabe eines Forward Proxy.

nginx is not a DataImpulse product, and DataImpulse does not sell a managed scraping API oder a free web proxy. Run nginx yourself where it fits; where you need outbound scale, DataImpulse sources its IPs as ethische Proxies von Nutzern, die zustimmen und vergütet werden. Letzte Aktualisierung: 2026-07-22.

Häufig gestellte Fragen

Verwandte Leitfäden

• NGINX Forward Proxy
• Cloudflare Reverse Proxy
• Docker Reverse Proxy

Benötigen Sie ausgehende IPs, die nginx nicht rotieren kann?

Ein Reverse Proxy verarbeitet eingehenden Traffic. Wenn Ihre Aufgabe jedoch ausgehende Anfragen von vielen echten IPs benötigt, bietet DataImpulse mehr als 90 Mio. rotierende Residential-, Mobile- und Datacenter-IPs in 195 Ländern, nutzungsbasiert ab 1 Dollar pro GB mit Traffic ohne Ablaufdatum. Konto erstellen , um Gateway-Zugangsdaten zu erhalten und Ihren Client in den Pool zu leiten.