Was ist ein Reverse Proxy?

• Server und Infrastruktur
• Aktualisiert: 04.10.2026
• Ca. 10 Min. Lesezeit

Was macht ein Reverse Proxy?

1. 1

   Wo er steht: der Unterschied zum Forward Proxy

   Beide Arten stehen dazwischen, dienen aber unterschiedlichen Seiten:

   • Ein Forward Proxy steht vor dem Client und geht in dessen Auftrag ins Internet. In Firmennetzen dient er dazu, den ausgehenden Verkehr zu kontrollieren.
   • Ein Reverse Proxy steht vor dem Server und nimmt in dessen Auftrag Anfragen entgegen. Eingerichtet wird er vom Betreiber der Website; der Besucher muss nichts einstellen und bemerkt nicht einmal, dass es ihn gibt.

   Die Server hinter dem Reverse Proxy heißen Backend-Server (in der Nginx-Konfiguration upstream). Ein Backend kann eine PHP-, Node.js-, Java- oder Python-Anwendung sein, ein weiterer Webserver oder ein Container.

   : Vergrößern

2. 2

   Welche Aufgaben er übernimmt

   • Ein Einstiegspunkt: Alle Anfragen kommen über eine Adresse und einen Port herein. In der Firewall wird nur der Reverse Proxy zum Internet geöffnet; die Zugriffsprotokolle laufen an einer Stelle zusammen.
   • SSL-/TLS-Terminierung: Das Zertifikat wird auf dem Reverse Proxy installiert, die verschlüsselte Verbindung wird dort entschlüsselt. Es ist nicht nötig, für jede Anwendung ein eigenes Zertifikat einzurichten und zu erneuern.
   • Lastverteilung (Load Balancing): Die Anfragen werden auf mehrere Backend-Server verteilt; antwortet einer nicht, geht die Anfrage an die anderen.
   • Caching: Antworten, die sich nicht ändern, werden gespeichert und erneut ausgeliefert, ohne dass das Backend überhaupt angesprochen wird.
   • Backend verbergen und schützen: Die Anwendungsserver bleiben im internen Netz und sind aus dem Internet nicht direkt erreichbar. Fehlerhafte oder übergroße Anfragen können abgewiesen werden, bevor sie das Backend erreichen.
   • Routing: Mehrere Anwendungen werden unter einer Domain veröffentlicht, nach Pfad (z. B. /api/) oder nach Subdomain (z. B. panel.beispiel.de).
   • Komprimierung: Textbasierte Antworten werden komprimiert an den Besucher gesendet; die Anwendung muss sich nicht darum kümmern.
   • Ratenbegrenzung (Rate Limiting): Die Zahl der Anfragen, die eine Quelle in einem bestimmten Zeitraum stellen darf, wird beschränkt; aufwendige Endpunkte wie Anmeldung und Suche werden geschützt.

   : Vergrößern

3. 3

   Typische Architekturen

   • Eine Anwendung: Reverse Proxy und Anwendung liegen auf demselben Server. Die Anwendung lauscht nur auf einer lokalen Adresse (z. B. 127.0.0.1:3000); nach außen geöffnet ist der Reverse Proxy. Das ist die häufigste Konstellation und auch für Websites mit nur einem Server nützlich: Zertifikat, Komprimierung und statische Dateien werden von der Anwendung getrennt.
   • Mehrere Anwendungen: Derselbe Reverse Proxy leitet je nach Pfad oder Domain der Anfrage an unterschiedliche Anwendungen weiter. Website, API und Verwaltungsoberfläche laufen als getrennte Prozesse, der Besucher sieht jedoch eine einzige Website.
   • Mehrere Backends: Kopien derselben Anwendung laufen auf mehreren Servern; der Reverse Proxy verteilt die Anfragen auf sie. Wird ein Server gewartet, bleibt die Website erreichbar. Einzelheiten stehen in der Anleitung zur Lastverteilung.

   : Vergrößern

