Was ist ein Reverse Proxy? Verständlich erklärt (2026)

Ein Reverse Proxy ist ein Server, der stellvertretend für andere Server antwortet. Clients – Browser, Apps, andere Programme – sprechen nur mit ihm. Er holt die eigentliche Antwort von der Anwendung dahinter und reicht sie zurück. Von außen sieht es aus, als käme alles von einer einzigen Maschine, auch wenn dahinter fünfzig Dienste auf fünfzig Ports laufen.

Das ist die kurze Antwort. Die längere ist interessanter, weil fast jede Erklärung im Netz an derselben Stelle unscharf wird: Sie erklärt, was ein Reverse Proxy tut, aber nicht, wovon er sich unterscheidet – und genau daran scheitert die Auswahl in der Praxis. Load Balancer, API-Gateway, CDN und Reverse Proxy überlappen sich so stark, dass die Frage „welches davon brauche ich?” öfter falsch beantwortet wird als die Frage „wie konfiguriere ich es?”.

Dieser Artikel bleibt deshalb bewusst herstellerneutral. Er erklärt das Konzept, grenzt es gegen die Nachbarbegriffe ab und zeigt, wann du keinen brauchst. Die Zahlen darin stammen nicht aus anderen Blogs, sondern von unseren eigenen Servern – gemessen am 14. September 2026, inklusive der Messfehler, die uns dabei unterlaufen sind.

Was ist ein Reverse Proxy? Die Definition aus dem Standard

Die meisten Erklärungen zitieren sich gegenseitig. Es lohnt sich, einmal in die Primärquelle zu schauen – und dort wird es überraschend: Im HTTP-Standard heißt das Ding gar nicht „Reverse Proxy”.

RFC 9110, der aktuelle HTTP-Semantik-Standard vom Juni 2022, kennt drei Arten von Vermittlern: proxy, gateway und tunnel. Und schreibt:

A “gateway” (a.k.a. “reverse proxy”) is an intermediary that acts as an origin server for the outbound connection but translates received requests and forwards them inbound to another server or servers.

Übersetzt: Ein Gateway ist ein Vermittler, der nach außen so auftritt, als wäre er der Ursprungsserver, die empfangenen Anfragen aber übersetzt und nach innen an einen oder mehrere andere Server weiterreicht. „Reverse Proxy” ist im Standard nur der Klammerzusatz, der geläufige Zweitname.

Dieses Detail ist mehr als Wortklauberei, denn im selben Abschnitt steht der entscheidende Satz:

All HTTP requirements applicable to an origin server also apply to the outbound communication of a gateway.

Alle Anforderungen, die für einen Ursprungsserver gelten, gelten auch für die nach außen gerichtete Kommunikation des Gateways. Der Reverse Proxy ist aus Sicht des Clients nicht „ein Zwischending” – er ist der Server. Er darf sich nicht wie eine Weiterleitung verhalten, sondern muss vollständig für die Anwendung dahinter einstehen. Wer verstanden hat, dass das Ding nach außen die volle Verantwortung eines Servers trägt, versteht auch, warum so viele Probleme (falsche IP-Adressen in Logs, kaputte Redirects, Cookies, die nicht ankommen) nicht Konfigurationsfehler sind, sondern Folgen dieser Rolle.

Und die Definition erklärt eine zweite Sache: Das RFC nennt als Einsatzzwecke ausdrücklich, „legacy or untrusted information services” zu kapseln und „partitioning or load balancing of HTTP services across multiple machines” zu ermöglichen. Verstecken und Verteilen – das sind die beiden Kernaufgaben, alles andere kommt obendrauf.

Forward Proxy vs. Reverse Proxy: derselbe Mechanismus, entgegengesetzte Richtung

Die Begriffe klingen verwandt, und technisch sind sie es auch – beide leiten HTTP weiter. Der Unterschied liegt nicht in der Technik, sondern darin, wer den Vermittler ausgesucht hat.

Auch das steht im RFC überraschend klar. Über den normalen Proxy heißt es:

A “proxy” is a message-forwarding agent that is chosen by the client, usually via local configuration rules […]

Ein Forward Proxy wird vom Client gewählt. Dein Browser, dein Firmennetz, dein VPN-Client entscheidet, dass Anfragen über ihn laufen. Der Zielserver weiß davon oft nichts und sieht nur die IP des Proxys.

