Reverse Proxy

Der normale Proxy schützt den User (versteckt ihn). Der Reverse Proxy schützt den Server (versteckt ihn). Wenn du google.com aufrufst, landest du nie auf dem Computer, der die Suche berechnet. Du landest auf einem Reverse Proxy (an der Tür). Er sagt: "Willkommen! Du willst suchen? Geh zu Server 5." Für dich sieht es aus, als wäre der Proxy der Server. Er macht Security, Lastverteilung und Verschlüsselung zentral an einer Stelle.

Merksatz: Ein Server, der Anfragen aus dem Internet entgegennimmt und an einen oder mehrere interne Backend-Server weiterleitet.

Das Standard-Setup für jede moderne App: User -> Internet -> Nginx (Reverse Proxy) -> Node.js (App) Warum nicht direkt Node.js ans Internet?

SSL Termination: Nginx ist schneller im Verschlüsseln. Node.js muss sich nicht mit Zertifikaten quälen.
Sicherheit: Nginx ist hart und getestet. Node.js hat vielleicht Bugs.
Caching: Nginx speichert Bilder im RAM und liefert sie rasend schnell.

Praxisroutine

In der Praxis lernst du Reverse Proxy, indem du mit einem kleinen, kontrollierten Beispiel beginnst. Baue zuerst einen Minimalfall, prüfe das Ergebnis, veraendere genau eine Sache und beobachte, was sich ändert. Notiere dir Eingabe, Aktion, Ausgabe und typischen Fehler.

Übung: Erstelle ein Beispiel aus deinem Alltag, fuehre den Ablauf gedanklich Schritt für Schritt durch und markiere die Stelle, an der du Feedback oder ein Log brauchst. Wenn du diese Stelle benennen kannst, verstehst du den Begriff praktisch.

1. Load Balancing

Der Reverse Proxy kennt 10 Backend-Server. Algorithmen:

Round Robin: 1, 2, 3, 1, 2, 3...
Least Connections: Wer hat am wenigsten zu tun?
Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Das Standard-Setup für jede moderne App: User - Internet - Nginx (Reverse Proxy) - Node.js (App) Warum nicht direkt Node.js ans Internet? 1. SSL Termination: Nginx ist schneller im Verschlüsseln. Node.js muss sich nicht mit Zertifikaten quälen. 2. Sicherheit: Nginx ist hart und getestet. Node.js hat vielleicht Bugs. 3. Caching: Nginx speichert Bilder im RAM und liefert sie rasend schnell.
IP Hash: "User A landet immer auf Server 1". (Sticky Session). Wichtig, wenn Session-Daten lokal gespeichert sind.

2. Buffering & Slowloris Protection

Node.js (Single Threaded) hasst langsame Clients. Wenn ein Mobile-User 10 Sekunden braucht, um 1KB zu senden, ist der Node-Thread blockiert. Nginx puffert. Er saugt den Request langsam vom User auf, und schießt ihn dann in 1ms an Node.js weiter. Schützt vor Slowloris-Attacken.

3. API Gateway

Ein aufgebohrter Reverse Proxy (z. B. Kong, Traefik). Macht zusätzlich: Authentication (OAuth prüfen), Rate Limiting ("Max 100 Requests/Min"), Logging, Billing.

Zero-Downtime Reloads im Nginx

Ein extrem starkes Feature von industriellen Proxys ist der Konfigurations-Reload ohne verlorene Requests (nginx -s reload). Der Proxy läuft klassisch im Master-Worker Modell. Ändert der Ops das Config-File, schießt er das SIGHUP Signal an den Master-Prozess. Der Master fährt daraufhin neue Worker-Prozesse auf dem aktualisierten Stand hoch. Die alten Worker-Thread beenden sofort das Akzeptieren von neuen TCP-Handshakes, arbeiten aber brav noch laufende Gigabyte-Downloads ab. Erst wenn der letzte User abgekoppelt ist, sterben die alten Threads friedlich. Kein User spürt, dass der Load Balancer umzog.

SSL Passthrough vs. SSL Termination via SNI

Meist entschlüsselt Nginx in der DMZ und pumpt HTTP (Plaintext) zum Node-Backend ins Private Subnet (SSL Termination). Sehr harte Compliance (Banken) verlangt jedoch oft End-to-End, bis in den RAM des Kern-Servers ("Deep im LAN"). Dies löst man per SSL Passthrough auf TCP-Layer-4 Basis (Nginx stream block). Der Proxy fasst die Verschlüsselung nicht an. Das Problem: Ohne Decryption kann der Proxy die Hostnamen-Header (Host: shop.tld) im HTTP-Kopf nicht lesen – wie soll er routen? Die Lösung ist SNI (Server Name Indication). Bereits im unverschlüsselten ClientHello Handshake am Start des TCP-Pakets funkt der moderne Browser den gewünschten Hostnamen. Der Proxy liest diesen String und fädelt den Black-Box-TCP-Stream blind an das richtige interne Backend.

The Upstream Gateway Timeout Mismatch (504)

Einer der häufigsten DevOps-Fehler in Microservices: Ungleiche Timeouts. Der Reverse Proxy hat ein proxy_read_timeout von 60s. Der interne Express.js-Server verarbeitet einen brutalen Report (80s). Nach 60s wirft der Proxy resigniert den harten 504 Gateway Timeout zum Client im Browser. Fatal: Das Node-Backend rödelt trotzdem stur weiter, zerschießt die Datenbank und sendet das Ergebnis 20 Sekunden später per "Broken Pipe" in eine tote Proxy-Wall. Um das zu vermeiden, muss das App-Backend entweder eine harte Timeout-Middleware vorweisen (< 60s Drop), oder der Proxy extrem große Timeouts bei Long-Running API Endpoints genehmigt bekommen.