Reverse Proxy mit NGINX – Setup, HTTPS und Cache Praxis

Du möchtest Webdienste sicher veröffentlichen, Last verteilen und Antwortzeiten verbessern. Genau dafür eignet sich NGINX als Reverse Proxy. Er sitzt vor deinen Apps, nimmt Anfragen an, spricht TLS, setzt Header, cached Antworten und leitet nur das weiter, was wirklich zum Backend muss.

Das Schöne: Der Einstieg ist einfach und schrittweise möglich. Mit einer kleinen Konfigurationsdatei bekommst du HTTPS, Weiterleitungen, GZip und Caching unter Kontrolle. In diesem Guide zeige ich dir die Bausteine, erkläre die wichtigsten Direktiven und gebe dir kopierbare Snippets für dein erstes Setup.

Was ein Reverse Proxy macht

Ein Reverse Proxy nimmt Anfragen von außen entgegen und reicht sie an einen internen Dienst weiter, zum Beispiel an http://127.0.0.1:3000. Vorteile: TLS liegt zentral an, Sicherheitsregeln und Rate Limiting sind an einer Stelle, Caching entlastet die App und du kannst mehrere Dienste unter einer Domain betreiben.

Installation und Basis-Setup

NGINX installieren

Unter Ubuntu/Debian installierst du NGINX mit dem Paketmanager. Nach der Installation läuft ein Default-Server, den du durch eine eigene Server-Block-Datei ersetzt.

Minimaler Reverse-Proxy

Die folgende Konfiguration leitet https://example.com an http://127.0.0.1:3000 weiter und setzt sinnvolle Header und Timeouts.

# /etc/nginx/sites-available/example.conf
server {
  listen 80;
  server_name example.com www.example.com;
  return 301 https://example.com$request_uri;
}

server {
  listen 443 ssl http2;
  server_name example.com;

  # TLS - Zertifikate (Let's Encrypt legt diese Pfade an)
  ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
  ssl_protocols TLSv1.2 TLSv1.3;
  ssl_ciphers HIGH:!aNULL:!MD5;

  # Sicherheitsrelevante Header
  add_header X-Content-Type-Options "nosniff" always;
  add_header X-Frame-Options "SAMEORIGIN" always;
  add_header Referrer-Policy "strict-origin-when-cross-origin" always;

  # GZip fürs Web-Delivery
  gzip on;
  gzip_types text/plain text/css application/javascript application/json image/svg+xml;

  # Proxy Settings
  location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_http_version 1.1;
    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;
    proxy_read_timeout 30s;
    proxy_connect_timeout 5s;
  }
}

Wichtig: server_name, Zertifikatspfade und Backend-Adresse anpassen. HTTP auf HTTPS umleiten schützt vor Plaintext-Zugriffen.

TLS einrichten – ideal mit Let’s Encrypt

Zertifikate beziehen

Mit Certbot holst du kostenlose Zertifikate und aktivierst Auto-Renewal.

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com

Hinweis: TLS 1.2 und TLS 1.3 sind Standard. Halte Cipher Suites modern. Für HTTP/2 reicht http2 im listen-Block. HTTP/3 ist optional, erfordert QUIC und zusätzliche Listen-Direktiven.

Caching – Backend entlasten, Antworten beschleunigen

Proxy-Cache anlegen

Ein Disk Cache spart Backend-Zeit ein. Definiere ihn global und nutze ihn pro Location.

# /etc/nginx/nginx.conf (http {})
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=STATIC:100m
                 max_size=1g inactive=60m use_temp_path=off;
proxy_cache_key "$scheme$request_method$host$request_uri";

# im Server-Block
location /assets/ {
  proxy_pass http://127.0.0.1:3000;
  proxy_cache STATIC;
  proxy_cache_valid 200 302 24h;
  proxy_cache_valid 404 1m;
  proxy_ignore_headers Set-Cookie;
  add_header X-Cache-Status $upstream_cache_status;
}

