Funk­ti­ons­wei­se, Ein­satz­ge­bie­te und Un­ter­schie­de zum Forward-Proxy

Ein Reverse-Proxy ist ein Server, der Anfragen von Clients stell­ver­tre­tend für einen oder mehrere Backend-Server ent­ge­gen­nimmt, an den passenden Server wei­ter­lei­tet und dessen Antwort an den Client zu­rück­gibt. Für Nut­ze­rin­nen und Nutzer wirkt der Reverse-Proxy wie der ei­gent­li­che Webserver. Ein­ge­setzt wird er vor allem, um Server ab­zu­si­chern, Last zu verteilen und Websites durch Caching, Kom­pres­si­on und TLS-Ter­mi­nie­rung schneller und ef­fi­zi­en­ter aus­zu­lie­fern.

Wie funk­tio­niert ein Reverse-Proxy?

Grund­sätz­lich fungiert ein Proxy-Server als Ver­mitt­ler im Netzwerk: Er nimmt Anfragen entgegen und leitet sie stell­ver­tre­tend an ein Ziel weiter. Ein Reverse-Proxy steht dabei zwischen den Clients (z. B. Web­brow­sern oder Apps) und den Backend-Servern (z. B. Web­ser­vern oder An­wen­dungs­ser­vern). Clients kom­mu­ni­zie­ren aus­schließ­lich mit dem Reverse-Proxy; welche internen Server die Anfrage tat­säch­lich be­ar­bei­ten, bleibt für sie un­sicht­bar. Der Ablauf umfasst vier grund­le­gen­de Schritte:

1. Empfang der Client-Anfrage: Der Reverse-Proxy nimmt Anfragen über HTTP bzw. HTTPS entgegen, heute meist in den Pro­to­koll­ver­sio­nen HTTP/1.1, HTTP/2 oder HTTP/3, sowie lang­le­bi­ge Ver­bin­dun­gen wie WebSocket. Je nach Software lassen sich auch andere Dienste auf TCP- oder UDP-Ebene wei­ter­lei­ten, etwa FTP.
2. Analyse der Anfrage: Der Proxy prüft, ob die Anfrage gültig und zulässig ist, ob sie Si­cher­heits­re­geln verletzt und ob eine zwi­schen­ge­spei­cher­te Antwort vorliegt. Anhand von Hostname, Pfad oder Headern ent­schei­det er, welches Backend zuständig ist.
3. Wei­ter­lei­tung an den passenden Server: Kann die Anfrage nicht aus dem Cache be­ant­wor­tet werden, sendet der Reverse-Proxy sie an einen der internen Server. Dabei ergänzt er in der Regel Header mit In­for­ma­tio­nen über den ur­sprüng­li­chen Client (mehr dazu im Abschnitt „Wei­ter­ga­be der Client-In­for­ma­tio­nen“).
4. Antwort an den Client: Der Reverse-Proxy empfängt die Antwort des Backend-Servers, ver­ar­bei­tet sie bei Bedarf weiter (z. B. Kom­pres­si­on, Ver­schlüs­se­lung, Zwi­schen­spei­che­rung) und sendet sie an den an­fra­gen­den Client zurück.

Was ist der Un­ter­schied zwischen Forward-Proxy und Reverse-Proxy?

Beide Proxy-Arten ver­mit­teln zwischen Clients und Servern, sie handeln aber im Auftrag un­ter­schied­li­cher Seiten:

• Ein Forward-Proxy handelt im Auftrag der Clients. Er sitzt zwischen den Geräten in einem internen Netzwerk und dem Internet, bündelt deren aus­ge­hen­de Anfragen und leitet sie mit der eigenen Ab­sen­der­adres­se an die Ziel­ser­ver weiter. Die Ziel­ser­ver sehen daher nur die Adresse des Proxys, nicht die der einzelnen Clients – es sei denn, es handelt sich um einen trans­pa­ren­ten Proxy, der die Client-Adresse nicht verbirgt.
• Ein Reverse-Proxy handelt im Auftrag der Server. Er nimmt ein­ge­hen­de Anfragen aus dem Internet entgegen und verteilt sie an Server, die meist in einem privaten Netzwerk stehen. Er macht diese Server kon­trol­liert öf­fent­lich er­reich­bar, schützt sie und optimiert ihre Aus­lie­fe­rung.