Ein Reverse Proxy wird vom Serverbetreiber gewählt. Der Client hat keine Wahl und meistens keine Ahnung, dass da einer steht. Er tippt eine Domain ein, und was antwortet, ist der Reverse Proxy.

Die Faustregel, die in der Praxis trägt: Ein Forward Proxy schützt den Client vor dem Internet. Ein Reverse Proxy schützt das Internet vor deinen Servern – beziehungsweise deine Server vor dem Internet, je nachdem, wen du gerade für gefährdeter hältst.

Ein und dieselbe Software kann beides sein. Nginx, Caddy, HAProxy und Squid lassen sich in beiden Rollen betreiben. Ob etwas ein Forward oder ein Reverse Proxy ist, ist keine Eigenschaft des Programms, sondern seiner Position und Konfiguration.

Wie funktioniert ein Reverse Proxy konkret?

Der Ablauf hat fünf Schritte, und der dritte ist der, an dem die meisten Missverständnisse hängen.

1. Der Client verbindet sich mit dem Proxy. Er löst die Domain auf und landet bei der IP des Reverse Proxys – nicht bei der Anwendung.
2. Der Proxy beendet die TLS-Verbindung. Die Verschlüsselung endet hier. Er entschlüsselt die Anfrage und kann sie lesen.
3. Der Proxy entscheidet anhand der Anfrage, wohin sie geht. Meist anhand des Host-Headers, oft zusätzlich anhand des Pfads. Das ist der eigentliche Trick: Die Entscheidung fällt auf HTTP-Ebene, nicht auf IP-Ebene.
4. Er öffnet eine eigene, neue Verbindung zum Backend und stellt die Anfrage dort selbst.
5. Er nimmt die Antwort entgegen und reicht sie an den Client zurück – gegebenenfalls komprimiert, gecacht oder mit zusätzlichen Headern.

Schritt 3 ist der Grund, warum ein Reverse Proxy überhaupt nützlich ist. Ein Server hat für HTTPS genau einen Port 443. Wollte man zehn Websites ohne Reverse Proxy betreiben, bräuchte man zehn IP-Adressen oder zehn verschiedene Ports – und niemand tippt freiwillig :8443 hinter eine Domain. Der Reverse Proxy liest den Host-Header und weiß dadurch, für welche der zehn Seiten diese Anfrage gedacht war.

Wir haben das auf unserem eigenen Server nachgemessen. Drei völlig verschiedene Anwendungen, drei verschiedene Domains:

$ for h in getmind.io analytics.heynyx.dev compress.heynyx.dev; do
    curl -s -o /dev/null -w "$h -> %{http_code} remote=%{remote_ip}:%{remote_port}\n" "https://$h/"
  done
getmind.io           -> 200 remote=46.225.123.163:443
analytics.heynyx.dev -> 200 remote=46.225.123.163:443
compress.heynyx.dev  -> 200 remote=46.225.123.163:443

Dieselbe IP, derselbe Port, drei verschiedene Anwendungen. Das ist kein Trick, das ist der Normalfall – und ohne Reverse Proxy schlicht nicht möglich.

Was ein Reverse Proxy mit deiner Anfrage macht – gemessen, nicht behauptet

Statt zu beschreiben, was ein Reverse Proxy an einer Anfrage verändert, haben wir einen winzigen Server geschrieben, der einfach ausgibt, was bei ihm ankommt. Einmal direkt aufgerufen, einmal durch einen Reverse Proxy.

const http = require('http');
http.createServer((req, res) => {
  res.setHeader('content-type', 'application/json');
  res.end(JSON.stringify({ remoteAddress: req.socket.remoteAddress, headers: req.headers }, null, 1));
}).listen(3947, '127.0.0.1');

Direkt aufgerufen kommen genau drei Header an:

accept, host, user-agent

Durch einen Reverse Proxy (hier Caddy) kommt das an:

