🔀 · Traffic-Vermittler

Reverse Proxy: Der unsichtbare Türsteher deines Servers

Ein Reverse Proxy nimmt eingehende Anfragen entgegen und leitet sie an den richtigen Dienst weiter – mit TLS-Terminierung, Load Balancing und Sicherheits-Features. Pflicht für jeden Server der mehrere Services betreibt.

NginxCaddyTLSLoad BalancingHeader

Was ein Reverse Proxy leistet – und warum er unverzichtbar ist

Ohne Reverse Proxy müsste jeder Service auf einem anderen Port lauschen – :5678 für n8n, :3000 für Gitea, :8080 für den nächsten Dienst. Unpraktisch, unsicher, nicht skalierbar.

Ein Reverse Proxy löst das:

TLS-Terminierung: HTTPS wird einmal am Proxy gehandhabt. Services dahinter kommunizieren unverschlüsselt im internen Netzwerk.
Subdomain-Routing: n8n.domain.de → Port 5678, git.domain.de → Port 3000. Ein einziger Port 443 für alles.
Sicherheits-Header: HSTS, CSP, X-Frame-Options zentral setzen – einmal konfiguriert, gilt für alle Services.
Rate Limiting und Auth: Brute-Force-Schutz und Zugangskontrolle vor dem Dienst – Services selbst brauchen keine eigene Auth.

Nginx, Caddy oder Traefik – ein ehrlicher Vergleich

Drei dominante Optionen mit unterschiedlichen Stärken:

Nginx: Kampferprobt, maximale Flexibilität, riesige Dokumentation. Konfiguration in `/etc/nginx/sites-available/` – manuell, aber präzise. TLS via Certbot. Gut wenn komplexe Rewrite-Logik oder statische Files direkt ausgeliefert werden sollen.
Traefik: Für Docker-Umgebungen. Automatische Service-Discovery via Labels, kein Config-Reload. Let's Encrypt eingebaut. Ideal wenn viele Container kommen und gehen.
Caddy: Einfachste Konfiguration, automatisches TLS ohne Setup. `Caddyfile` ist lesbar wie Prosa. Für statische Sites und einfache Proxy-Setups ohne Docker-Komplexität.

# Nginx – einfacher Reverse Proxy Block
server {
    listen 443 ssl;
    server_name n8n.domain.de;
    location / {
        proxy_pass http://localhost:5678;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Häufige Konfigurationen: WebSockets, große Uploads, Timeouts

Standardkonfigurationen reichen nicht immer – drei häufige Spezialfälle:

WebSockets: Brauchen extra Headers: proxy_http_version 1.1, Upgrade und Connection Headers. n8n, Grafana Live und viele andere Tools nutzen WebSockets.
Große Uploads: client_max_body_size 100m in Nginx – Standard ist 1MB, was für File-Uploads schnell zu klein ist
Timeouts: Für lange laufende Requests (KI-Anfragen, langsame APIs): proxy_read_timeout 300s erhöhen. Standard 60s reicht für normale Requests.

Diese Einstellungen sind besonders relevant wenn lokale LLMs über einen Reverse Proxy exponiert werden – Generierung kann 30–120 Sekunden dauern.

Häufige Fragen zum Reverse Proxy

Brauche ich einen Reverse Proxy für einen einzelnen Service?

Technisch nein – ein einzelner Service kann direkt auf Port 443 lauschen. Praktisch ja: TLS-Terminierung, Sicherheits-Header und automatische Zertifikate sind auch für einen Service wertvoller als der Aufwand den Proxy einzurichten. Caddy ist in 10 Minuten aufgesetzt.

Wie stelle ich sicher dass Services NICHT direkt erreichbar sind?

Services ohne Port-Binding in compose.yml starten – nur im internen Docker-Netzwerk erreichbar. Firewall schließt alle Ports außer 80/443 und SSH. Traefik/Nginx als einzige Eintrittspunkte. Services die nur intern gebraucht werden: in separates Netzwerk ohne Proxy-Verbindung.

Was sind X-Forwarded-For Headers und warum sind sie wichtig?

Hinter einem Reverse Proxy sieht der Backend-Service nur die Proxy-IP, nicht die echte Client-IP. X-Forwarded-For und X-Real-IP übermitteln die echte IP – wichtig für Logging, Rate Limiting und Geo-Blocking. Muss explizit im Proxy konfiguriert und im Service ausgewertet werden.

Reverse Proxy und IPv6 – was beachten?

Nginx: `listen [::]:443 ssl` für IPv6 zusätzlich zu IPv4. Traefik unterstützt IPv6 nativ wenn der Docker-Host IPv6 konfiguriert hat. Hetzner Server haben standardmäßig IPv6 – lohnt sich zu aktivieren für vollständige Erreichbarkeit.