Verwendete Software und Versionen
Diese Erklärung bezieht sich auf:
- HTTP-Protokoll: HTTP/1.1, HTTP/2, HTTP/3
- SSL/TLS: Version 1.2+ für sichere Verbindungen
- Reverse Proxy-Konzepte: Plattform-unabhängige Grundlagen
- Kontext: Distributions-übergreifende Proxy-Grundlagen
Reverse Proxy vermittelt zwischen Clients und Backend-Services
Ein Reverse Proxy empfängt Client-Anfragen und leitet sie an Backend-Services weiter - das Gegenteil eines Forward Proxy, der Client-Requests zu externen Servern vermittelt. Diese Vermittlung ermöglicht Service-Konsolidierung: Zehn verschiedene Web-Anwendungen nutzen eine öffentliche IP-Adresse über Port 443, statt separate IPs oder Ports pro Service zu benötigen.
Artikel 1 und Artikel 5 erklären IP-Adressen, Ports und Firewall-Konzepte. Reverse Proxy erweitert diese um Service-Vermittlung: Plausible Analytics lauscht intern auf Port 8000, Matrix Synapse auf Port 8008, Listmonk auf Port 9000. Der Reverse Proxy empfängt alle HTTPS-Requests auf Port 443 und entscheidet anhand des HTTP-Host-Headers, welcher Backend-Service die Anfrage verarbeitet.
Client-Requests enthalten Domain-Information im Host-Header: GET / HTTP/1.1 Host: analytics.example.com. Der Proxy liest diesen Header und leitet den Request an das entsprechende Backend weiter - analytics.example.com zu 127.0.0.1:8000, chat.example.com zu 127.0.0.1:8008. Clients sehen nur Standard-HTTP-Ports 80/443, Backend-Services können beliebige interne Ports verwenden.
Diese Host-Header-Vermittlung funktioniert transparent: Browser senden normale HTTPS-Requests, der Proxy übersetzt sie zu HTTP-Backend-Requests. Antworten durchlaufen den umgekehrten Weg - Backend-Response wird zu Client-Response weitergeleitet. Clients erkennen nicht, dass Backend-Services auf anderen Ports oder IP-Adressen laufen.
SSL-Terminierung zentralisiert Verschlüsselung und Zertifikat-Management
HTTPS-Verbindungen erfordern TLS-Handshake, Zertifikat-Validierung und Ver-/Entschlüsselung für jeden Request. SSL-Terminierung am Reverse Proxy konzentriert diese kryptographischen Operationen zentral. Client-Verbindungen werden am Proxy entschlüsselt, Backend-Kommunikation erfolgt unverschlüsselt über localhost oder private Netzwerke.
Der Proxy verwaltet SSL-Zertifikate und private Schlüssel für alle Domains zentral. Ein Wildcard-Zertifikat für *.example.com deckt analytics.example.com, chat.example.com und newsletter.example.com ab. Die Backend-Services implementieren nur HTTP - die SSL-Konfiguration existiert nur einmal am Proxy statt in jedem Service.
SSL-Terminierung ermöglicht moderne TLS-Features ohne Backend-Modifikationen. HTTP/2 multiplext mehrere Requests über eine TCP-Verbindung und reduziert Latenz. Perfect Forward Secrecy generiert temporäre Schlüssel pro Session - kompromittierte Server-Schlüssel können vergangene Verbindungen nicht entschlüsseln. OCSP Stapling prüft Zertifikat-Gültigkeit vorab und reduziert Client-Latenz beim TLS-Handshake.
Client (HTTPS Port 443) → Reverse Proxy (SSL-Terminierung) → Backend (HTTP Port 8000)
Backend-Services erhalten Client-Informationen über HTTP-Header: X-Forwarded-For für Client-IP, X-Forwarded-Proto: https für ursprüngliches Protokoll, X-Real-IP für ursprüngliche Quell-Adresse. Diese Header ermöglichen korrektes Backend-Logging und IP-basierte Zugriffskontrolle trotz Proxy-Vermittlung.
Domain-basiertes Routing nutzt HTTP-Host-Header für Service-Auswahl
HTTP/1.1 führte den Host-Header für Virtual Hosting ein - mehrere Websites über eine IP-Adresse. Reverse Proxies nutzen diesen Mechanismus für Backend-Auswahl: Identische URLs werden je nach Domain an verschiedene Services weitergeleitet.
Wildcard-Domains skalieren automatisch: Eine Regel für *.api.example.com fängt v1.api.example.com und v2.api.example.com ab. Subdomain-Pattern leiten verschiedene API-Versionen an entsprechende Backend-Services weiter. Neue Subdomains erben automatisch die passenden Routing-Regeln ohne manuelle Konfiguration.
Path-basiertes Routing kombiniert Domain und URL-Pfad für granulare Service-Aufteilung: example.com/api/* zu API-Server Port 3000, example.com/admin/* zu Admin-Interface Port 4000, example.com/* zu Frontend-Website Port 5000. Eine Domain bedient mehrere spezialisierte Backend-Services basierend auf URL-Struktur.
Diese Routing-Flexibilität ermöglicht Service-Architekturen mit klarer Trennung. API-Backend, Admin-Interface und öffentliche Website laufen als separate Prozesse mit eigenen Skalierungs-Charakteristiken, werden aber über einheitliche Domain-Namen zugänglich gemacht.
Backend-Kommunikation überträgt Client-Kontext über HTTP-Header
Backend-Services hinter Reverse Proxies verlieren den direkten Client-Kontakt - alle Requests scheinen vom Proxy zu stammen. HTTP-Header übertragen Original-Client-Informationen: X-Forwarded-For für Client-IP, X-Forwarded-Proto für ursprüngliches Protokoll, X-Forwarded-Host für angefragte Domain.
Proxy-zu-Backend-Requests ergänzen die Standard-HTTP-Header um Client-Kontext:
Original Client-Request:
GET /dashboard HTTP/1.1
Host: analytics.example.com
Proxy-zu-Backend-Request:
GET /dashboard HTTP/1.1
Host: analytics.example.com
X-Forwarded-For: 203.0.113.25
X-Forwarded-Proto: https
X-Real-IP: 203.0.113.25
Backend-Services müssen diese Header für korrektes Verhalten auswerten. Logging-Systeme verwenden X-Forwarded-For für echte Client-IPs statt Proxy-Adressen. Rate-Limiting basiert auf Original-Client-IPs. Redirect-URLs verwenden X-Forwarded-Proto für korrekte HTTPS-Generierung.
Trusted Proxy-Konfiguration verhindert Header-Spoofing. Backend-Services akzeptieren Forwarded-Header nur von konfigurierten Proxy-IPs (127.0.0.1, private Netzwerke). Unbekannte Clients können X-Forwarded-For nicht fälschen - Sicherheit durch IP-basierte Vertrauensstellung.
Load Balancing und Connection Pooling optimieren Backend-Kommunikation
Load Balancing verteilt eingehende Requests auf mehrere Backend-Instanzen für erhöhte Ausfallsicherheit und bessere Performance. Round-Robin wechselt zyklisch zwischen verfügbaren Backends. Least-Connections leitet Requests an Backend mit wenigsten aktiven Verbindungen. IP-Hash gewährleistet Session-Persistenz durch Client-IP-basierte Backend-Zuordnung.
Health Checks überwachen Backend-Verfügbarkeit durch regelmäßige Test-Requests. Nicht antwortende Backends werden automatisch aus dem Load Balancing-Pool entfernt bis sie wieder erreichbar sind. Automatisierte Fehlerbehandlung ermöglicht unterbrechungsfreie Service-Updates und Backend-Wartung.
TCP-Verbindungsaufbau zwischen Proxy und Backend erfordert Handshake-Overhead für jeden Request. Connection Pooling hält TCP-Verbindungen zu Backend-Services offen und verwendet sie für mehrere HTTP-Requests wieder. Persistent Connections reduzieren Latenz und CPU-Verbrauch durch Eliminierung wiederholter Verbindungsaufbauten.
Keep-Alive-Parameter definieren Verbindungs-Wiederverwendung: Maximum Requests pro Connection, Idle-Timeout für ungenutzte Verbindungen, Pool-Größe pro Backend. Diese Parameter balancieren Ressourcen-Nutzung gegen Performance-Verbesserung basierend auf Traffic-Mustern.
Caching und Security-Features erweitern Proxy-Funktionalität
Reverse Proxy-Caching speichert Backend-Responses zwischenzeitlich und serviert wiederholte Requests aus dem Cache. Static Assets (CSS, JavaScript, Bilder) werden nach dem ersten Request gecacht und direkt vom Proxy ausgeliefert ohne Backend-Belastung.
Cache-Control-Header definieren Caching-Verhalten: Cache-Control: max-age=3600 erlaubt einstündiges Caching, Cache-Control: no-cache erzwingt Backend-Validierung bei jedem Request. ETag-Header ermöglichen Conditional Requests - Proxy prüft Content-Änderungen ohne vollständige Response-Übertragung.
Security-Features implementieren Defense-in-Depth-Strategien auf Application-Layer. Security-Header wie Strict-Transport-Security erzwingen HTTPS, X-Content-Type-Options verhindern MIME-Type-Sniffing, X-Frame-Options blockieren Clickjacking. Diese Header-Injection schützt Backend-Services ohne individuelle Implementierung.
Rate-Limiting beschränkt Request-Frequenz pro Client-IP oder Session und schützt vor Brute-Force-Angriffen. IP-basierte Zugriffskontrolle filtert Requests basierend auf Quell-Adressen vor Backend-Weiterleitung. Web Application Firewall-Features analysieren HTTP-Requests auf verdächtige Patterns wie SQL-Injection oder Cross-Site-Scripting.
Monitoring und Troubleshooting für Service-Überwachung
Zehn Backend-Services erzeugen zehn separate Log-Dateien in verschiedenen Verzeichnissen. Das erschwert Fehlersuche: War der langsame Request ein Problem von Plausible auf Port 8000 oder Matrix auf Port 8008? Reverse Proxy-Logs zentralisieren diese Informationen - alle Requests laufen durch einen Punkt mit einheitlicher Protokollierung.
Request-Response-Zeit-Messung unterscheidet zwischen Client-zu-Proxy und Proxy-zu-Backend-Latenz. Ein Request zu analytics.example.com dauert plötzlich 5 Sekunden statt 200ms. Die Proxy-Logs zeigen sofort: Liegt das Problem beim SSL-Handshake (Client-zu-Proxy-Latenz hoch) oder beim Backend-Service (Proxy-zu-Backend-Latenz hoch)?
Access-Logs verwenden strukturierte Formate für automatische Analyse: Combined Log Format, JSON-Logs oder Custom-Formats mit Request-IDs für Trace-Korrelation. Diese Logs enthalten vollständige Request-Informationen: Client-IP, Request-URL, Response-Codes, Response-Zeiten, Backend-Server.
Health Check-Monitoring überwacht Backend-Verfügbarkeit kontinuierlich und protokolliert Ausfälle mit Timestamps. Backend-Pool-Status zeigt aktive/inaktive Services für Kapazitäts-Planung. Failover-Events werden geloggt für Post-Incident-Analyse und Service-Level-Agreement-Berichterstattung.
Weiterführende Schritte:
- IP-Adressen und Ports verstehen ←
- Firewall-Prinzipien verstehen ←
- Debian-Reverse-Proxy mit nginx (geplant)
- OpenBSD-Reverse-Proxy mit httpd (geplant)
- SSL-Zertifikat-Management für Self-Hosting (geplant)
