# NGINX: Reverse Proxy, Load Balancing & Content Caching

TL;DR / Management Summary NGINX (sprich: Engine X) ist weit mehr als ein einfacher Webserver. In modernen Infrastrukturen agiert er primär als Reverse Proxy. Er nimmt Anfragen entgegen und leitet sie an interne Applikations-Server oder Container (LXC/Docker) weiter. Ein Senior Admin nutzt NGINX, um statische Inhalte (Bilder, JS) zwischenzuspeichern (Caching) und so die Last auf den Datenbanken massiv zu senken.

# 1. Nginx als Reverse Proxy

Der schlaue Vermittler.

Ein Reverse Proxy steht “vor” dem eigentlichen Server.

• Vorteil: Die interne Infrastruktur ist von außen unsichtbar (Security).
• Vorteil: Nginx kann SSL-Zertifikate (Let’s Encrypt) zentral verwalten.
• Konfiguration:

location / {
    proxy_pass http://internal-server:8080;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
}

# 2. Load Balancing mit Nginx

Einfache Verteilung.

Nginx kann Traffic auf mehrere Backends verteilen (Upstream).

upstream backend_cluster {
    server 10.0.1.51 weight=3;
    server 10.0.1.52;
    server 10.0.1.53 backup;
}

• Weight: Schickt 3x mehr Traffic an Server 1.
• Backup: Dieser Server wird nur genutzt, wenn die anderen beiden offline sind.

# 3. Deep Dive: Content Caching

Den Turbo zuschalten.

Warum sollte die Datenbank jedes Mal das gleiche Logo berechnen?

• Technik: Nginx speichert Antworten der Backends auf der lokalen Disk oder im RAM.
• Effekt: Die Antwortzeit für den User sinkt von 200ms auf < 5ms.
• Aktion: Konfigurieren Sie proxy_cache_path in der globalen Sektion.

# 4. Day-2 Operations: Web Application Firewall (WAF)

Schutz vor Injektionen.

Mit dem Modul ModSecurity wird Nginx zum Sicherheitswächter.

• Nutzen: Erkennt und blockiert SQL-Injections und Cross-Site-Scripting (XSS) bereits am Proxy, bevor sie den App-Server erreichen.

# 5. Troubleshooting & “War Stories”

Wenn der Proxy blockiert.

# Top 3 Fehlerbilder

1. Symptom: “413 Request Entity Too Large”.

   • Ursache: User versucht eine große Datei hochzuladen, Nginx limitiert dies jedoch.
   • Lösung: client_max_body_size 100M; in der Config setzen.

2. Symptom: Bilder oder CSS werden nicht geladen (Mixed Content).

   • Ursache: Der Proxy spricht HTTP mit dem Backend, der User nutzt aber HTTPS. Absolute URLs im HTML zeigen nun auf HTTP.
   • Fix: Nutzen Sie sub_filter, um Links im Output dynamisch zu ersetzen.

3. Symptom: “504 Gateway Timeout”.

   • Ursache: Das Backend braucht zu lange für die Antwort (z.B. komplexe Suche).
   • Lösung: proxy_read_timeout erhöhen.

# “War Story”: Der “Caching” Teufel

Ein Admin aktivierte ein aggressives Caching für ein internes Firmenportal. Das Ereignis: Mitarbeiter beschwerten sich, dass sie nach dem Login die Daten des vorherigen Kollegen sahen. Die Ursache: Nginx hatte die personalisierte Startseite inklusive der Session-Daten gecacht, da der App-Server keinen Cache-Control: private Header mitschickte. Lehre: Cachen Sie niemals personalisierte oder authentifizierte Inhalte, außer Sie nutzen feingranulare Cache-Keys, die den Session-Cookie berücksichtigen.

# 6. Monitoring & Reporting

Dashboarding.

# Nginx VTS (Virtual Host Traffic Status)

Installieren Sie das VTS-Modul für detaillierte JSON-Statistiken.

• KPI: Cache Hit Ratio.
• KPI: Requests per Status Code (Suche nach 5xx Fehlern).

# 7. Fazit & Empfehlung

Nginx ist der Alleskönner für Web-Workloads.

• Empfehlung: Nutzen Sie Nginx für statische Webseiten und als Ingress-Proxy für Docker-Stacks.
• Wahl: Wenn Sie extrem komplexe Layer-4 Lastverteilungen (z.B. für SQL-Cluster oder RDP) benötigen, ist HAProxy (Artikel 746) oft die performantere Wahl.

# Anhang: Cheatsheet (Nginx CLI)

# Referenzen

• NGINX Open Source Documentation
• NGINX Reverse Proxy Guide
• OWASP: Hardening NGINX Guide