Ver­ein­facht gesagt: Der Forward-Proxy schützt und steuert Clients, der Reverse-Proxy schützt und entlastet Server.

Reverse-Proxy: An­wen­dungs­ge­bie­te

Weil alle Anfragen über den Reverse-Proxy laufen, lässt sich der ein­ge­hen­de Da­ten­ver­kehr an einer zentralen Stelle steuern. So lassen sich mehrere Server oder An­wen­dun­gen unter derselben Domain be­reit­stel­len, Anfragen auf ver­schie­de­ne Server verteilen, Inhalte zwi­schen­spei­chern und Si­cher­heits­re­geln ein­heit­lich durch­set­zen. Die folgenden Ein­satz­fel­der sind die wich­tigs­ten.

Load Balancing

Über einen vor­ge­schal­te­ten Reverse-Proxy lässt sich eine Domain mit mehreren Servern im privaten Netzwerk ver­knüp­fen. Ein­ge­hen­de Anfragen werden dann nach einem fest­ge­leg­ten Verfahren verteilt, etwa reihum (Round Robin), an den Server mit den wenigsten aktiven Ver­bin­dun­gen (Least Con­nec­tions) oder anhand der Client-IP (IP-Hash), damit ein Client immer beim selben Server landet. Ein solches Load Balancing beugt der Über­las­tung einzelner Systeme vor. Über re­gel­mä­ßi­ge Health Checks erkennt der Proxy, wenn ein Server aufgrund von Hardware- oder Soft­ware­feh­lern nicht antwortet, und verteilt die Anfragen auf die ver­blei­ben­den Server. So bleibt der Dienst auch bei Ausfällen verfügbar, und einzelne Server lassen sich für War­tungs­ar­bei­ten aus dem Betrieb nehmen, ohne dass Nut­ze­rin­nen und Nutzer etwas davon bemerken.

Caching

Viele Reverse-Proxys können häufig ab­ge­ru­fe­ne Inhalte zwi­schen­spei­chern und wie­der­keh­ren­de Anfragen ganz oder teilweise selbst be­ant­wor­ten. Das betrifft vor allem statische Inhalte wie Bilder, Ja­va­Script-Dateien oder CSS-Style­sheets. Da weniger Anfragen beim Backend-Server ankommen, sinken Ant­wort­zei­ten und Ser­ver­last spürbar.

Wie lange eine Antwort im Cache bleiben darf, steuern Betreiber über HTTP-Header wie Cache-Control oder über eigene Regeln im Proxy. Bei Inhalten, die sich häufig ändern, besteht das Risiko, dass Clients veraltete Versionen erhalten. Viele Lösungen erlauben es daher, einzelne Einträge oder den gesamten Cache gezielt zu leeren, etwa nach einem Update der Website. Besondere Vorsicht ist bei per­so­na­li­sier­ten Inhalten geboten: Werden Seiten mit Nut­zer­da­ten ver­se­hent­lich zwi­schen­ge­spei­chert, können sie anderen Be­su­che­rin­nen und Besuchern angezeigt werden.

Schutz- und Si­cher­heits­maß­nah­men

Ein Reverse-Proxy fungiert als Schutz­schild für die Backend-Server und kann in dieser Rolle ver­schie­de­ne Si­cher­heits­funk­tio­nen über­neh­men:

