Linux环境下不使用反向代理直接运行Kestrel是否仍被推荐？

结论是：仍然强烈推荐在Nginx这类反向代理后运行Kestrel，即使Kestrel近年功能有所完善，反向代理能解决的核心痛点依然无法被替代，具体原因如下：

• TLS管理更高效：Kestrel虽支持TLS，但Nginx在证书自动续期、TLS版本/加密套件调优上更成熟。比如用Let's Encrypt证书时，Nginx能通过certbot一键配置自动续期，不用修改.NET项目配置或代码；多域名证书管理也比每个Kestrel实例单独配置便捷得多。
• 负载均衡与流量调度：如果你的服务是多实例部署，Nginx可轻松实现负载均衡，还能按请求路径分流到不同服务——这些能力Kestrel本身并不具备，得依赖额外组件才能实现。
• 静态资源与压缩优化：Nginx处理静态文件（JS、CSS、图片）的性能远高于Kestrel，还能直接配置gzip/brotli压缩，无需在.NET中编写额外逻辑，让Kestrel专注处理业务请求。
• 安全防护更全面：Nginx可快速配置请求频率限制、IP黑白名单、基础WAF规则，拦截恶意请求（如SQL注入、XSS的初步过滤），这些功能若用Kestrel实现，需要依赖第三方中间件或自定义开发，成熟度和易用性都不如Nginx。
• 端口权限合规性：Linux下非root用户无法监听80/443这类低端口，Kestrel直接运行要么用root（存在安全风险），要么做端口转发；而Nginx可通过root监听低端口，再转发到Kestrel的高位端口，既合规又安全。

微软当前文档虽未强制要求反向代理，但也保留了Nginx反向代理的部署方案——Kestrel的定位是高性能应用服务器，而非全能的边缘服务器，搭配反向代理能让生产环境的服务更稳定、更易维护。

内容的提问来源于stack exchange，提问作者M. Akar