Reverse Proxy

Ein Server, der vor deinen Backend-Servern sitzt und Anfragen entgegennimmt, verteilt und absichert – für Load Balancing, SSL, Caching und Security.

Fortgeschritten2 Min Lesezeit

Erklärung starten

Auf einen Blick

3 Punkte

  1. Sitzt vor Backend-Servern und leitet Requests weiter
  2. Übernimmt SSL-Terminierung, Caching, Load Balancing
  3. Versteckt Backend-Infrastruktur vor dem Internet

Sofortantwort

Reverse Proxy einfach erklärt

Vermittler zwischen Clients und Backend-Servern für Security und Performance.

Kurz gesagt
Sitzt vor Backend-Servern und leitet Requests weiter
Typischer Einsatz
SSL-Terminierung, Load Balancing, Caching
Wichtig zu wissen
Versteckt Backend-Infrastruktur vor dem Internet

Reverse Proxy im Überblick

Ein Reverse Proxy sitzt zwischen dem Internet und deinen Servern. Alle Anfragen gehen erst an den Proxy, der sie dann an den richtigen Backend-Server weiterleitet.

Ohne Reverse Proxy:

Internet → Backend-Server (direkt erreichbar)
         → Jeder Server braucht SSL
         → Keine zentrale Kontrolle

Mit Reverse Proxy:

Internet → Reverse Proxy → Backend-Server 1
                        → Backend-Server 2
                        → Backend-Server 3
         
         ↑ SSL hier    ↑ Intern HTTP OK
         ↑ Caching
         ↑ Security

Was macht ein Reverse Proxy?

FunktionBeschreibung
SSL-TerminierungHTTPS entschlüsseln, intern HTTP
Load BalancingTraffic auf Server verteilen
CachingStatische Inhalte zwischenspeichern
CompressionGzip/Brotli für kleinere Responses
SecurityWAF, Rate Limiting, IP-Blocking
Routing/api → Backend A, /web → Backend B

Technisch betrachtet

Nginx Konfiguration

Einfacher Reverse Proxy:

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://localhost:3000;
        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;
    }
}

Mit SSL:

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

    ssl_certificate /etc/ssl/certs/example.com.crt;
    ssl_certificate_key /etc/ssl/private/example.com.key;

    location / {
        proxy_pass http://localhost:3000;
    }
}

# HTTP → HTTPS Redirect
server {
    listen 80;
    server_name example.com;
    return 301 https://$server_name$request_uri;
}

Load Balancing:

upstream backend {
    server 10.0.0.1:3000 weight=3;
    server 10.0.0.2:3000 weight=2;
    server 10.0.0.3:3000 weight=1;
}

server {
    location / {
        proxy_pass http://backend;
    }
}

Traefik (Docker/Kubernetes)

docker-compose.yml:

services:
  traefik:
    image: traefik:v3.0
    command:
      - "--providers.docker=true"
      - "--entrypoints.web.address=:80"
      - "--entrypoints.websecure.address=:443"
      - "--certificatesresolvers.letsencrypt.acme.email=admin@example.com"
      - "--certificatesresolvers.letsencrypt.acme.storage=/letsencrypt/acme.json"
      - "--certificatesresolvers.letsencrypt.acme.httpchallenge.entrypoint=web"
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./letsencrypt:/letsencrypt

  app:
    image: myapp:latest
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.app.rule=Host(`app.example.com`)"
      - "traefik.http.routers.app.tls.certresolver=letsencrypt"

Caddy (Automatisches HTTPS)

Caddyfile:

example.com {
    reverse_proxy localhost:3000
}

api.example.com {
    reverse_proxy localhost:8080
}

Das war’s – Caddy holt automatisch Let’s Encrypt Zertifikate.

Security-Features

Rate Limiting (Nginx):

limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

server {
    location /api/ {
        limit_req zone=api burst=20 nodelay;
        proxy_pass http://backend;
    }
}

IP Blocking:

location / {
    deny 192.168.1.1;
    deny 10.0.0.0/8;
    allow all;
    proxy_pass http://backend;
}

Headers hinzufügen:

add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-XSS-Protection "1; mode=block" always;

Caching

proxy_cache_path /var/cache/nginx levels=1:2 
                 keys_zone=my_cache:10m max_size=1g 
                 inactive=60m use_temp_path=off;

server {
    location /static/ {
        proxy_cache my_cache;
        proxy_cache_valid 200 1d;
        proxy_cache_use_stale error timeout updating;
        proxy_pass http://backend;
    }
}

01Einsatzbereiche

Wann ist Reverse Proxy sinnvoll?

Geeignet für

  • SSL-TerminierungHTTPS am Proxy, HTTP intern – einfachere Zertifikatsverwaltung
  • Load BalancingRequests auf mehrere Backend-Server verteilen
  • CachingStatische Inhalte cachen, Backend entlasten
  • SicherheitWAF, Rate Limiting, IP-Blocking am Eingang

↑ Inhalt

02Werkzeuge

Womit Reverse Proxy umgesetzt wird

↑ Inhalt

Merksatz

Ein Reverse Proxy ist wie ein Empfangstresen in einem großen Unternehmen

Besucher (Requests) kommen an, werden geprüft, und dann zum richtigen Mitarbeiter (Backend-Server) weitergeleitet – ohne dass Besucher direkt in die Büros laufen.

  1. Sitzt vor Backend-Servern und leitet Requests weiter
  2. Übernimmt SSL-Terminierung, Caching, Load Balancing
  3. Versteckt Backend-Infrastruktur vor dem Internet

04Redaktion

Herkunft und Stand

Redaktion und Aktualität

Ebenex RedaktionRedaktion

Veröffentlicht
Aktualisiert

Dieses Feld entwickelt sich schnell. Oben stehen Veröffentlichung und letzte Änderung; ein Prüfdatum kommt dazu, sobald die Erklärung nach ihrer letzten Änderung geprüft wurde.

↑ Inhalt

05FAQ

Häufige Fragen zu Reverse Proxy

Was ist der Unterschied zwischen Reverse Proxy und Load Balancer?

Load Balancer verteilt Traffic auf Server. Reverse Proxy kann das auch, aber zusätzlich: SSL, Caching, Compression, Header-Manipulation. Oft ist ein Reverse Proxy auch Load Balancer.

Reverse Proxy vs. Forward Proxy?

Forward Proxy: Sitzt vor Clients, versteckt deren Identität (VPN-ähnlich). Reverse Proxy: Sitzt vor Servern, versteckt deren Identität. Unterschiedliche Richtung.

Brauche ich einen Reverse Proxy?

Für Produktion fast immer ja. SSL-Terminierung, Security, Logging, Flexibilität. Ausnahme: Serverless/PaaS wo das die Plattform übernimmt.

Nginx oder Traefik?

Nginx: Bewährt, schnell, mehr manuelle Konfiguration. Traefik: Modern, automatische Service Discovery, ideal für Kubernetes/Docker. Beide gut.

↑ Inhalt

06Weiterlernen

Was möchtest du als Nächstes verstehen?

  • Grundlage nachholen

    Load Balancing

    Eingehende Anfragen werden auf mehrere Server verteilt, um Überlastung zu vermeiden.

↑ Inhalt