• DDoS-Abwehr und Rate Limiting: Reverse-Proxys können auf­fäl­li­ge oder un­ge­wöhn­lich hohe An­fra­ge­men­gen, wie sie bei DDoS-Angriffen auftreten, erkennen, die Zahl der Anfragen pro Client begrenzen und solchen Traffic blo­ckie­ren, bevor er die Backend-Server erreicht. Gegen große vo­lu­me­tri­sche Angriffe, die bereits die Netz­an­bin­dung über­las­ten, reicht ein einzelner Proxy al­ler­dings nicht aus; dafür sind verteilte Schutz­diens­te des Hosting- oder CDN-Anbieters nötig.
• Web Ap­pli­ca­ti­on Firewall (WAF): Viele Reverse-Proxys lassen sich um eine WAF ergänzen oder bringen eine mit. Sie filtert schäd­li­che Anfragen wie SQL-In­jec­tions oder Cross-Site-Scripting (XSS). Bei NGINX und Apache geschieht das meist über Zu­satz­mo­du­le wie Mod­Se­cu­ri­ty.
• Al­low­lists und Block­lists: Der Proxy kann bestimmte IP-Adressen oder Netz­be­rei­che sperren oder Ver­bin­dun­gen nur aus fest­ge­leg­ten Netz­wer­ken zulassen, etwa für Ad­mi­nis­tra­ti­ons­be­rei­che.
• Zentrale Au­then­ti­fi­zie­rung: An­mel­dun­gen, etwa per Single Sign-on, lassen sich am Proxy bündeln, statt sie in jeder Anwendung einzeln um­zu­set­zen.
• Ver­schleie­rung der Backend-Server: Da Clients nur mit dem Proxy kom­mu­ni­zie­ren, bleiben die internen IP-Adressen und die Struktur der Backend-Server verborgen. Das erschwert gezielte Angriffe auf einzelne Systeme.

Ver­schlüs­se­lung und TLS-Ter­mi­nie­rung

Reverse-Proxys über­neh­men häufig die Ver­schlüs­se­lung für alle da­hin­ter­lie­gen­den Dienste. Bei der so­ge­nann­ten TLS-Ter­mi­nie­rung baut der Proxy die ver­schlüs­sel­te SSL/TLS-Ver­bin­dung zum Client auf, ent­schlüs­selt die Anfrage, leitet sie an den Backend-Server weiter und sendet die Antwort wieder ver­schlüs­selt an den Client zurück. Zer­ti­fi­ka­te müssen so nur an einer Stelle verwaltet werden, und die Backend-Server werden von der re­chen­in­ten­si­ven Ver­schlüs­se­lung entlastet. Aktuelle Standards wie TLS 1.3 oder HTTP/3, das auf dem Trans­port­pro­to­koll QUIC basiert, lassen sich auf diese Weise zentral für alle Dienste ak­ti­vie­ren, auch wenn die An­wen­dun­gen dahinter sie selbst nicht un­ter­stüt­zen.

Die interne Ver­bin­dung zwischen Proxy und Backend kann un­ver­schlüs­selt erfolgen, wenn das interne Netz ver­trau­ens­wür­dig ist. In sensiblen Um­ge­bun­gen oder bei geteilter In­fra­struk­tur ver­schlüs­selt der Proxy auch diese Strecke erneut (Re-En­cryp­ti­on) oder reicht die ver­schlüs­sel­te Ver­bin­dung un­ver­än­dert durch (TLS-Pass­th­rough).

Viele Reverse-Proxys können TLS-Zer­ti­fi­ka­te zudem au­to­ma­tisch über das ACME-Protokoll beziehen und erneuern, etwa bei der kos­ten­lo­sen Zer­ti­fi­zie­rungs­stel­le Let’s Encrypt. Caddy erledigt das stan­dard­mä­ßig, Traefik bringt die Funktion mit und benötigt nur wenige Ein­stel­lun­gen. Apache bietet dafür das mit­ge­lie­fer­te Modul mod_md (seit Version 2.4.30, noch als ex­pe­ri­men­tell ge­kenn­zeich­net), für NGINX gibt es seit 2025 ein natives ACME-Modul, das zunächst als Preview ver­öf­fent­licht wurde. Al­ter­na­tiv über­neh­men externe Werkzeuge wie Certbot den Zer­ti­fi­kats­a­bruf.

Wei­ter­ga­be der Client-In­for­ma­tio­nen

Da die Ver­bin­dung zum Backend vom Reverse-Proxy ausgeht, sieht der Backend-Server zunächst nur dessen IP-Adresse. Damit An­wen­dun­gen dennoch wissen, wer anfragt – etwa für Logs, Sta­tis­ti­ken, Si­cher­heits­re­geln oder stand­ort­be­zo­ge­ne Inhalte –, reicht der Proxy die ur­sprüng­li­che Client-IP, das ver­wen­de­te Protokoll und den an­ge­frag­ten Host in HTTP-Headern weiter. Ver­brei­tet ist der De-facto-Standard X-Forwarded-For (ergänzt um X-Forwarded-Proto und X-Forwarded-Host); stan­dar­di­siert ist seit 2014 der Header Forwarded (RFC 7239). Aus Da­ten­schutz­grün­den können Betreiber IP-Adressen auch gekürzt wei­ter­ge­ben oder pro­to­kol­lie­ren.

