# Nginx Masterclass: Reverse Proxy & Load Balancing

TL;DR / Management Summary Ein Reverse Proxy ist der “Single Point of Entry” für Ihre Infrastruktur. Er nimmt Anfragen aus dem Internet entgegen und verteilt sie an interne Backend-Server. Nginx ist dafür das Werkzeug schlechthin. Er bietet nicht nur Sicherheit (SSL-Termination), sondern kann Last auf mehrere Server verteilen (Load Balancing) und durch Caching die Antwortzeiten massiv senken.

# 1. Einführung & Architektur

Warum ein Proxy nötig ist.

In modernen Architekturen stehen Applikationsserver (Node.js, Go, Python) oft in isolierten Netzen. Der Proxy agiert als Schutzschild und Verteiler.

# Architektur-Übersicht (Mermaid)

graph TD
    A[Client: Internet] -->|HTTPS Port 443| B[Nginx Reverse Proxy]
    subgraph "Internal Network"
        B -->|HTTP Port 8080| C[App Server 1]
        B -->|HTTP Port 8080| D[App Server 2]
        B -->|HTTP Port 8080| E[App Server 3]
    end
    B -->|Check Cache| F[RAM Cache]

# 2. Der Reverse Proxy: Grundsetup

Anfragen sicher weiterleiten.

# Beispiel: Einfacher Proxy (/etc/nginx/sites-available/proxy)

server {
    listen 443 ssl;
    server_name service.company.com;

    ssl_certificate /etc/letsencrypt/live/service.company.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/service.company.com/privkey.pem;

    location / {
        proxy_pass http://10.0.0.50:8080;
        
        # Wichtig: Header weitergeben, damit die App die echte Client-IP sieht
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

# 3. Load Balancing: Skalierung für Fortgeschrittene

Last intelligent verteilen.

Nutzen Sie den upstream Block, um mehrere Server zu bündeln.

upstream backend_cluster {
    # Round Robin (Default)
    server 10.0.0.51:8080 weight=3; # Bekommt mehr Traffic
    server 10.0.0.52:8080;
    server 10.0.0.53:8080 backup;   # Springt nur ein, wenn andere down sind
    
    # Optional: Merkt sich User-Sitzungen (Sticky Sessions)
    # ip_hash;
}

server {
    listen 80;
    server_name api.company.com;

    location / {
        proxy_pass http://backend_cluster;
    }
}

# 4. Performance & Caching

Millisekunden sparen.

# Gzip Kompression

Spart massiv Bandbreite bei Text-Dateien (HTML, JSON, JS).

gzip on;
gzip_types text/plain text/css application/json application/javascript;

# Static File Caching

location /static/ {
    root /var/www/data;
    expires 30d;
    add_header Cache-Control "public, no-transform";
}

# 5. Troubleshooting & “War Stories”

Wenn der Proxy blockiert.

# Story 1: “Upstream Too Big (HTTP 502)”

Symptom: Nginx meldet sporadisch “502 Bad Gateway” bei großen Dateiuploads oder komplexen Formularen. Ursache: Die Backend-Antwort ist zu groß für die Nginx-Buffer. Lösung: Buffer-Größen erhöhen:

proxy_buffers 8 16k;
proxy_buffer_size 32k;

# Story 2: “WebSocket Verbindungen brechen ab”

Symptom: Chat-Apps oder Real-Time Dashboards funktionieren nicht über den Proxy. Ursache: WebSockets benötigen ein Upgrade des HTTP-Protokolls, das Nginx standardmäßig nicht durchreicht. Lösung: Hop-by-Hop Header setzen:

proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";

# 6. Fazit & Empfehlung

• Sicherheit: Nutzen Sie Nginx als SSL-Terminator. So müssen Ihre Backend-Apps keine Zertifikate verwalten.
• Health-Checks: Prüfen Sie regelmäßig die Erreichbarkeit der Upstreams.
• Logs: Trennen Sie Proxy-Logs von Backend-Logs, um Engpässe schnell zu identifizieren.

# Anhang: Cheatsheet