Freigeben über

Verwenden von Kestrel mit einem Reverseproxy

  • Artikel

Hinweis

Dies ist nicht die neueste Version dieses Artikels. Die aktuelle Version finden Sie in der .NET 9-Version dieses Artikels.

Warnung

Diese Version von ASP.NET Core wird nicht mehr unterstützt. Weitere Informationen finden Sie in der .NET- und .NET Core-Supportrichtlinie. Die aktuelle Version finden Sie in der .NET 9-Version dieses Artikels.

Wichtig

Diese Informationen beziehen sich auf ein Vorabversionsprodukt, das vor der kommerziellen Freigabe möglicherweise noch wesentlichen Änderungen unterliegt. Microsoft gibt keine Garantie, weder ausdrücklich noch impliziert, hinsichtlich der hier bereitgestellten Informationen.

Die aktuelle Version finden Sie in der .NET 9-Version dieses Artikels.

Kestrel kann eigenständig oder mit einem Reverseproxyserver verwendet werden. Ein Reverseproxyserver empfängt HTTP-Anforderungen aus dem Netzwerk und leitet diese an Kestrel weiter. Beispiele für einen Reverseproxyserver:

Kestrel bei Verwendung als Webserver mit direkter Internetverbindung:

Kestrel kommuniziert direkt mit dem Internet ohne einen Reverseproxyserver

Kestrel bei Verwendung in einer Reverseproxykonfiguration:

Kestrel kommuniziert indirekt mit dem Internet über einen Reverseproxyserver wie IIS, Nginx oder Apache

Jede der beiden Konfigurationen – mit oder ohne einen Reverseproxyserver – stellt eine unterstützte Hostingkonfiguration dar.

Wenn Kestrel als Edgeserver ohne Reverseproxyserver verwendet wird, wird das gemeinsame Nutzen derselben IP-Adresse und desselben Ports für mehrere Prozesse nicht unterstützt. Wenn Kestrel für das Lauschen an einem Port konfiguriert ist, verarbeitet Kestrel den gesamten Datenverkehr für diesen Port unabhängig von den Host-Headern der Anforderungen. Ein Reverseproxy, der Ports freigeben kann, kann Anforderungen an Kestrel über eine eindeutige IP und einen eindeutigen Port weiterleiten.

Auch wenn kein Reverseproxyserver erforderlich ist, kann die Verwendung eines solchen empfehlenswert sein.

Für einen Reverseproxy gilt Folgendes:

  • Er kann die verfügbar gemachten öffentlichen Oberflächen der von ihm gehosteten Apps einschränken.
  • Bietet eine zusätzliche Ebene der Konfiguration und der umfassenden Cybersicherheit.
  • Er lässt sich besser in die vorhandene Infrastruktur integrieren.
  • Vereinfacht die Konfiguration von Lastenausgleich und sicherer Kommunikation (HTTPS). Nur der Reverseproxyserver benötigt das X.509-Zertifikat für die öffentlichen Domänen. Dieser Server kann mit den Servern der App im internen Netzwerk über einfaches HTTP oder HTTPS mit lokal verwalteten Zertifikaten kommunizieren. Internes HTTPS erhöht die Sicherheit, bringt aber auch erheblichen Mehraufwand mit sich.

Warnung

Das Hosting in einer Reverseproxykonfiguration erfordert Hostfilterung.

Zusätzliche Ressourcen

Konfigurieren von ASP.NET Core zur Verwendung mit Proxyservern und Lastenausgleich