Programmierung · Server · Netzwerk

Was ist ein Reverse Proxy?

Sobald Sie mehr als eine Anwendung auf einem Server betreiben — eine Website, eine API, vielleicht ein paar Container — stoßen Sie auf ein praktisches Problem: Besucher landen alle auf den Ports 80 und 443, aber jede Anwendung lauscht woanders. Ein Reverse Proxy ist die Standardantwort. Dieser Leitfaden erklärt, was ein Reverse Proxy ist, wie er sich von dem Proxy unterscheidet, den Sie vielleicht schon kennen, und warum fast jede Produktivumgebung einen hat.

Die kurze Definition

Ein Reverse Proxy ist ein Server, der vor einem oder mehreren Backend-Servern steht, jede eingehende Client-Anfrage entgegennimmt und an das passende Backend weiterleitet — und dann dessen Antwort an den Client zurückgibt. Für den Besucher ist der Reverse Proxy die Website: Er spricht nur mit ihm und sieht die dahinterliegenden Server nie. Das Wort „Reverse" (umgekehrt) ist wichtig, und der nächste Abschnitt erklärt warum.

Reverse Proxy vs. Forward Proxy

Ein gewöhnlicher (Forward) Proxy steht vor den Clients. Wenn Ihr Browser so konfiguriert ist, dass er einen verwendet, gehen Ihre Anfragen über den Proxy in Ihrem Namen hinaus — er handelt für diejenigen, die Anfragen stellen. Ein Reverse Proxy ist das Spiegelbild: Er steht vor den Servern und handelt in deren Namen. Clients verbinden sich mit ihm in dem Glauben, er sei der echte Server, und er entscheidet, welches Backend jede Anfrage tatsächlich bearbeitet. Dieselbe Idee eines Vermittlers, nur auf der gegenüberliegenden Seite des Gesprächs.

Wofür man einen Reverse Proxy wirklich nutzt

• Routing nach Hostname oder Pfad: api.example.com an Ihre API und example.com an Ihre Website senden, obwohl beide auf derselben Maschine laufen.
• TLS-Terminierung: HTTPS-Zertifikate an einer Stelle verwalten, damit jedes Backend intern einfaches HTTP spricht und Sie Zertifikate nur einmal verwalten.
• Caching: häufige Antworten direkt speichern und ausliefern, damit das Backend nicht bei jeder Anfrage belastet wird.
• Pufferung und Schutz: langsame Clients abfangen, Limits durchsetzen und die echten Adressen der Backends hinter einem einzigen öffentlichen Eingang verbergen.

In der Praxis genügen Routing und TLS schon als Begründung: Sie erlauben es, mehrere Anwendungen sauber auf einem einzigen VPS zu hosten, mit HTTPS, hinter einer einzigen Adresse.

Reverse Proxy vs. Load Balancer

Diese überschneiden sich, daher die Verwechslung. Ein Load Balancer hat eine konkrete Aufgabe: eingehenden Verkehr auf mehrere identische Backends verteilen, damit keines überlastet wird. Ein Reverse Proxy ist das umfassendere Konzept — er leitet Anfragen weiter und kann vieles tun (Routing, TLS, Caching), und das Verteilen der Last auf Backends ist eines davon. Ein Load Balancer ist also im Kern ein Reverse Proxy, der sich auf die Lastverteilung konzentriert. Die meisten modernen Reverse Proxies können auch Last verteilen, während ein dedizierter Load Balancer oft wenig anderes tut.

Die gängigen Tools

Die am weitesten verbreiteten Reverse Proxies sind Nginx, Caddy, HAProxy und Traefik. Nginx ist der langjährige Standard und extrem schnell beim Ausliefern und Proxyen. Caddy ist beliebt, weil es HTTPS-Zertifikate fast ohne Konfiguration automatisch beschafft und erneuert. Traefik ist für Container- und Kubernetes-Umgebungen gebaut, wo es Dienste erkennt, sobald sie auftauchen und verschwinden. HAProxy wird bevorzugt, wenn Lastverteilung bei hohem Volumen die Priorität ist. Cloud-Anbieter bieten zudem verwaltete Reverse Proxies und Load Balancer als Dienst an.

Ein minimales Beispiel

Eine Reverse-Proxy-Konfiguration ist vor allem eine kurze Liste von Regeln. In Nginx sieht das Weiterleiten von Anfragen für einen Host an eine lokal auf Port 3000 laufende App so aus:

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
    }
}

Das ist die ganze Idee: Anfragen für example.com kommen bei Nginx auf Port 80 an, und Nginx leitet sie an Ihre App auf Port 3000 weiter und gibt den ursprünglichen Host mit. Fügen Sie einen TLS-Block und einen zweiten server für Ihre API hinzu, und eine einzige Maschine bedient sauber mehrere Anwendungen über HTTPS.

Die ehrlichen Kompromisse

Ein Reverse Proxy fügt ein weiteres bewegliches Teil hinzu. Er wird zur einzigen Stelle, durch die jede Anfrage fließt, sodass bei seinem Ausfall alles dahinter unerreichbar ist — weshalb man ihn in Produktion zuverlässig und manchmal doppelt betreibt. Er fügt außerdem etwas Latenz und eine weitere zu verstehende Konfigurationsdatei hinzu. Für eine einzige kleine App, die bereits auf Port 443 lauscht, brauchen Sie ihn vielleicht gar nicht. Doch sobald Sie mehr als einen Dienst hosten, HTTPS an einer Stelle verwalten oder skalieren wollen, macht sich ein Reverse Proxy schnell bezahlt.

Häufig gestellte Fragen

Stöbern Sie in weiteren klaren Erklärungen in unserem Guide-Index.