Reverse Proxy

Entstehung und Beteiligte

Reverse Proxys entstanden aus Web-Proxys und Server-Gateways. CERN httpd, Apache, Squid, NGINX und kommerzielle Produkte entwickelten die Rolle weiter. Der Begriff beschreibt die Position vor Servern, nicht einen einzelnen Standard.

Welches Problem sollte gelöst werden?

Clients sollten einen stabilen öffentlichen Endpunkt sehen, während interne Server wechseln, geschützt oder gemeinsam genutzt werden. TLS, Caching und Zugriffskontrolle konnten zentral gebündelt werden.

Technische Hürden und Lösungen

Der Proxy muss ursprüngliche Clientdaten sicher weitergeben, Headergrenzen prüfen und Protokoll-Upgrades beherrschen. Falsch vertraute Forwarded-Header ermöglichen Spoofing. Timeouts und Pufferung beeinflussen Streaming und große Uploads.

Standardisierung und Einordnung

Physische und logische Infrastruktur muss über Herstellergrenzen hinweg funktionieren. IEEE-, ISO- und IETF-Standards definieren elektrische Werte, optische Übertragung, Rahmenformate und Steuerprotokolle. In der Praxis kommen weitere Hürden hinzu: Kabellängen, Störungen, Stromversorgung, Wärme, Redundanz und Wartbarkeit. Gute Planung betrachtet deshalb nicht nur Datenblattwerte, sondern den gesamten Lebenszyklus.

Technik im praktischen Betrieb

Planung endet nicht mit dem Kauf eines Geräts. Dokumentation, Beschriftung, Ersatzteile, Firmwarepfade, Strombudget und Messwerte bestimmen die Wartbarkeit. Redundante Leitungen helfen nur, wenn sie nicht im selben Kabelweg, Switch, Netzteil oder Provider enden. Vor einer Änderung sollten Ausgangszustand und Rückweg feststehen. Nachher müssen nicht nur Linkanzeigen, sondern Fehlerzähler, Aushandlung, reale Datenrate und Anwendungserreichbarkeit kontrolliert werden.

Warum das Thema heute noch relevant ist

Infrastruktur bleibt meist länger im Einsatz als Anwendungen. Entscheidungen zu Kabeln, Frequenzen, Portzahl, Leistung und Redundanz wirken zehn Jahre oder länger. Historische Standards sind deshalb weiterhin relevant und werden durch schnellere Varianten erweitert statt vollständig ersetzt. Eine gute Installation lässt Messung, Austausch und Erweiterung zu. Reserven bei Platz, Kühlung, Strom und Fasern sind oft günstiger als ein späterer Umbau unter laufendem Betrieb.

Daten und Meilensteine

• Ein Forward Proxy handelt im Auftrag von Clients, ein Reverse Proxy vor Servern.
• TLS-Terminierung zentralisiert Zertifikate.
• Host- und Pfadregeln können auf verschiedene Backends routen.
• Proxy Protocol oder geprüfte Forwarded-Header übertragen Clientadressen.

Was ist ein Reverse Proxy?

Ein Reverse Proxy ist ein Server, der Anfragen von Clients entgegennimmt und an Backend-Server weiterleitet. Im Unterschied zum Forward Proxy (der Client-Anfragen stellvertretend weiterleitet) schützt der Reverse Proxy Backend-Server vor direktem Zugriff.

Der Client kommuniziert nur mit dem Reverse Proxy – die Existenz der Backend-Server bleibt verborgen. nginx, Apache HTTP Server, Caddy und HAProxy sind die populärsten Reverse-Proxy-Lösungen.

Funktionen

• SSL/TLS-Terminierung: Verschlüsselung am Proxy beenden, Backend HTTP nutzen. Zertifikat-Management zentral.
• Load Balancing: Anfragen auf mehrere Backend-Instanzen verteilen.
• Caching: Statische oder wiederholte Responses cachen – Backend entlasten.
• Kompression: Gzip/Brotli-Kompression für HTTP-Responses.
• URL-Routing: /api/* → API-Server, /static/* → CDN oder Dateisystem.
• Sicherheit: IP-Filterung, Rate Limiting, HTTP-Header-Sanitization, WAF-Integration.
• Automatisches TLS: Caddy generiert und erneuert Let's-Encrypt-Zertifikate automatisch.
• A/B-Testing und Canary Releases durch gewichtetes Routing.

nginx als Reverse Proxy

nginx (Engine-X) ist der meistgenutzte Webserver und Reverse Proxy weltweit. Konfiguration in nginx.conf:

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

Caddy ist moderner und einfacher: automatisches HTTPS, einfache Caddyfile-Syntax. Traefik ist Cloud-native und erkennt Docker/K8s-Container automatisch.