Reverse Proxy (Nginx, Caddy, Traefik)

1. Überblick über das Konzept und das systemische Problem

Anfänger versuchen oft, ihren Server direkt ins Internet zu stellen: Sie starten npm start oder uvicorn main:app auf Port 80. Diese Konfiguration ist ein grober Verstoß gegen die Architekturstandards für den Produktivbetrieb (Production):

• Sicherheit: Um Ports 80 und 443 zu lauschen, muss der Prozess Root-Rechte (root) besitzen. Jede Schwachstelle in einer npm-Abhängigkeit gibt einem Angreifer volle Kontrolle über das Betriebssystem.
• Slowloris-Angriffe: Ein Client mit schlechter Verbindung, der alle 10 Sekunden nur ein Byte sendet, blockiert einen Worker-Thread von Node.js oder Python und legt so die Bedienung anderer Benutzer lahm.
• Ineffiziente Auslieferung statischer Inhalte: Das Senden von Bildern, Schriftarten und JS-Dateien über die CPU-Threads der Anwendung verbrennt Ressourcen, die eigentlich für die Geschäftslogik reserviert sein sollten.
• Fragilität bei SSL: Die Notwendigkeit, Verschlüsselung innerhalb des Anwendungs-Codes zu konfigurieren, zwingt dazu, den Dienst bei jeder Zertifikatsaktualisierung neu zu starten.

Ein Reverse Proxy fungiert als gesicherte Eingangstür Ihrer Infrastruktur. Er nimmt externen Internet-Traffic entgegen, entschlüsselt HTTPS-Verbindungen, komprimiert Daten, cacht statische Inhalte und leitet den sauberen internen Traffic transparent an lokale Ports Ihrer isolierten Anwendungen weiter (127.0.0.1:3000).

2. Architektonische Taxonomie und mentales Modell

Die Landschaft der Reverse Proxies wird nach dem Paradigma der Konfiguration klassifiziert:

┌─────────────────────────────────────────────────────────────┐
│                 REVERSE PROXY COMPARISON MATRIX             │
├─────────────────────────────────────────────────────────────┤
│ 1. Nginx: Event-driven C architecture (epoll / kqueue)      │
│    • Максимальна сира продуктивність, мінімум пам'яті       │
│    • Вимагає зовнішнього Certbot для Let's Encrypt          │
├─────────────────────────────────────────────────────────────┤
│ 2. Caddy: Memory-safe Go Server with Auto-HTTPS (ACME)      │
│    • Нативне автоматичне отримання та ротація SSL           │
│    • Сучасний лаконічний синтаксис (Caddyfile)              │
│    • Нативна підтримка HTTP/3 (QUIC) з коробки              │
├─────────────────────────────────────────────────────────────┤
│ 3. Traefik: Cloud-Native Container Router                   │
│    • Динамічне підхоплення сервісів за мітками Docker Labels│
│    • Ідеально для автоматизації PaaS (Coolify, Kubernetes)  │
└─────────────────────────────────────────────────────────────┘

1. TLS/SSL-Terminierung (SSL Termination):
   • Der Proxy übernimmt die ressourcenintensiven kryptografischen Handshake-Operationen (TLS Handshake) und entlastet damit das Backend.
2. Routing virtueller Hosts (Virtual Hosting & Routing):
   • Ermöglicht es, auf einem einzigen Server mit einer IP-Adresse Dutzende verschiedener Projekte zu hosten:
     • gotburnout.com ➔ lokaler Container auf Port 3000 (Next.js).
     • api.gotburnout.com ➔ lokaler Container auf Port 8000 (FastAPI).
     • n8n.gotburnout.com ➔ interner Port 5678 (n8n).
3. Proxying von Echtzeit-Streams (WebSockets & SSE):
   • Spezielle Behandlung der Upgrade-Header und Deaktivierung der Pufferung zur Unterstützung voll-duplex Verbindungen und zum Streaming von Token-Generierungen durch LLMs.
4. Kompression im Durchlauf (Gzip & Brotli):
   • Komprimiert Textressourcen und reduziert das Volumen des an den Client übertragenen Traffics um 60–80 %.

3. Technischer Pipeline und interne Mechanik

Der Lebenszyklus eines Client-Requests durch einen Reverse Proxy:

