Katalog
concept#Architektur#Sicherheit#Plattform#Zuverlässigkeit

Reverse Proxy

Ein Vermittler-Server, der Client-Anfragen entgegennimmt und an interne Backend-Server weiterleitet, wobei er Routing-, Sicherheits- und Performance-Funktionen zentralisiert.

Ein Reverse Proxy ist ein Server zwischen Clients und Backend-Services, der Anfragen entgegennimmt und an interne Server weiterleitet.
Etabliert
Mittel

Klassifikation

  • Mittel
  • Technisch
  • Architektur
  • Fortgeschritten

Technischer Kontext

NGINX / NGINX IngressHAProxyKubernetes Ingress Controller

Prinzipien & Ziele

Single‑Responsibility: Reverse Proxy übernimmt zentrale Cross‑Cutting‑Funktionen, Backends bleiben zustandslos.Observability: Proxy sollte Metriken, Logs und Tracing‑Kontexte liefern.Fail‑Fast und Health‑Checks: Unhealthy Backends automatisch aus dem Pool entfernen.
Betrieb
Unternehmen, Domäne, Team

Use Cases & Szenarien

Kompromisse

  • Fehlkonfiguration kann Traffic blockieren oder Sicherheitslücken öffnen.
  • Ungenügende Skalierung führt zu Engpässen unter Last.
  • Falsch implementiertes TLS‑Handling kompromittiert Vertraulichkeit.
  • Betreibe Proxy‑Instanzen hochverfügbar in mehreren Availability Zones.
  • Zentralisiere TLS‑Management und automatisiere Zertifikatserneuerung.
  • Instrumentiere Metriken und Verteile Logs für schnelles Troubleshooting.

I/O & Ressourcen

  • Liste der Backend‑Services/Upstreams
  • Routing‑Regeln und Header‑Policies
  • TLS‑Zertifikate und Secrets
  • Zentrales Routing und Load‑Balancing
  • Aggregierte Metriken und Logs
  • Verbesserte Ausfallsicherheit und Performance

Beschreibung

Ein Reverse Proxy ist ein Server zwischen Clients und Backend-Services, der Anfragen entgegennimmt und an interne Server weiterleitet. Er bietet Lastverteilung, TLS‑Beendigung, Caching und Sicherheitsfunktionen sowie zentrales Routing. Reverse Proxies unterstützen Health‑Checks, Canary‑Rollouts und liefern Metriken und Logs zur Observability ohne Änderungen an Backends.

✔

  • Zentrale Kontrolle über Routing und Sicherheitsrichtlinien.
  • Entlastung der Backends durch Caching und TLS‑Offload.
  • Ermöglicht Canary‑Deployments und feingranulare Traffic‑Steuerung.

✖

  • Zusätzliche Latenz und potenzieller Single Point of Failure ohne HA.
  • Komplexität in Konfiguration und Geheimnisverwaltung (TLS).
  • Cache‑Invalidation und Konsistenz können schwierig sein.

  • Latenz (p95/p99)

    Messung der Antwortzeiten durch den Proxy; wichtig für Performance‑SLAs.

  • Cache‑Trefferquote

    Anteil der Anfragen, die aus dem Cache bedient wurden; beeinflusst Backend‑Load.

  • Fehlerquote upstream

    Anteil der fehlerhaften Antworten von Backends, beobachtbar über den Proxy.

NGINX als Reverse Proxy vor einer Web‑Applikation

NGINX terminiert TLS, verteilt Last und cached statische Inhalte für eine skalierende Web‑Applikation.

HAProxy für hohen Durchsatz und TCP‑Routing

HAProxy wird für SSL‑Passthrough, TCP‑Load‑Balancing und detailliertes Health‑Checking eingesetzt.

Kubernetes Ingress Controller als Reverse Proxy

Ingress Controller (z. B. NGINX Ingress) steuert Routing, TLS und Rate‑Limiting für Container‑Workloads.

1

Architektur und Anforderungen analysieren

2

Geeignete Proxy‑Software auswählen (NGINX/HAProxy/Ingress)

3

Upstreams, Routing‑Regeln und TLS konfigurieren

4

Health‑Checks, Rate‑Limiting und Caching aktivieren

5

Monitoring, Alerts und Tests (Canary) einführen

⚠️ Technische Schulden & Engpässe

  • Hardcodierte Upstream‑Listen statt Service‑Discovery.
  • Nicht versionierte Proxy‑Konfiguration erschwert Rollbacks.
  • Fehlende Automatisierung für Cert‑Rotation und Key‑Management.
TLS‑CPU‑LastNetzwerkbandbreiteProxy‑State/Session‑Management
  • TLS‑Zertifikate lokal auf einer einzelnen Proxy‑Instanz speichern ohne Rotation.
  • Alle Authentifizierungschecks nur im Proxy und nicht in Backends durchführen.
  • Dynamische API‑Antworten großzügig cachen und dadurch inkonsistente Daten liefern.
  • Übersehene Header‑Weitergabe (X‑Forwarded‑For, Trace‑Header) bricht Authentifizierung.
  • Unzureichende Timeouts führt zu gehängten Verbindungen unter Last.
  • Fehlende Upstream‑Health‑Checks lässt defekte Backends im Verkehr bleiben.
Netzwerk‑ und TLS‑GrundlagenKonfiguration von Webservern/Proxies (NGINX, HAProxy)Monitoring und Log‑Analyse
Skalierbarkeit durch LastverteilungSicherheit und PerimeterkontrolleBetriebliche Observability und Monitoring
  • • Erforderliche Hochverfügbarkeit für produktiven Einsatz
  • • Regulatorische Anforderungen an TLS/Logging
  • • Limitierte Proxy‑Ressourcen (CPU/RAM) beeinflussen Skalierung