Erklärung: keys_zone definiert den Cache, proxy_cache_valid steuert TTL. Über X-Cache-Status siehst du MISS, HIT oder BYPASS. Set-Cookie ignorieren verhindert, dass personalisierte Antworten im Shared Cache landen.

HTML vorsichtig cachen

Dynamisches HTML lieber kurz oder gar nicht cachen. Alternativ stale-while-revalidate via proxy_cache_use_stale updating error timeout; nutzen, um bei Kurzspitzen alte Inhalte kurz zu liefern.

Load Balancing und Upstreams

Mehrere Backends einbinden

Mit upstream verteilst du Last auf mehrere App-Server. Einfache Health Checks erreichst du mit max_fails und fail_timeout.

upstream app_pool {
  server 127.0.0.1:3001 max_fails=3 fail_timeout=10s;
  server 127.0.0.1:3002 max_fails=3 fail_timeout=10s;
  keepalive 32;
}

server {
  listen 443 ssl http2;
  server_name example.com;
  # ... TLS und Header wie oben ...

  location / {
    proxy_pass http://app_pool;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Proto $scheme;
  }
}

Tipp: keepalive reduziert TCP-Overhead. Für Sticky Sessions brauchst du Cookie-basierte Lösungen in der App oder spezielle Hash-Verfahren.

Logging, Monitoring, Fehleranalyse

Logs verstehen

NGINX schreibt access.log und error.log. Prüfe Statuscodes, Antwortzeiten und den Cache-Header.

log_format main '$remote_addr - $request $status $body_bytes_sent $request_time '
                'upstream:$upstream_addr ustat:$upstream_status ureq:$upstream_response_time '
                'cache:$upstream_cache_status';
access_log /var/log/nginx/access.log main;

Praxis: Hohe $request_time mit MISS deuten auf Kaltstart oder langsames Backend hin. Viele 5xx-Codes im error.log sprechen für Timeouts oder Backend-Fehler.

Sicherheit und saubere Defaults

Größe begrenzen, Timeouts setzen

Mit client_max_body_size verhinderst du übergroße Uploads. Timeouts schützen vor hängenden Verbindungen.

server {
  # ...
  client_max_body_size 20m;
  send_timeout 15s;
  keepalive_timeout 65s;
}

Weiterleitungen und echte IPs

Hänge X-Forwarded-For an, damit deine App die Client-IP sieht. Leite www konsequent auf kanonische Domain um und setze 301 statt 302, wenn es dauerhaft ist.

Häufige Fehler – und die schnelle Lösung

• 502 Bad Gateway: Backend nicht erreichbar. proxy_pass prüfen, Firewall und App-Port verifizieren.
• Zu starke Kompression: Doppelte Kompression vermeiden, gzip_proxied prüfen.
• Falsche Zertifikatspfade: ssl_certificate und Key stimmen nicht. Certbot neu laufen lassen.
• Cache-poisoning durch Cookies: Set-Cookie ignorieren oder nur /assets cachen.

Dein Fahrplan in kurz

Starte mit einem einfachen Server-Block, aktiviere TLS mit Let’s Encrypt, setze Header und GZip. Füge Proxy-Cache für statische Inhalte hinzu und beobachte X-Cache-Status in den Logs. Wenn stabil, erweitere um Upstreams und Load Balancing. Dokumentiere jede Direktive kurz in der Config, damit du und dein Team später schneller anpassen könnt.

Fazit

Mit NGINX als Reverse Proxy bekommst du Sicherheit, Performance und Kontrolle an einer zentralen Stelle. TLS schützt die Verbindung, Caching beschleunigt Antworten und Load Balancing macht deine Dienste robuster. Wenn du saubere Defaults, klare Header und übersichtliche Logs kombinierst, bleibt dein Setup einfach zu betreiben und wächst stressfrei mit.