Kom­pres­si­on

Ein Reverse-Proxy kann Antworten der Backend-Server kom­pri­mie­ren, bevor er sie an den Client sendet. Das ver­rin­gert die über­tra­ge­ne Da­ten­men­ge und be­schleu­nigt den Sei­ten­auf­bau, vor allem bei text­ba­sier­ten Inhalten wie HTML, CSS, Ja­va­Script oder JSON. Bereits kom­pri­mier­te Formate wie JPEG oder MP4 pro­fi­tie­ren dagegen kaum. Welches Verfahren zum Einsatz kommt, handeln Browser und Server über den Header Accept-Encoding aus. Am weitesten ver­brei­tet ist gzip, das in Web­ser­vern wie Apache oder NGINX über Module be­reit­steht. Ef­fi­zi­en­ter sind die neueren Verfahren Brotli und Zstandard (zstd), die aktuelle Browser wie Chrome, Edge und Firefox ebenfalls un­ter­stüt­zen. Je nach Software sind sie in­te­griert oder per Zu­satz­mo­dul nach­rüst­bar.

Reverse-Proxy, Load Balancer und API-Gateway: Wo liegt der Un­ter­schied?

Die Begriffe über­schnei­den sich, da dieselbe Software oft mehrere Rollen übernimmt:

• Reverse-Proxy ist der Ober­be­griff für eine Kom­po­nen­te, die Anfragen stell­ver­tre­tend für Server ent­ge­gen­nimmt und wei­ter­lei­tet – un­ab­hän­gig davon, ob es dahinter einen oder viele Server gibt.
• Ein Load Balancer ist auf die Ver­tei­lung von Anfragen auf mehrere Server spe­zia­li­siert. Arbeitet er auf der Trans­port­ebe­ne (Layer 4), verteilt er TCP- oder UDP-Ver­bin­dun­gen, ohne deren Inhalt aus­zu­wer­ten. Ein Layer-7-Load-Balancer wertet dagegen HTTP-Inhalte wie Hostname, Pfad oder Cookies aus und ist damit zugleich ein Reverse-Proxy.
• Ein API-Gateway ist ein spe­zia­li­sier­ter Reverse-Proxy für Pro­gram­mier­schnitt­stel­len. Zu­sätz­lich zur Wei­ter­lei­tung übernimmt er Aufgaben wie Au­then­ti­fi­zie­rung per API-Schlüssel oder Token, Ra­ten­be­gren­zung pro Kunde, Ver­sio­nie­rung und Aus­wer­tung der API-Nutzung.

In Ku­ber­netes-Clustern über­neh­men Ingress-Con­trol­ler die Rolle des Reverse-Proxys für die Dienste im Cluster. Für neue In­stal­la­tio­nen empfiehlt das Ku­ber­netes-Projekt in­zwi­schen die Gateway API anstelle der Ingress-API. Die Ingress-API ist ein­ge­fro­ren: Sie wird nicht mehr wei­ter­ent­wi­ckelt, bleibt aber als stabile Schnitt­stel­le erhalten und soll nicht entfernt werden. Der ver­brei­te­te Con­trol­ler Ingress NGINX wurde im November 2025 ab­ge­kün­digt; seit März 2026 erhält er keine Updates und Si­cher­heits­kor­rek­tu­ren mehr. Er ist nicht zu ver­wech­seln mit dem separat wei­ter­ent­wi­ckel­ten NGINX Ingress Con­trol­ler von F5/NGINX.

Ver­brei­te­te Reverse-Proxy-Software

Für den Betrieb eines Reverse-Proxys stehen zahl­rei­che, über­wie­gend quell­of­fe­ne Lösungen zur Verfügung:

• NGINX: Weit ver­brei­te­ter Webserver und Reverse-Proxy mit Load Balancing, Caching und TLS-Ter­mi­nie­rung. HTTP/3 un­ter­stützt NGINX seit Version 1.25.0 über ein ex­pe­ri­men­tel­les, op­tio­na­les Modul.
• Apache HTTP Server: Mit den Modulen mod_proxy und mod_proxy_balancer lässt sich der klas­si­sche Webserver als Reverse-Proxy und Load Balancer einsetzen.
• HAProxy: Auf Load Balancing und hohe Ver­füg­bar­keit spe­zia­li­sier­ter Proxy für Layer 4 und Layer 7, der für hohe Last und Sta­bi­li­tät bekannt ist.
• Traefik: Für Container-Um­ge­bun­gen wie Docker und Ku­ber­netes ent­wi­ckel­ter Reverse-Proxy, der neue Dienste au­to­ma­tisch erkennt und Zer­ti­fi­ka­te per ACME bezieht.
• Caddy: Webserver und Reverse-Proxy mit besonders einfacher Kon­fi­gu­ra­ti­on und stan­dard­mä­ßig ak­ti­vier­tem au­to­ma­ti­schem HTTPS.
• Envoy: Leis­tungs­fä­hi­ger Proxy für Cloud-native Ar­chi­tek­tu­ren, der häufig als Grundlage für Service Meshes und API-Gateways dient.

Reverse-Proxy in der Cloud betreiben

Wer Web­an­wen­dun­gen auf eigenen vir­tu­el­len Servern betreibt, kann den Reverse-Proxy als eigene Instanz vor die An­wen­dungs­ser­ver setzen. In einer Cloud-In­fra­struk­tur wie der IONOS Compute Engine sieht ein typischer Aufbau so aus: Ein Server mit öf­fent­li­cher IP-Adresse betreibt die Proxy-Software, etwa NGINX oder HAProxy, und ist als einziges System aus dem Internet er­reich­bar. Die An­wen­dungs- und Da­ten­bank­ser­ver hängen nur in einem privaten Netzwerk und sind aus dem Internet nicht direkt er­reich­bar. Steigt die Last, lassen sich zu­sätz­li­che An­wen­dungs­ser­ver hinter dem Proxy ergänzen, ohne dass sich an der öf­fent­li­chen Adresse etwas ändert. Um den Proxy selbst nicht zum einzigen Aus­fall­punkt zu machen, sollten Sie bei ge­schäfts­kri­ti­schen Diensten min­des­tens zwei Proxy-Instanzen einplanen oder einen ver­wal­te­ten Load-Balancer-Dienst des Cloud-Anbieters vor­schal­ten.

Welche Nachteile und Risiken hat ein Reverse-Proxy?

So nützlich ein Reverse-Proxy ist, er bringt auch zu­sätz­li­che Kom­ple­xi­tät mit sich:

• Single Point of Failure: Fällt ein einzelner Reverse-Proxy aus, sind alle Dienste dahinter nicht mehr er­reich­bar. Für hohe Ver­füg­bar­keit sind daher red­un­dan­te Proxys nötig, etwa mehrere Instanzen hinter einer ge­mein­sa­men IP-Adresse.
• Zu­sätz­li­che Latenz: Jede Anfrage durch­läuft eine weitere Station. In der Praxis ist der Aufschlag meist gering und wird durch Caching und Kom­pres­si­on oft mehr als aus­ge­gli­chen, bei schlecht di­men­sio­nier­ten Proxys kann er sich aber bemerkbar machen.
• Fehl­kon­fi­gu­ra­ti­on: Falsche Regeln können Si­cher­heits­lü­cken öffnen, etwa wenn interne Pfade oder Ad­mi­nis­tra­ti­ons­ober­flä­chen ungewollt öf­fent­lich er­reich­bar werden, per­so­na­li­sier­te Seiten im Cache landen oder Backends ungeprüft wei­ter­ge­reich­ten Client-IPs vertrauen.
• War­tungs­auf­wand: Der Proxy ist ein ex­po­nier­tes System und muss re­gel­mä­ßig ak­tua­li­siert, überwacht und ab­ge­si­chert werden. Zer­ti­fi­ka­te, Regeln und Wei­ter­lei­tun­gen sind zu pflegen.