In HTTP-Terminologie wirkt er auf der clientseitigen Verbindung als Origin-Server, während er die Anfrage für die eingehende Zustellung übersetzt. Clients adressieren üblicherweise den Reverse Proxy, statt ihn als Allzweck-Relay auszuwählen.
Reverse Proxies übernehmen üblicherweise TLS-Terminierung, Anfrage-Routing, Lastverteilung, Caching, Authentifizierungsintegration, Ratenlimitierung und die kontrollierte Veröffentlichung interner Dienste. Korrektes Design beschränkt zudem direkten Backend-Zugriff und definiert, welche vom Proxy hinzugefügten Header eine Anwendung vertrauen darf. Der öffentliche Name, die Zertifikate, Health Checks und das Ausfallverhalten des Proxys werden Teil der Dienstarchitektur.
Wichtigste Punkte
Routing und IsolationNur erwartete Hosts, Pfade, Methoden und Protokolle routen. Backends in kontrollierte Netzwerke stellen und verhindern, dass Internet-Clients den Proxy umgehen, um einen Origin direkt zu erreichen.
Identität und MetadatenNicht vertrauenswürdige Forwarding-Header entfernen, bevor autoritative Werte hinzugefügt werden. Anwendungen sollten ihnen nur von designierten Proxy-Adressen vertrauen und prüfbare Client-Zuschreibung bewahren.
Verfügbarkeit und DatenschutzBegrenzte Timeouts, Anfragegrößen-Limits, Health Checks, Kapazitätskontrollen und resiliente Instanzen nutzen. Logs minimieren sowie Sitzungstokens, Autorisierungs-Header und entschlüsselten Inhalt schützen.
Wichtige EinschränkungEin Reverse Proxy macht eine Anwendung nicht automatisch sicher und ist nicht synonym mit einer Web Application Firewall. Unsichere Anwendungslogik, großzügige Routen, Origin-Umgehung, Header-Verwirrung oder Proxy-Kompromittierung können den Dienst dennoch exponieren. TLS-Terminierung lässt den Proxy zudem Klartext verarbeiten und kann geschützte Neuverschlüsselung zu Backends erfordern.