4. 4

   TLS-Terminierung und die echten Besucherdaten

   Sobald ein Reverse Proxy dazwischensteht, sieht das Backend am anderen Ende der Verbindung nicht den Besucher, sondern den Reverse Proxy. Für die Anwendung scheinen zwei Informationen verloren zu sein: die IP-Adresse des Besuchers und die Frage, ob die Verbindung über https läuft. Der Reverse Proxy gibt diese Informationen in Headern weiter, die er der Anfrage hinzufügt:

   • X-Forwarded-For: die IP-Adresse des Besuchers (bei mehreren Proxys dazwischen eine durch Kommas getrennte Liste).
   • X-Forwarded-Proto: das Protokoll, das der Besucher verwendet hat (http oder https).
   • Host: die Domain, die der Besucher angefragt hat.

   Die Anwendung muss so eingerichtet sein, dass sie diese Header auswertet; Einzelheiten stehen weiter unten im Abschnitt „Worauf Sie achten sollten“.

   : Vergrößern

5. 5

   Verhältnis zu CDN und Load Balancer

   Diese drei Begriffe sind keine Konkurrenten, sondern dieselbe Idee in unterschiedlichem Maßstab:

   • Ein Load Balancer ist ein Reverse Proxy, der sich auf die Aufgabe der Verteilung konzentriert. Ein Reverse Proxy wie Nginx kann die Lastverteilung mit übernehmen; in großen Umgebungen wird dafür eine eigene Schicht oder der verwaltete Dienst des Hosting-Anbieters eingesetzt.
   • Ein CDN (Content Delivery Network) besteht aus Reverse Proxys, die an verschiedenen Orten der Welt stehen und vor allem auf Caching ausgelegt sind. Der Besucher verbindet sich mit dem nächstgelegenen Edge-Server; Inhalte, die dieser nicht vorrätig hat, fordert er von Ihrem Server an. Dienste wie Cloudflare sind Beispiele für diese Art.

   Werden sie gemeinsam eingesetzt, wird die Kette länger: Besucher → CDN → Ihr eigener Reverse Proxy → Anwendung. In diesem Fall sieht auch Ihr Reverse Proxy am anderen Ende der Verbindung nicht den Besucher, sondern das CDN; die echte Adresse wird wiederum aus den Headern gelesen. Einzelheiten finden Sie in der Anleitung zum CDN.

   : Vergrößern

Ein kurzes Nginx-Beispiel

Das folgende Beispiel verteilt Anfragen für beispiel.de auf zwei Anwendungsserver im internen Netz und gibt die Besucherdaten in Headern weiter. Der Block upstream definiert die Backend-Server; die Direktive proxy_pass schickt die Anfrage an diese Gruppe.

# Backend-Server (internes Netz)
upstream app_backend {
    server 10.0.0.11:8080;
    server 10.0.0.12:8080;
}

server {
    listen 80;
    server_name beispiel.de www.beispiel.de;

    location / {
        # Anfrage an die Backend-Gruppe weitergeben
        proxy_pass http://app_backend;

        # Angefragte Domain, echte IP-Adresse des Besuchers und Protokoll
        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;
    }
}

Haben Sie nur eine Anwendung, ist kein upstream-Block nötig; es genügt, proxy_pass http://127.0.0.1:3000; zu schreiben. Mehrere Anwendungen nach Pfad und Subdomain zu trennen, sieht so aus:

server {
    listen 80;
    server_name beispiel.de;

    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;

    # Website
    location / {
        proxy_pass http://127.0.0.1:3000;
    }

    # Anfragen, die mit /api/ beginnen, gehen an eine eigene Anwendung
    location /api/ {
        proxy_pass http://127.0.0.1:8080;
    }
}

