Is reverse proxy actually needed on ASP.NET core?

Question

We're wondering if reverse proxy is actually required for most use cases and would appreciate additional information.

The Kerstel/Nginx documentation claims:

Kestrel is great for serving dynamic content from ASP.NET Core. However, the web serving capabilities aren't as feature rich as servers such as IIS, Apache, or Nginx. A reverse proxy server can offload work such as serving static content, caching requests, compressing requests, and HTTPS termination from the HTTP server. A reverse proxy server may reside on a dedicated machine or may be deployed alongside an HTTP server. (See source)

Could anyone please share some insights if this is actually relevant nowadays?

On our use case, we use Docker instances with external load balancing (AWS ALB). Each docker instance has both Nginx and our ASP.NET Core application running. We couldn't figure out the exact benefits of using Nginx.

1. Serving static content As we're using an external CDN (AWS CloudFront), I assume static caching doesn't really have any actual benefits, does it?

2. Caching requests I believe this is the same as serving static content, as dynamic content isn't cached on most scenarios (on our use case - all scenarios).

3. Compressing requests ASP.NET Core has a response compression middleware, however - it claims "The performance of the middleware probably won't match that of the server modules. HTTP.sys server server and Kestrel server don't currently offer built-in compression support.". Perhaps some benchmarks could be created to validate this claim. https://learn.microsoft.com/en-us/aspnet/core/performance/response-compression?view=aspnetcore-2.2

4. HTTPS termination from the HTTP server I assume most clients having load balancers can skip this part, as HTTPS termination can be done on the load balancer if needed.

Thanks! Effy

Dubonnet

it is usually more practical to run applications behind nginx because you don't have to configure the same things twice if you have more than one application running. Someting like encryption certificates and automatic rewriting to https is very practical to do in nginx so you don't have to do it in your app – Nations

Thanks Johan, we're using a single application architecture (single SaaS solution). Encryption certificates could also be configured on ASP.NET core. Automatic re-writing to HTTPs is great, but we actually do that on on CDN (AWS CloudFront) anyway. – Dubonnet

No, you no longer need a reverse proxy. – Kursh

Thanks David, we'll consider stop using Nginx then. – Dubonnet

Hi @davidfowl, do you have any information regarding compression using ASP.NET Core vs. nginx? According to Microsoft documentation (learn.microsoft.com/en-us/aspnet/core/performance/…), response compression should be avoided, and Nginx seems to be preferred. Are those docs out of date? Thank you for your help! – Dubonnet

Answer 1

This documentation does not tell you that you „should“ run ASP.NET Core / Kestrel behind a reverse proxy, just that advanced scenarios can benefit from one since Kestrel does not have some features that other web servers may have.

If you don‘t have a use for an additional nginx reverse proxy then you don‘t have to use one.

E.g. Kestrel only recently adopted APIs to change certain connection parameters on the fly without requiring a restart - this is helpful for switching certificates acquired via ACME (e.g. Let‘s Encrypt service).

It highly depends on the system architecture if a reverse proxy is needed or not, but you don‘t have to deploy one if you don‘t require a specific feature.

Reflexive

Thanks Martin, We've actually stopped using reverse proxy already, didn't run into any issues in the progress. – Dubonnet

Thought so, just didn't want to see this remain unanswered :) – Reflexive

@EffyTeva Have you notice any performance degradation since you stopped using Nginx? Have you run any load test on your applications and compared the results? – Huth

@SohailAhmed, no, we didn't run into any performance issues since removing Nginx so far. We ran some specific load test, but didn't see any major differences. – Dubonnet