ASP.NET Core的Kestrel是否适合生产？公开部署安全性存疑求解

首先直接给你结论：Kestrel完全可以用于生产环境，但不建议直接暴露在公网，那些说法其实是有历史背景和适用场景的，咱们拆开说：

1. "Kestrel公开暴露应用时不安全"的说法是怎么来的？ #

这个说法主要源于早期的Kestrel版本（比如ASP.NET Core 1.x），当时它确实缺少一些面向公网的安全特性：

• 没有内置的请求限流、防DDOS的基础机制
• 不支持多站点托管
• 安全配置选项相对简陋

但到了ASP.NET Core 2.0，Kestrel已经做了大幅增强：

• 原生支持HTTPS，且强制HTTPS的配置更简便
• 增加了请求筛选（比如限制请求大小、请求路径）
• 支持基于SNI的多站点HTTPS托管

不过话说回来，即使是2.0+的Kestrel，直接暴露在公网依然不是最优选择——因为它的定位是「应用服务器」，而非「面向公网的前端Web服务器」，它缺少反向代理服务器（比如IIS、Nginx）自带的成熟安全防护：比如IP黑名单/白名单、负载均衡、静态文件高效缓存、集成防火墙规则、更精细的请求过滤等。

2. Kestrel适合生产环境吗？当然适合！ #

你现在用的「IIS作为反向代理+Kestrel处理应用请求」，恰恰是微软官方推荐的生产部署架构：

• IIS负责对接公网，处理所有前端的安全校验、请求转发、静态资源托管
• Kestrel专注于处理ASP.NET Core应用的业务逻辑，发挥它高性能的优势

这种架构兼顾了安全性和性能，完全符合生产环境的要求。

3. "仅适用于内部应用"的说法不准确 #

Kestrel并非只能用于内部应用：

• 如果是内部无公网访问的服务，直接部署Kestrel是完全没问题的，不用额外加反向代理，节省架构复杂度
• 如果是面向公网的应用，只要搭配了反向代理（比如你已用的IIS），Kestrel作为后端应用服务器，完全可以稳定运行在生产环境

最后给你的小提醒 #

既然你已经部署在IIS+Kestrel的架构上，那其实不用太担心安全性——只要把IIS的安全配置做好（比如开启请求过滤、配置HTTPS、限制IP访问范围等），Kestrel作为后端不会直接暴露给公网，是非常安全的生产部署方式。

内容的提问来源于stack exchange，提问作者Hemanth Bidare