# Subdomain: Die Verwaltungsoberfläche ist eine eigene Anwendung
server {
    listen 80;
    server_name panel.beispiel.de;

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

Die Beispiele sind bewusst schlicht gehalten, um das Prinzip zu zeigen, und lauschen nur auf Port 80. Eine echte Installation braucht Ergänzungen wie HTTPS, Einstellungen zur Zeitüberschreitung und WebSocket-Unterstützung: Die Schritt-für-Schritt-Beschreibung steht in der Anleitung zur Einrichtung eines Reverse Proxys mit Nginx, die Einrichtung des Zertifikats in der Anleitung zu HTTPS mit Nginx.

Worauf Sie achten sollten

Die echte IP-Adresse des Besuchers

Schaut die Anwendung auf das andere Ende der Verbindung, sieht sie jeden Besucher mit der Adresse des Reverse Proxys: Die Protokolle werden wertlos, und eine IP-basierte Ratenbegrenzung zählt alle als eine Person. Die Lösung besteht darin, den Header X-Forwarded-For zu lesen; allerdings kann jeder diesen Header senden. Kommt die Anfrage direkt aus dem Internet, ist dem Header nicht zu trauen. Die Regel lautet: Berücksichtigen Sie den Header nur dann, wenn die Verbindung von der Adresse Ihres eigenen Reverse Proxys kommt.

<?php
// Dem Header X-Forwarded-For nur vertrauen, wenn die Anfrage vom eigenen Reverse Proxy kommt.
// Für eine Installation mit einem einzigen Reverse Proxy; dieser hängt die gesehene Adresse ans Ende der Liste an.
$guvenilenVekiller = ['10.0.0.5'];

$ip = $_SERVER['REMOTE_ADDR'] ?? '';
if (in_array($ip, $guvenilenVekiller, true) && !empty($_SERVER['HTTP_X_FORWARDED_FOR'])) {
    $adresler = array_map('trim', explode(',', $_SERVER['HTTP_X_FORWARDED_FOR']));
    $aday = end($adresler);
    if (filter_var($aday, FILTER_VALIDATE_IP) !== false) {
        $ip = $aday;
    }
}

// Hat sich der Besucher per https mit der Website verbunden?
$https = in_array($_SERVER['REMOTE_ADDR'] ?? '', $guvenilenVekiller, true)
    && ($_SERVER['HTTP_X_FORWARDED_PROTO'] ?? '') === 'https';

Die meisten Anwendungs-Frameworks bieten dafür eine Einstellung für „vertrauenswürdige Proxys“ (Trusted Proxies); nutzen Sie diese, statt es von Hand zu schreiben. Ebenso wichtig ist, dass die Backend-Server Verbindungen nur vom Reverse Proxy annehmen; andernfalls lässt sich der Reverse Proxy umgehen und ein gefälschter Header senden.

Protokollinformation

Bei TLS-Terminierung ist die Verbindung, die bei der Anwendung ankommt, einfaches HTTP. Beachtet die Anwendung den Header X-Forwarded-Proto nicht, erzeugt sie Links mit http://, sendet „sichere“ Cookies nicht oder leitet die Website immer wieder auf die https-Adresse um und gerät so in eine Endlosschleife.

Der Host-Header

Nginx sendet den Host-Header der Anfrage an das Backend standardmäßig entsprechend der Adresse in proxy_pass. Damit die Anwendung die Domain sieht, die der Besucher eingegeben hat, ist die Zeile proxy_set_header Host $host; aus dem Beispiel nötig.

Single Point of Failure

Da der gesamte Verkehr über den Reverse Proxy läuft, ist die Website nicht erreichbar, sobald er ausfällt, selbst wenn die Server dahinter in Ordnung sind. Bei kleinen Websites ist das ein vertretbares Risiko; wo Ausfälle teuer sind, wird auch der Reverse Proxy redundant aufgebaut (zwei Server mit einer IP-Adresse, die zwischen ihnen wechseln kann, oder der verwaltete Load Balancer des Anbieters). Testen Sie die Konfiguration nach jeder Änderung unbedingt, bevor Sie sie neu laden; eine fehlerhafte Zeile betrifft alle Websites.

Zeitüberschreitung

Der Reverse Proxy wartet nicht unbegrenzt auf die Antwort des Backends. In Nginx beträgt der Standardwert der Direktive proxy_read_timeout 60 Sekunden; sendet das Backend in dieser Zeit keine Antwort, sieht der Besucher den Fehler 504. Ist das Backend gar nicht erreichbar oder kommt eine ungültige Antwort, lautet der Fehler 502. Lösen Sie lang laufende Vorgänge (Berichte, Exporte) möglichst durch Ausführung im Hintergrund und nicht durch eine höhere Zeitüberschreitung (Timeout). Die Fehlercodes werden in der Anleitung zu den Fehlern 502 und 504 ausführlich behandelt.

Upload-Größe

In Nginx ist der Standardwert von client_max_body_size 1m (1 Megabyte). Erlaubt Ihre Anwendung größere Datei-Uploads, müssen Sie diese Grenze auch auf dem Reverse Proxy anheben; sonst wird die Anfrage mit dem Fehler 413 abgewiesen, bevor sie die Anwendung erreicht.

Wann brauchen Sie einen Reverse Proxy?

• Wenn Ihre Anwendung ein Prozess ist, der auf einem eigenen Port läuft (etwa Node.js, Java, Python oder .NET), und Sie sie über 80/443 veröffentlichen möchten.
• Wenn Sie auf demselben Server mehrere Websites oder Anwendungen betreiben.
• Wenn Sie Zertifikate an einer Stelle verwalten möchten.
• Wenn Sie den Verkehr auf mehrere Server verteilen oder ohne Unterbrechung aktualisieren müssen.
• Wenn Sie statische Dateien und Caching von der Anwendung trennen und diese entlasten möchten.

Für eine klassische PHP-Website im Shared Hosting müssen Sie keinen Reverse Proxy selbst einrichten; darum kümmert sich der Hosting-Anbieter. Verwalten Sie Ihren eigenen Server (einen VPS oder einen physischen Server), gehört ein Reverse Proxy ganz selbstverständlich zur Einrichtung.

Checkliste

• Die Backend-Server sind nicht direkt aus dem Internet erreichbar; sie nehmen Verbindungen nur vom Reverse Proxy an.
• Die Header Host, X-Forwarded-For und X-Forwarded-Proto werden weitergegeben.
• Die Anwendung vertraut diesen Headern nur bei Anfragen, die von der Adresse des Reverse Proxys kommen.
• In den Protokollen erscheint die echte IP-Adresse des Besuchers.
• Zeitüberschreitung und Upload-Größe sind auf den Bedarf der Anwendung abgestimmt.
• Änderungen an der Konfiguration werden vor dem Neuladen getestet.
• Es ist bekannt, was beim Ausfall des Reverse Proxys geschieht: Überwachung und, falls nötig, ein Ersatzsystem sind eingerichtet.

Häufige Fragen

Verwandte Anleitungen

• Was ist ein Proxy-Server?Forward Proxy und Reverse Proxy im Vergleich, typische Einsatzgebiete, Abgrenzung zum VPN und Hinweise zur Privatsphäre.
• Nginx als Reverse Proxy einrichtenSchritt für Schritt: server-Block, proxy_pass, weitergereichte Header, WebSocket, Timeouts und echte Client-IP.
• Was ist Lastverteilung (Load Balancing)?Wie Anfragen auf mehrere Server verteilt werden, die upstream-Einstellungen in Nginx, Zustandsprüfung und das Sitzungsproblem.
• Was ist ein CDN (Content Delivery Network)?Was ein CDN ist, wie es in Betrieb geht und worauf bei echter IP, Cache und Sicherheit des Ursprungsservers zu achten ist.