accept: */*
accept-encoding: gzip
host: 127.0.0.1:3948
user-agent: nyx-test
via: 1.1 Caddy
x-forwarded-for: 127.0.0.1
x-forwarded-host: 127.0.0.1:3948
x-forwarded-proto: http

Vier Header sind dazugekommen, und sie sind alle aus demselben Grund da: Der Proxy hat Information vernichtet und liefert sie als Ersatz mit. Das Backend sieht als Absender nur noch den Proxy. Ohne X-Forwarded-For wüsste keine Anwendung mehr, wer sie eigentlich aufgerufen hat – jeder Besucher hieße 127.0.0.1.

Genau dieses Problem beschreibt RFC 7239 in seinem Abstract als Zweck des standardisierten Forwarded-Headers: Er erlaubt Proxy-Komponenten, „information lost in the proxying process” offenzulegen – zum Beispiel die ursprüngliche IP-Adresse. Das RFC hält dabei ausdrücklich fest, dass X-Forwarded-For, X-Forwarded-By und X-Forwarded-Proto nicht standardisierte Felder sind; der offizielle Ersatz heißt Forwarded. In der Praxis ist die nicht standardisierte Variante trotzdem die verbreitete, was man wissen sollte, bevor man sich über eine fehlende Forwarded-Zeile wundert.

Die Falle, die fast jeder einbaut

Wenn die echte Client-IP in einem Header steht – was hindert den Client daran, diesen Header selbst zu setzen? Nichts. Wir haben es ausprobiert:

# Direkt ans Backend, Proxy umgangen:
$ curl -s http://127.0.0.1:3947/ -H "X-Forwarded-For: 1.2.3.4"
  Backend sieht: 1.2.3.4

Das Backend glaubt die Lüge sofort. Wer also seine Anwendung so baut, dass sie X-Forwarded-For vertraut, und das Backend nebenbei direkt erreichbar lässt, hat sich eine Rate-Limit-Umgehung und einen IP-Filter-Bypass in einem gebaut.

Interessanter wird es durch den Proxy – und hier unterscheiden sich die Programme deutlich. Wir haben denselben gefälschten Header durch zwei verschiedene Reverse Proxies geschickt:

# Durch Caddy:
$ curl -s http://127.0.0.1:3948/ -H "X-Forwarded-For: 1.2.3.4"
  Backend sieht: '127.0.0.1'

# Durch nginx mit proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
$ curl -s http://127.0.0.1:3951/ -H "X-Forwarded-For: 1.2.3.4"
  Backend sieht: '1.2.3.4, 127.0.0.1'

Das ist ein wichtiger, selten erwähnter Unterschied. Caddy ersetzt den Wert. Nginx mit der meistkopierten Konfigurationszeile der Welt hängt an. Die Variable $proxy_add_x_forwarded_for tut genau das, was ihr Name sagt: Sie addiert die echte IP an das, was der Client geschickt hat.

Das ist nicht falsch – in einer Kette aus mehreren Proxies ist es sogar richtig, denn so entsteht der vollständige Pfad. Gefährlich wird es durch die Kombination mit einem zweiten verbreiteten Ratschlag: „Nimm den ersten Eintrag aus X-Forwarded-For, das ist der echte Client.” Bei dieser Konfiguration ist der erste Eintrag das, was der Angreifer hineingeschrieben hat. Auf unserem System steht diese Zeile übrigens in /etc/nginx/proxy_params, also in genau der Datei, die man per include einbindet, ohne sie noch einmal zu lesen.

Die Regel daraus: Vertraue nicht dem ersten Eintrag, sondern zähle von rechts so viele Einträge ab, wie du eigene Proxies hast. Alles links davon ist Client-Eingabe und damit unbewiesen.

Reverse Proxy vs. Load Balancer vs. API-Gateway vs. CDN

Hier trennen sich die Begriffe – und hier liegt der eigentliche Nutzen dieses Artikels, weil diese vier ständig verwechselt werden. Die ehrliche Antwort vorweg: Es sind keine vier Produktkategorien, sondern vier Aufgaben, die dieselbe Sorte Software übernehmen kann. Jeder Load Balancer für HTTP ist ein Reverse Proxy. Jedes API-Gateway ist ein Reverse Proxy. Ein CDN enthält einen.

Die Unterscheidung, die wirklich trägt:

• Ein Reverse Proxy fragt: Wohin gehört diese Anfrage? Die Backends sind verschieden.
• Ein Load Balancer fragt: Welcher von diesen gleichen Servern ist gerade am wenigsten beschäftigt? Die Backends sind austauschbar.
• Ein API-Gateway fragt: Darf dieser Aufrufer das, und wie oft? Es interessiert sich für die Fachlichkeit, nicht nur für den Transport.
• Ein CDN fragt: Kann ich das beantworten, ohne überhaupt nach hinten zu gehen? Es ist primär ein verteilter Cache.

Das RFC stützt diese Verwandtschaft übrigens ausdrücklich: Es nennt „partitioning or load balancing of HTTP services across multiple machines” in einem Atemzug als Gateway-Zwecke. Load Balancing ist im Standard kein eigenes Konzept, sondern eine Spielart desselben.

Praktisch heißt das: Wenn dich jemand fragt „Reverse Proxy oder Load Balancer?”, ist die Frage meistens falsch gestellt. Die richtige lautet: „Sind meine Backends verschieden oder austauschbar?” Bei verschieden brauchst du Routing. Bei austauschbar brauchst du Verteilung. Bei beides nimmst du ein Programm, das beides kann – was praktisch alle können.

TLS-Terminierung: wo die Verschlüsselung endet

„TLS-Terminierung” klingt technisch, meint aber etwas sehr Einfaches: Die verschlüsselte Verbindung endet am Reverse Proxy, nicht an deiner Anwendung. Der Proxy entschlüsselt, liest, entscheidet und spricht dahinter oft unverschlüsselt weiter.

Das ist der am häufigsten missverstandene Punkt, weil er zunächst nach einer Sicherheitslücke klingt. Ist es dann nicht unverschlüsselt? Ja – aber auf der Strecke zwischen Proxy und Anwendung, und die liegt in der Regel auf derselben Maschine über das Loopback-Interface. Dieser Verkehr verlässt den Rechner nie.

Der Gewinn ist erheblich: Zertifikate liegen an einer Stelle. Ihre Erneuerung passiert an einer Stelle. Deine Anwendung muss von TLS gar nichts wissen. Auf unserem Server verwaltet Caddy aktuell 940 Zertifikate vollautomatisch:

$ find /var/lib/caddy -path "*certificates*" -name "*.crt" | wc -l
940

Keine einzige der dahinterliegenden Anwendungen enthält eine Zeile TLS-Code. Sie sprechen alle schlichtes HTTP auf 127.0.0.1 – und genau das ist der Punkt.

Wichtig ist dabei die Konsequenz für deine Anwendung: Sie sieht http, obwohl der Nutzer https benutzt hat. Wer Redirects oder absolute URLs selbst baut, erzeugt so Links auf http:// – die klassische Redirect-Schleife nach einer Proxy-Einführung. Dafür ist X-Forwarded-Proto da, und die meisten Frameworks haben einen Schalter namens „trust proxy”, der das berücksichtigt. Er ist fast immer standardmäßig aus, aus gutem Grund: Ohne Proxy davor wäre er eine Sicherheitslücke.

Kostet ein Reverse Proxy Geschwindigkeit? Eine Messung – und ein eigener Messfehler

Die naheliegende Sorge: Eine zusätzliche Station muss doch langsamer sein. Wir wollten das messen, statt es zu schätzen – und sind dabei zuerst in die eigene Falle gelaufen. Das gehört hierher, weil der falsche Wert plausibler aussah als der richtige.

Erster Versuch. Wir riefen die Anwendung über den Proxy mit curl -k auf und setzten den Host per Header:

$ curl -sk -o /dev/null -w "tls=%{time_appconnect} total=%{time_total}\n" \
    https://127.0.0.1/ -H "Host: analytics.heynyx.dev"
tls=0.000000 total=0.004527

3,3 bis 4,5 Millisekunden – eine schöne Zahl. Sie war falsch. Stutzig machte tls=0.000000: Eine HTTPS-Verbindung, die null Zeit für den TLS-Handshake braucht, gibt es nicht. Mit -v kam heraus:

* TLSv1.3 (IN), TLS alert, internal error (592)
* OpenSSL: error:0A000438:SSL routines::tlsv1 alert internal error

Der Host:-Header ändert SNI nicht. curl schickte 127.0.0.1 als Servernamen, Caddy fand dafür kein Zertifikat und brach ab. Die Abfrage lieferte code=000 – gar keine Antwort. Und trotzdem stand da eine Antwortzeit. Eine fehlgeschlagene Verbindung hat eben auch eine Dauer. Hätten wir nur auf time_total geschaut, wäre eine erfundene Zahl in diesen Artikel gewandert.

Die Lehre daraus, die weit über diesen Fall hinausgeht: Eine Zeitmessung ohne Statuscode-Prüfung misst auch Fehlschläge mit. Und ein Fehlschlag ist meistens schneller als ein Erfolg – er macht sich damit in jedem Durchschnitt gut.

Zweiter Versuch, korrekt mit --resolve, Statuscode geprüft, nur 200er gezählt:

# A) Direkt ans Backend, ohne Proxy
n=30 min=0.0010 median=0.0015 p90=0.0018

# B) Durch den Proxy, NEUE TLS-Verbindung für jede Anfrage
n=30 min=0.0206 median=0.0299 p90=0.0377

# C) Durch den Proxy, EINE Verbindung wiederverwendet
n=30 min=0.0011 median=0.0014 p90=0.0017

Diese drei Zeilen sind die eigentliche Antwort auf die Frage nach der Geschwindigkeit.

Variante B sieht katastrophal aus: Faktor 20 langsamer, 30 ms statt 1,5 ms. Variante C ist mit 1,4 ms praktisch nicht unterscheidbar vom direkten Zugriff – der Median liegt sogar minimal darunter, was schlicht Messrauschen ist.

Der Unterschied zwischen B und C ist nicht der Proxy. Es ist der TLS-Handshake. In B baut jede Anfrage eine komplett neue verschlüsselte Verbindung auf; in C laufen alle 30 Anfragen über eine bestehende. Das eigentliche Weiterreichen der Anfrage kostet also im Bereich von Mikrosekunden, während der Verbindungsaufbau rund 28 Millisekunden kostet.

Und weil echte Browser Verbindungen wiederverwenden (bei HTTP/2 sogar aggressiv), ist Variante C der realistische Fall und Variante B der Ausnahmefall beim allerersten Kontakt. Die ehrliche Antwort auf „kostet ein Reverse Proxy Geschwindigkeit?” lautet deshalb: Das Proxying selbst praktisch nicht. Das TLS, das er dir abnimmt, schon – aber das hättest du sonst auch bezahlt, nur woanders.

Wann du einen Reverse Proxy brauchst – und wann nicht

Die ehrliche Liste, in beide Richtungen.

Du brauchst einen, wenn:

• Du mehr als eine Anwendung auf einer Maschine betreibst. Ab der zweiten Domain ist die Frage entschieden.
• Du HTTPS willst, ohne es in jeder Anwendung einzeln zu implementieren und zu erneuern.
• Deine Anwendung auf einem anderen Port als 80/443 lauscht – also bei praktisch jeder Node-, Python- oder Go-Anwendung.
• Du mehrere Instanzen derselben Anwendung betreibst und die Last verteilen willst.
• Du ohne Ausfall deployen willst: Der Proxy schwenkt auf die neue Instanz, sobald deren Health-Check grün ist.
• Du zentral Sicherheits-Header, Rate Limits oder Zugriffsschutz durchsetzen willst, ohne sie in jeder Anwendung zu pflegen.

Du brauchst keinen, wenn:

• Du eine statische Website hast und ein Webserver sie direkt ausliefert. Ein Proxy davor ist dann eine Station ohne Aufgabe.
• Du eine Plattform nutzt (Vercel, Netlify, Cloud Run, App-Hosting) – dort läuft bereits einer, du siehst ihn nur nicht. Einen eigenen davorzusetzen verdoppelt die Fehlerquellen.
• Du lokal entwickelst. In der Entwicklung ist die zusätzliche Schicht meist nur eine zusätzliche Stelle, an der etwas falsch konfiguriert sein kann.
• Deine Anwendung sowieso schon hinter einem CDN hängt, das Routing und TLS übernimmt.

Der häufigste Fehler ist nicht, keinen einzusetzen, sondern zwei übereinander – CDN plus eigener Proxy plus Plattform-Proxy – und sich dann zu wundern, warum X-Forwarded-For drei Einträge hat und das Rate Limit nicht greift.

Ein Reverse Proxy ist kein Firewall-Ersatz

Das ist der Punkt, an dem sich unsere eigene Praxis am deutlichsten von der Theorie unterscheidet – und wir müssen ihn gegen uns selbst formulieren.

Der übliche Satz lautet: „Der Reverse Proxy versteckt deine Backends, damit sind sie nicht mehr erreichbar.” Das stimmt nur, wenn die Backends tatsächlich nicht anders erreichbar sind. Wir haben auf unserem Server nachgesehen:

# Dienste, die nur auf 127.0.0.1 lauschen:   42
# Dienste, die auf 0.0.0.0 lauschen:         22

22 Dienste lauschen auf allen Interfaces. Der Reverse Proxy hilft dagegen kein Stück – wer den Port kennt, kann ihn direkt ansprechen und den Proxy samt aller Regeln umgehen. Was uns rettet, ist eine zweite, unabhängige Schicht:

$ ufw status | head
Status: active
22/tcp   ALLOW  Anywhere   # SSH
80/tcp   ALLOW  Anywhere   # HTTP
443/tcp  ALLOW  Anywhere   # HTTPS

Für die Anwendungs-Ports existiert keine ALLOW-Regel, die Standardrichtlinie verwirft sie. Gemessen statt vermutet: Von den Ports 3850, 5050, 3875 und 3896 ist keiner in der Firewall freigegeben – obwohl alle vier auf 0.0.0.0 lauschen.

Daraus folgt die Regel, die in unserem eigenen Betriebshandbuch steht: Dienste an 127.0.0.1 binden, nicht an 0.0.0.0. Bei Docker heißt das '127.0.0.1:5432:5432' statt '5432:5432' – die Standardschreibweise veröffentlicht den Port für die ganze Welt. Wir wissen das nicht aus der Dokumentation, sondern weil uns das BSI wegen einer offen erreichbaren PostgreSQL-Instanz angeschrieben hat.

Und dazu passt eine zweite Erfahrung aus der Prüfung selbst: Ein curl auf die eigene öffentliche IP beweist gar nichts. Der Kernel leitet solche Anfragen über lo, und die Firewall-Kette wird nie durchlaufen – der Test meldet „erreichbar”, obwohl der Port von außen dicht ist. Ein Erreichbarkeitstest ist nur dann einer, wenn er von einer anderen Maschine kommt.

Der Reverse Proxy ist also ein Routing- und Sichtbarkeitswerkzeug, kein Zugangsschutz. Er reduziert die Angriffsfläche, indem er die Anzahl der Türen verringert, auf die jemand überhaupt zielen sollte. Er verriegelt die anderen Türen nicht. Das macht die Firewall.

Die üblichen Kandidaten – eine Landkarte, keine Empfehlung

Vier Programme decken fast alles ab. Welches passt, hängt weniger von Leistungsdaten ab als davon, wie du arbeitest.

Nginx ist der Standard. Am weitesten verbreitet, jede Fehlermeldung ist schon einmal jemandem passiert, für jedes Problem gibt es eine Antwort. Preis: eigene Konfigurationssprache mit einigen scharfen Kanten – die X-Forwarded-For-Sache oben ist ein gutes Beispiel. Wenn du ohnehin schon Nginx-Konfigurationen liest, bleib dabei; unser kompletter Nginx-Reverse-Proxy-Guide geht genau darauf ein. Und falls du noch davor stehst, welcher Webserver es überhaupt sein soll: Apache vs. Nginx beantwortet die Frage.

Caddy holt Zertifikate automatisch, ohne Zusatzwerkzeug. Genau das machen die 940 Zertifikate oben – dafür mussten wir nichts einrichten. Die Konfiguration ist deutlich kürzer; ein funktionierender Reverse Proxy mit HTTPS sind zwei Zeilen. Preis: kleinere Community, für sehr exotische Fälle findet man weniger.

Traefik entdeckt Dienste selbst. In Docker- oder Kubernetes-Umgebungen liest es Labels und konfiguriert sich daraus. Wenn Container ständig kommen und gehen, ist das der richtige Ansatz. Auf einem klassischen Server ist es Aufwand ohne Gegenwert.

HAProxy ist der Spezialist fürs Verteilen. Wenn Load Balancing die Hauptaufgabe ist und nicht ein Nebenprodukt, ist es die genaueste Wahl – mit den besten Werkzeugen für Health-Checks und Lastverteilung.

Dazu kommen die Gehosteten: Cloudflare, Fastly und andere sind Reverse Proxies, die jemand anders betreibt. Sie nehmen dir die Arbeit ab und die Kontrolle gleich mit. Für viele Fälle ein guter Tausch – nur sollte man wissen, dass man ihn macht. Wenn du generell über Alternativen zu gehosteten Plattformen nachdenkst, ist unser Vergleich der Vercel-Alternativen der passende Einstieg.

Unser eigenes Setup nutzt Caddy, aber das ist eine Vorliebe, keine Empfehlung: Wir betreiben viele kleine Dienste unter vielen Domains, und die automatische Zertifikatsverwaltung nimmt uns genau den Teil ab, der sonst Arbeit macht. Bei einer einzelnen großen Anwendung wäre der Vorteil klein.

Typische Fehler beim ersten Reverse Proxy

Die Probleme, die praktisch jeder einmal hat – und woran man sie erkennt.

502 Bad Gateway. Der Proxy erreicht das Backend nicht. Fast immer: Die Anwendung läuft nicht, lauscht auf einem anderen Port, oder sie lauscht auf 127.0.0.1, während der Proxy in einem Container sitzt und deshalb von außen kommt. Erster Test ist immer, das Backend direkt anzusprechen – antwortet es dort, liegt es am Proxy; antwortet es nicht, liegt es an der Anwendung.

504 Gateway Timeout. Das Backend antwortet, aber zu langsam. Ein Standard-Timeout von 60 Sekunden ist für einen Datei-Upload oder einen langen Report schnell erreicht. Wichtig: Das Timeout hochsetzen ist selten die richtige Lösung, es verschiebt nur die Grenze.

Endlose Redirect-Schleife. Die Anwendung sieht http, leitet auf https um, der Proxy schickt die Anfrage wieder als http weiter. Das ist der X-Forwarded-Proto-Fall von oben – „trust proxy” einschalten.

Alle Besucher haben dieselbe IP. Die Anwendung liest die Socket-Adresse statt X-Forwarded-For. Fällt oft erst auf, wenn ein Rate Limit plötzlich alle gemeinsam trifft.

WebSockets brechen ab. WebSocket-Verbindungen brauchen einen Protokoll-Upgrade, den nicht jeder Proxy von allein durchreicht. Bei Nginx sind dafür die Upgrade- und Connection-Header nötig; Caddy und Traefik machen es von selbst.

Uploads scheitern bei größeren Dateien. Der Proxy hat ein eigenes Limit für die Größe des Anfragekörpers, oft 1 MB. Die Anwendung sieht die Anfrage nie und kann deshalb auch keine sinnvolle Fehlermeldung liefern.

Was allen sechs gemeinsam ist: Die Anwendung ist in Ordnung, und die Fehlermeldung entsteht an einer Stelle, an der man nicht sucht. Deshalb lohnt es sich, bei jedem Proxy-Problem zuerst den direkten Zugriff aufs Backend zu testen. Diese eine Frage – „geht es ohne Proxy?” – halbiert die Suchzeit.

Häufig gestellte Fragen

Was ist ein Reverse Proxy einfach erklärt?

Ein Server, der stellvertretend für andere Server antwortet. Clients sprechen nur mit ihm, er holt die Antwort von der eigentlichen Anwendung dahinter und reicht sie zurück. Von außen wirkt es wie eine einzige Maschine, auch wenn dahinter viele Dienste laufen. Im HTTP-Standard RFC 9110 heißt dieses Bauteil eigentlich „Gateway”; „Reverse Proxy” ist dort nur der geläufige Zweitname.

Was ist der Unterschied zwischen Proxy und Reverse Proxy?

Wer ihn ausgesucht hat. Einen Forward Proxy wählt der Client – laut RFC 9110 ist er ein Vermittler, der „chosen by the client” wird, etwa über Browser- oder Netzwerkeinstellungen. Einen Reverse Proxy wählt der Serverbetreiber, und der Client merkt in der Regel nichts davon. Der Forward Proxy verbirgt den Client vor dem Server, der Reverse Proxy verbirgt die Server vor dem Client. Technisch ist es dieselbe Sorte Software in entgegengesetzter Richtung.

Ist ein Reverse Proxy dasselbe wie ein Load Balancer?

Nicht ganz, aber sie überlappen stark. Jeder HTTP-Load-Balancer ist ein Reverse Proxy, nicht jeder Reverse Proxy ist ein Load Balancer. Der Unterschied liegt in den Backends: Ein Reverse Proxy leitet an verschiedene Anwendungen weiter und entscheidet anhand von Host und Pfad. Ein Load Balancer verteilt auf austauschbare Instanzen derselben Anwendung und entscheidet anhand von Auslastung und Verfügbarkeit.

Macht ein Reverse Proxy meine Website langsamer?

Das Weiterreichen selbst kostet fast nichts. In unserer Messung lag der direkte Zugriff bei einem Median von 1,5 ms und der Zugriff über den Proxy bei wiederverwendeter Verbindung bei 1,4 ms – nicht unterscheidbar. Deutlich teurer war nur der Fall, in dem für jede einzelne Anfrage eine neue TLS-Verbindung aufgebaut wurde: 29,9 ms. Diese Kosten verursacht aber der TLS-Handshake, nicht das Proxying, und echte Browser vermeiden ihn durch Wiederverwendung der Verbindung.

Brauche ich einen Reverse Proxy für eine einzelne Website?

Meistens nicht, wenn es eine statische Seite ist, die ein Webserver direkt ausliefert. Sobald die Seite aber von einer eigenen Anwendung auf einem eigenen Port kommt – Node, Python, Go – brauchst du etwas, das Port 443 belegt und HTTPS übernimmt. Spätestens ab der zweiten Domain auf derselben Maschine ist die Frage entschieden, weil es nur einen Port 443 gibt.

Ersetzt ein Reverse Proxy eine Firewall?

Nein. Er verringert die Zahl der Türen, auf die jemand zielen sollte, aber er verriegelt die übrigen nicht. Auf unserem eigenen Server lauschen 22 Dienste auf allen Interfaces; würde die Firewall diese Ports nicht verwerfen, wären sie trotz Reverse Proxy direkt erreichbar. Dienste gehören an 127.0.0.1 gebunden, und die Firewall bleibt eine eigene, unabhängige Schicht.

Was ist TLS-Terminierung?

Die verschlüsselte Verbindung endet am Reverse Proxy statt an der Anwendung. Der Proxy entschlüsselt die Anfrage, entscheidet über das Ziel und spricht dahinter meist unverschlüsselt weiter – in der Regel über das Loopback-Interface derselben Maschine, sodass dieser Verkehr den Rechner nie verlässt. Der Vorteil ist, dass Zertifikate nur an einer Stelle liegen und erneuert werden müssen.

Warum sieht meine Anwendung hinter dem Proxy nur eine IP-Adresse?

Weil der Proxy eine eigene, neue Verbindung zum Backend aufbaut. Aus Sicht der Anwendung ist der Proxy der Absender. Die echte Adresse reicht er in X-Forwarded-For nach – RFC 7239 beschreibt genau das als Zweck: Information offenzulegen, die beim Proxying verloren geht. Wichtig ist, diesem Header nur so weit zu trauen, wie eigene Proxies in der Kette stehen, denn Clients können ihn selbst setzen.

Fazit: ein Bauteil, das man erst vermisst, wenn es fehlt

Ein Reverse Proxy ist kein Optimierungswerkzeug, sondern ein Strukturwerkzeug. Er löst ein Problem, das aus einer schlichten Tatsache folgt: Es gibt nur einen Port 443, aber meistens mehr als eine Anwendung. Alles andere – TLS an einer Stelle, Lastverteilung, zentrale Header, Deployments ohne Ausfall – kommt obendrauf, weil an dieser Stelle ohnehin schon jemand steht, der jede Anfrage sieht.

Was wir beim Schreiben dieses Artikels selbst gelernt haben, steht in den Messungen und nicht in den Definitionen. Dass der Aufpreis beim Proxying im Mikrosekundenbereich liegt und der scheinbare Faktor 20 in Wahrheit der TLS-Handshake ist. Dass zwei verbreitete Reverse Proxies bei einem gefälschten X-Forwarded-For unterschiedlich reagieren und die meistkopierte Nginx-Zeile die Client-Eingabe stehen lässt. Und dass unser eigener Server 22 Dienste auf allen Interfaces betreibt, die der Reverse Proxy kein Stück schützt – das tut die Firewall.

Der ehrlichste Moment war der erste Messversuch, der eine saubere Zahl lieferte, obwohl gar keine Verbindung zustande kam. Eine Zeitmessung ohne Statuscode-Prüfung misst auch Fehlschläge – und Fehlschläge sind schnell. Hätten wir nicht hingesehen, stünde hier eine erfundene Zahl, die vollkommen plausibel aussieht.

Wenn du jetzt konkret werden willst: Der nächste Schritt ist die Konfiguration, und dafür gibt es unseren ausführlichen Nginx-Reverse-Proxy-Guide mit Schritt-für-Schritt-Einrichtung, SSL, Caching und Hardening. Wenn der Server noch gar nicht steht, fang bei Linux-Server einrichten an – dort geht es auch um die Firewall-Regeln, die neben dem Proxy stehen müssen. Und wenn dich interessiert, was passiert, wenn diese Schichten fehlen: Wir haben einmal fünf Tage lang nicht gemerkt, dass unser Server gekapert war.