Was ist ein Reverse Proxy? Ein praktischer DNS- und Web-Leitfaden

Ein Reverse Proxy ist ein Server, der Anfragen im Namen eines oder mehrerer Backend-Server entgegennimmt und sie an das passende Ziel weiterleitet. Aus Sicht eines Besuchers ist der Proxy oft der öffentliche Endpunkt; der Browser verbindet sich nicht direkt mit dem Anwendungsserver. Ein Reverse Proxy kann HTTPS terminieren, Anfragen nach Hostname oder Pfad routen, Verkehr verteilen, Antworten cachen, Inhalte komprimieren und Sicherheitskontrollen anwenden. DNS verweist einen öffentlichen Hostnamen meist auf den Proxy oder auf eine vom Anbieter verwaltete Adresse davor. Der Proxy nutzt dann seine eigene Routing-Konfiguration, um die Upstream-Anwendung zu erreichen.

Reverse Proxy versus Forward Proxy

Ein Forward Proxy handelt für Clients: Der Client sendet Anfragen über ihn, um externe Dienste zu erreichen, oft aus Gründen von Richtlinien, Datenschutz oder Netzwerkzugang. Ein Reverse Proxy handelt für Server: Externe Clients verbinden sich mit ihm, und er leitet Anfragen an Backend-Dienste weiter. Das Wort „Proxy“ allein ist daher mehrdeutig. In einer Website-Architektur stellt ein Reverse Proxy typischerweise den öffentlichen Dienstendpunkt dar und verbirgt Details des Backend-Pools. Er kann mehrere Domains auf derselben Infrastruktur routen und verschiedene Pfade an unterschiedliche Anwendungen leiten, während er einen einzigen öffentlichen Zugangspunkt beibehält.

DNS und ein Reverse Proxy lösen unterschiedliche Teile der Verbindung. DNS ordnet einen Hostnamen einer öffentlichen Adresse oder einem Alias zu. Sobald der Client sich verbindet, nutzt der Proxy HTTP-Host-Informationen, die TLS Server Name Indication und seine eigene Konfiguration, um den richtigen Dienst zu wählen. Das erklärt, warum die Anfrage an eine reine IP eine Standardseite oder eine Zertifikatswarnung zeigen kann, selbst wenn die Domain funktioniert: Die Anfrage enthält womöglich nicht den erwarteten Hostnamen-Kontext. Ebenso erzeugt eine DNS-Änderung nicht automatisch eine passende Proxy-Route oder ein Zertifikat. Beide Ebenen müssen sich über Hostnamen und Ziel einig sein.

Wie der Proxy typischerweise Teil eines Ausfalls wird

Eine Domain kann korrekt auflösen, während der Reverse Proxy auf einen toten Upstream zeigt, den falschen Port nutzt oder einen Hostnamen ablehnt, für den er nicht konfiguriert wurde. TLS-Fehler können auftreten, wenn dem Edge ein gültiges Zertifikat fehlt oder ein verschlüsselter Upstream falsch konfiguriert ist. Ein Proxy kann auch einen Timeout zurückgeben, wenn ein Backend überlastet oder nicht erreichbar ist. Umgekehrt kann eine gesunde Anwendung nicht verfügbar wirken, wenn DNS Clients auf die falsche Proxy-Adresse lenkt. Halten Sie zuerst die DNS-Antwort fest und prüfen Sie dann der Reihe nach HTTP-Antwort, TLS-Verbindung, Proxy-Logs und Backend-Zustand.

• Bestätigen Sie, dass DNS auf den vorgesehenen öffentlichen Proxy-Endpunkt zeigt.
• Prüfen Sie, dass der Proxy für die Domain eine Host-Regel und einen gesunden Upstream hat.
• Prüfen Sie bei HTTPS-Fehlern sowohl die TLS-Einstellungen am Edge als auch am Upstream.
• Nutzen Sie Proxy-Logs, um Routing-Fehler von Anwendungsfehlern zu unterscheiden.
• Gehen Sie nicht davon aus, dass eine IP-Abfrage den Backend-Server offenlegt.

Sicherheitsgrenzen und betriebliche Grenzen

Ein Reverse Proxy kann die direkte Exposition von Backend-Diensten verringern, ist aber nicht automatisch eine Sicherheitsgrenze, solange Zugriffsregeln nicht konfiguriert und gepflegt werden. Der Origin sollte Verkehr nur über die vorgesehenen Pfade akzeptieren, wo die Architektur es erlaubt. Administrationsoberflächen sollten nicht ohne ordentliche Authentifizierung auf öffentlichen Routen liegen. Halten Sie die Proxy-Software gepatcht, beschränken Sie den Verwaltungszugriff und validieren Sie weitergeleitete Header, denn der Proxy wird zum vertrauenswürdigen Interpreten von Client- und Upstream-Informationen. Dokumentieren Sie, welches Team DNS, Proxy-Regeln, Zertifikate und das Backend verantwortet, damit die Störungsbehandlung nicht stockt, weil jede Gruppe annimmt, eine andere Ebene sei zuständig.

Zum Verhältnis zwischen öffentlichem Edge und Backend lesen Sie Was ein Origin-Server ist. Zu globalen Proxy-Netzwerken siehe Wie CDNs DNS nutzen. Eine öffentliche Domain-zu-IP-Prüfung kann die von DNS präsentierte Adresse bestätigen, doch die Route des Reverse Proxys und der Zustand der Anwendung brauchen eigene operative Prüfungen. Werden diese Verantwortlichkeiten getrennt gehalten, wird das Debugging präziser, und ein Adressergebnis wird nicht mit einer vollständigen Infrastrukturdiagnose verwechselt.

Die Verantwortung für Proxy-Regeln explizit machen

Ein Reverse Proxy sitzt an einer kritischen Übergabestelle, halten Sie daher fest, wer DNS, Host-Routing, Zertifikate, Upstream-Definitionen und Zugriffsrichtlinien verantwortet. Eine Änderung kann in einer Ebene korrekt sein und trotzdem scheitern, weil eine andere Ebene nicht aktualisiert wurde: DNS zeigt auf den Proxy, aber dem Proxy fehlt ein virtueller Host; die Route existiert, aber das Zertifikat gilt für einen anderen Namen; oder der Upstream ist gesund, aber eine Firewall blockiert das Proxy-Subnetz. Führen Sie für jeden Produktions-Hostnamen ein einfaches Pfaddiagramm und eine bekanntermaßen funktionierende Anfrage. Vergleichen Sie bei einem Vorfall die öffentliche DNS-Antwort, das Proxy-Zugriffslog, den Upstream-Zustand und das Anwendungslog anhand desselben Anfrage-Zeitstempels oder derselben Korrelations-ID.