Welcher Reverse Proxy für ASP.NET Core Apps?

_RM_

Cadet 4th Year
Registriert
Juli 2018
Beiträge
122
Hallo Forum,

derzeit bastle ich an einer ASP.NET Core Blazor Server App und einer ASP.NET Web API, die ich demnächst mal testweise auf meinem Debian VPS bereitstellen möchte.

Die Apps laufen aktuell und standardmäßig mit Kestrel. Abgesehen von den verwendeten Ports habe ich nichts geändert. Zwar könnte man Kestrel auch für produktiv direkt ins Internet hängen, aber auch Microsoft empfiehlt einen Reverse Proxy vorzuschalten, da das mehrere Vorteile bietet (bessere Sicherheit durch zusätzlichen Layer, mehr Konfigurationsmöglichkeiten, Load Balancing, Zertifikat für TLS nur im Proxy notwendig, ...). Nicht alle Vorteile werden für mich relevant sein, dennoch vertraue ich z.B. IIS, Apache oder nginx mehr als dem mir doch recht unbekannten Kestrel. Da in Zukunft auch noch mehr Apps dazukommen sollen, wäre es auch gut, wenn ich das Zertifikat nur im Reverse Proxy hinterlegen müsste.

Nun frage ich mich, welche Software ich als Reverse Proxy verwenden sollte. Ich brauche den Reverse Proxy für Windows 10 (lokale Entwicklung) und Debian 10 (VPS, Produktiv). Im Endeffekt kommen vermutlich nur Apache oder nginx in Frage. Mit Apache habe ich durch PHP-Entwicklung schon Erfahrung, aber mit Reverse Proxies hatte ich bisher noch gar nichts zu tun. nginx hingegen ist mir völlig unbekannt, aber ich hab den Begriff schon sehr oft gehört^^.

Was meint ihr dazu und könnt ihr mir Für und Wider (aus eurer Erfahrung) zu den beiden oder auch weiteren nennen?
 
Zuletzt bearbeitet:
Unter Linux geht nginx gut für .NET core. Gibt genug Anleitungen. Keine Erfahrung mit nginx unter Windows
 
  • Gefällt mir
Reaktionen: _RM_
Tornhoof schrieb:
Unter Linux geht nginx gut für .NET core. Gibt genug Anleitungen. Keine Erfahrung mit nginx unter Windows

nginx unter Windows funktioniert ebenfalls gut, Service kann via nssm eingerichtet werden.
 
  • Gefällt mir
Reaktionen: _RM_
Hab nginx auf Windows eingerichtet und soweit funktioniert das jetzt mal wie gewünscht.

Es gab nur ein Problem mit
limit_req zone=one burst=10 nodelay;
das so in der Doku stand. Wenn man das in die conf gibt, funktioniert die WebSockets-Verbindung nicht mehr zuverlässig.
 
Zurück
Oben