1. Herstellung der sicheren Verbindung (TLS Handshake): Der Client initiiert eine Verbindung auf Port 443. Caddy oder Nginx verhandeln das TLS 1.3 Protokoll, senden ein gültiges Domain-Zertifikat und verschlüsseln den Kanal.
2. Analyse der Header und SNI (Server Name Indication): Der Proxy liest den Header Host: gotburnout.com sowie den URL-Pfad /api/v1/chat.
3. Normalisierung der Proxy-Header: Der Proxy fügt Service-Header hinzu, damit die interne Anwendung die tatsächliche IP-Adresse des Clients kennt:

   X-Real-IP: 203.0.113.195
   X-Forwarded-For: 203.0.113.195, 10.0.0.1
   X-Forwarded-Proto: https
   

4. Weiterleitung an den Upstream (Upstream Dispatch): Die Anfrage wird über einen vorab geöffneten Connection Pool an den lokalen Socket http://127.0.0.1:3000 weitergeleitet.
5. Empfang und Rückgabe der Antwort an den Client:
   • Wenn eine statische Datei zurückgegeben wird – cacht der Proxy diese.
   • Wenn es sich um ein Token-Streaming handelt (SSE) – streamt der Proxy jeden Chunk sofort an den Client, ohne ihn im Buffer zu sammeln.

4. Praktische Engineering-Szenarien im Production-Betrieb

01. Caddy-Konfiguration für Next.js und AI-Streaming in 10 Zeilen

Eine Caddyfile für den Produktivbetrieb mit automatischem HTTPS und Streaming-Unterstützung:

gotburnout.com {
    encode zstd gzip

    # Проксування додатку
    reverse_proxy 127.0.0.1:3000 {
        # Вимкнення буферизації для миттєвого стрімінгу LLM токенів
        flush_interval -1
    }

    # Кешування статичних файлів Next.js на 1 рік
    @static path /_next/static/*
    header @static Cache-Control "public, max-age=31536000, immutable"
}

02. Nginx-Konfiguration für Server-Sent Events (SSE)

Verhinderung von Hängern beim Streaming in Nginx:

location /api/generate {
    proxy_pass http://127.0.0.1:8000;
    proxy_http_version 1.1;
    proxy_set_header Connection '';
    
    # Критично важливі директиви для стрімінгу AI:
    proxy_buffering off;
    proxy_cache off;
    chunked_transfer_encoding on;
    proxy_read_timeout 600s;
}

03. Routing einer Multi-Service-Plattform auf einem einzelnen Server

Organisation des Zugriffs auf interne Tools:

• Caddy verteilt den Traffic: Anfragen an ai.company.internal werden an den Ollama-Container geleitet, während metrics.company.internal auf das Grafana-Dashboard zeigt, wobei der Zugriff durch Basis-Autorisierung (basic_auth) abgesichert wird.

5. Fallstricke, häufige Fehler und Sicherheit

• Hänger beim Streaming durch Pufferung: Der häufigste Fehler in Nginx ist die standardmäßig aktivierte proxy_buffering. Der Benutzer sieht 30 Sekunden lang einen leeren Bildschirm, bevor der gesamte generierte Artikel gleichzeitig erscheint.
• IP-Spoofing durch unsichere Header: Wenn Ihr Backend naiv req.headers['x-forwarded-for'] liest, ohne zu überprüfen, ob die Anfrage tatsächlich von Ihrem lokalen Proxy stammt, kann ein Angreifer jede beliebige IP-Adresse fälschen, um Rate-Limits zu umgehen.
• Host Header Injection: Wenn in der Nginx-Konfiguration ein Standardblock (default_server) definiert ist, der Traffic ohne Prüfung des Host-Namens weiterleitet, kann ein Angreifer Links zur Passwortzurücksetzung über gefälschte Host-Header manipulieren.
• Vergessene Timeouts für lange AI-Anfragen: Der Standard-Timeout für die Antwort vom Backend beträgt 60 Sekunden (proxy_read_timeout 60s). Wenn ein komplexes Reasoning-Modell 90 Sekunden braucht, gibt der Proxy einen 504 Gateway Timeout an den Client zurück. Erhöhen Sie die Timeouts für AI-Routen.