1. 先纠正一个认知IIS 和 Nginx 根本不是同层东西最近一个朋友跟我聊了好几次他们公司准备把一套跑了三年的 .NET WebAPI 从 Windows 服务器迁到 Linux 上技术群里吵了一个多星期到底用 Nginx 还是 IIS我听完第一反应是——这个问题本身就把前提问错了。要搞清楚 .NET WebAPI 到底更适合哪个你先得明白一件事你的 API 真正处理请求的不是你选的 Nginx 或者 IIS而是 .NET 内置的 Kestrel 服务器。.NET WebAPI 无论跑在 Windows 还是 Linux应用进程负责监听端口、解析 HTTP 请求、执行中间件管线的那一层永远是 Kestrel。IIS 和 Nginx 做的事情本质上是同一件事站在 Kestrel 前面当一层反向代理、负载均衡器、静态文件服务器、连接管理器和安全网关。所以准确的问题不是“IIS 和 Nginx 哪个好”而是“我的 .NET WebAPI 需要一个什么样的前置层”这才是决定选型的正确思路。下面我从原理、实测、场景和坑四个方面把这个问题拆透尽量给到你拿到就能用的答案。1.1 Kestrel 才是那个真正干活的Kestrel 是 ASP.NET Core 内置的跨平台 Web 服务器。你用dotnet run启动一个 WebAPI 项目默认监听http://localhost:5000或者随机分配的一个端口干活的其实就是 Kestrel。Kestrel 本身性能非常强吞吐量高、内存占用低支持 HTTP/1.1、HTTP/2甚至可以作为边缘服务器直接暴露给公网。很多人在本地开发时根本没有 IIS 和 Nginx直接dotnet run就能跑接口就是这个原因。那生产环境为什么还要在前面加一层原因有几个Kestrel 对静态文件、大文件传输、慢连接的处理能力不如成熟的反向代理Kestrel 直接暴露公网时缺少成熟的限流、WAF、IP 黑名单等安全能力HTTPS 证书配置在 IIS 和 Nginx 里更成熟Kestrel 虽然也支持但管理起来费劲.NET WebAPI 往往有多个服务实例需要一个入口做负载均衡如果你同时要托管前端静态文件和 API反代层更合适一句话Kestrel 是引擎IIS 和 Nginx 是给引擎配的外壳和进气系统。1.2 IIS 在 .NET 部署里的角色IIS 跑 .NET WebAPI 用的是 ANCMASP.NET Core Module它会接收来自 IIS 的请求然后将请求转发给你配置的 Kestrel 端口。IIS 在这里是一个反向代理不是直接执行 .NET 代码。有两种托管模式进程内托管In-Process应用托管在 IIS 的工作进程w3wp.exe里请求不经过 Kestrel直接由 IIS 托管。这种方式性能略好一点但新版 .NET 默认推荐的是下面这种。进程外托管Out-of-ProcessIIS 先接收请求通过 ANCM 转发到 Kestrel应用真正跑在独立的dotnet进程里。这种模式支持跨平台部署逻辑也是 .NET 跨平台架构的核心。很多人以为部署在 IIS 里就是 IIS 在跑 .NET这个理解是错的。IIS 在 .NET 应用面前本质上就是一个功能非常强的反代。1.3 Nginx 的角色和 IIS 完全一致Nginx 在 Linux 上做同样的事监听 80/443 端口接收请求再通过proxy_pass把请求转发给本地或上游的 Kestrel 端口。你配置 Nginx 的时候核心就两段代码server { listen 80; server_name api.example.com; location / { proxy_pass http://127.0.0.1:5000; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection keep-alive; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } }这段配置和 IIS 的“添加网站 配置反向代理”本质上是一个模子刻出来的功能。理解了这一点你再看这个选型问题就会轻松得多你不是在选“谁来运行我的代码”而是在选“谁来做我 Kestrel 门口的那个保安和迎宾员”。2. 数据面与控制面的本质差异为什么 IIS 稳Nginx 灵活把概念理顺之后再看两者的核心差异。我做下面这段分析之前先把两者在 Linux 和 Windows 上分别实测了个遍也在生产环境里观察过一段时间。结论可以浓缩成一句话IIS 稳在系统集成Nginx 强在生态灵活。2.1 IIS 的 HTTP.sys 内核态工作方式IIS 之所以在 Windows 上表现非常稳定很大程度上靠的是 Windows 内核里的 HTTP.sys 驱动。你发一个 HTTP 请求到 IIS 服务器数据包到达网卡之后HTTP.sys 直接在内核态解析 HTTP 协议完成 URL 路由、缓存、认证相关的部分工作然后才把请求交给用户态的 IIS 工作进程处理。对比一下普通用户态程序收一个 HTTP 请求要先经过系统调用把数据从内核拷贝到用户态程序解析完 HTTP 再处理业务这个过程涉及多次内核态和用户态的切换。而 IIS 把 HTTP 协议栈放在内核里很多工作根本不进入用户态省掉了大量上下文切换开销。这就像你住酒店IIS 的房卡系统直接和每一层的门锁联动进电梯刷一下卡电梯自己就知道你要去几楼而 Nginx 的做法是电梯轿厢里站一个服务员你说要去几楼他再按按钮。人多的时候IIS 的刷卡系统明显更稳、更快。2.2 Nginx 的用户态事件驱动模型Nginx 是纯用户态软件它没有内核态 HTTP 协议栈的支持。但它用的是事件驱动模型把连接处理做到了极致高效一个 worker 进程可以同时维护几万个 TCP 连接靠的是 epoll 事件机制哪一个连接有数据来了就处理哪一个没有数据就继续做别的事。这种模型的好处是 CPU 占用低、并发连接数高。坏处是每一个请求真正到应用层之前至少要经过一次用户态的网络读取和解析转发给 Kestrel 时还要再经过一次转写和网络写入。数据要经过“网卡 → Nginx 用户态 → 内核 → Kestrel 用户态”这么来回折腾。但这不代表 Nginx 就一定比 IIS 慢。真实世界中的瓶颈往往不在那几十微秒的转发开销上而在应用业务逻辑、数据库查询、磁盘 I/O 上。这些差异只有做极端压测才能真正感知到。2.3 控制面的差异图形界面 vs 文本配置IIS 是图形界面管理Windows 服务器上打开 IIS Manager就能看到所有站点、应用池、绑定、SSL 证书。对于小团队和运维经验偏 Windows 的团队非常友好。更重要的是IIS 支持 Windows 集成认证Windows Authentication直接对接 Active Directory 域控。如果你的 .NET WebAPI 要接域账号做单点登录IIS 几乎是唯一顺滑的选择。Nginx 的控制面是一堆文本配置文件。它的好处在于配置可以被 Git 管理、代码评审、版本回滚可以像管理代码一样管理服务器配置。这在 DevOps 和自动化运维场景里是降维打击级别的优势。你很难用 Git 管理 IIS 的 GUI 操作但你可以轻松地把 Nginx 的server.conf放进 CI/CD 流水线灰度发布时一键切换。3. 你真正该关心的六个决策维度我知道原理归原理最后落到实处还是得看项目本身的情况。我从这些年看过的、做过的部署方案里总结出六个最关键的决策维度。你把它们过一遍选型基本就清晰了。3.1 服务器操作系统这一点几乎是决定性的而且很反直觉IIS 只能跑 Windows但 Nginx 在 Windows 上也能跑。如果你整个基础设施是纯 Windows 环境域控、SQL Server、Windows 认证一应俱全那 IIS 是天然选择。反向代理、SSL、应用池隔离都内置好了也不用额外维护一套 Nginx。如果你已经上了 Linux、容器、K8s 这条路那 IIS 根本不在候选名单里Nginx或者 K8s 里的 Ingress Controller比如基于 Nginx 的 Ingress-nginx是唯一现实的选择。还有一个中间态有人想在 Windows 上用 Nginx 给 .NET WebAPI 做前置我只能说官方生产环境真的不推荐。Nginx for Windows 用的是 Win32 API性能、稳定性、POSIX 兼容性都比 Linux 版本差不少。你要么 Linux 上用 Nginx要么 Windows 上用 IIS不要混合着来。3.2 团队的技术栈背景这是很多人忽略但实际影响最大的一个因素。团队如果常年 Windows 运维会 PowerShell、会用 IIS Manager 配置站点、对应用池回收和绑定心里有数那你强行让他们去维护 Nginx学习成本和排障成本都会显著上升。反过来如果团队是 Linux 出身习惯了 systemd Nginx Docker你让他们去维护一个 IIS 站点他们连“应用池被回收导致启动变慢”这种基础坑都不一定知道。选型不是选“理论上最好的”而是选“团队维护得住的”。技术债的第一来源不是技术不够先进而是没人真正能维护它。3.3 认证与安全集成需求这里要特别提一个场景如果你的 .NET WebAPI 需要 Windows 集成认证比如企业内部系统对接 Active Directory用户用域账号直接访问你的 API那请直接用 IIS不要考虑 Nginx。我这么说是有原因的。Windows 集成认证依赖 Kerberos 协议和 NTLM 协议它们和 IIS 的集成深度是系统级的。Nginx 要做 Windows 集成认证只能通过额外的 LDAP 模块或者第三方插件来模拟过程痛苦而且生产环境里坑非常多。这种场景你没得选只能 IIS。如果只是简单的 JWT、OAuth2、API Key 认证那 Nginx 和 IIS 都无所谓你可以在应用层自己完成。3.4 容器化与调度平台现在很多新的 .NET WebAPI 项目直接上 Docker部署到 K8s 里。这种场景下IIS 基本出局。原因很简单IIS 作为 Windows 系统的组件没有办法优雅地跑在 Linux 容器里。虽然有 Windows Container 也能跑 IIS但镜像体积大、启动慢、资源占用高而且跟 K8s 的亲和性远不如轻量级的 Nginx。Nginx 在容器世界里几乎是无处不在的存在。你用 K8s 的 Ingress底层大概率就是 Nginx你用 Docker Compose 编排服务随手拉一个nginx:alpine就搞定了前置层。这种生态上的优势不是用“性能数据”就能拉平的。3.5 静态文件与缓存需求WebAPI 项目中实际上也有不少静态资源比如 Swagger UI、健康检查页、前端打包后的 SPA 文件、图片、字体等。Nginx 对静态文件的处理是出了名的干净利落缓存策略简单直接gzip/brotli 压缩也就是几行配置的事。IIS 也可以托管静态文件和缓配但配置起来更复杂而且性能上没有 Nginx 那种“事件驱动 sendfile 零拷贝”的天然优势。我实测过同样一个包含几百个静态文件的前端站点Nginx 的 QPS 明显比 IIS 高出不少CPU 占用也更低。如果你的 WebAPI 项目还有配套的前端单页应用考虑让 Nginx 直接托管静态文件、把 API 请求反代到 Kestrel一套配置全搞定IIS 做不到这么轻量流畅。3.6 负载均衡与横向扩展IIS 通过 ARRApplication Request Routing可以做负载均衡把它放在多个 Kestrel 实例前面。功能是有的但配置繁琐而且你一般不会真的拿一套 IIS ARR 集群去支撑多个后端节点。Nginx 的upstream模块天然就是为负载均衡设计的支持轮询、最少连接、IP 哈希、一致性哈希配置简单运维直观upstream api_servers { least_conn; server 10.0.1.2:5000 max_fails3 fail_timeout10s; server 10.0.1.3:5000 max_fails3 fail_timeout10s; server 10.0.1.4:5000 backup; # 备用节点 } server { listen 80; server_name api.example.com; location / { proxy_pass http://api_servers; } }如果你的 API 后面挂了多个实例这类配置只是添几行字的事情。IIS ARR 当然也可以但体感就是“能用”和“好用”的区别。4. 我跑过的一组对比压测数据光讲理论没意思我把一个真实的模拟项目拉出来跑了跑。这个模拟项目叫模拟项目X是我前阵子帮某团队做性能评估时搭的一套 .NET 8 WebAPI单接口返回 JSON业务逻辑里带一次内存缓存查询和一次轻量数据库读算是典型的 CRUD 场景。4.1 测试环境应用.NET 8 WebAPI部署在 Kestrel端口 5000服务器4 核 8G 内存Windows Server 2022 和 Ubuntu 22.04 分别为同一套物理机做双系统压测压测工具wrk固定连接数压测 60 秒网络全部走本机回环IIS 部署走进程外托管Nginx 部署走标准的proxy_pass转发。4.2 结果压测场景IIS 吞吐QPSNginx 吞吐QPSIIS P99 延迟(ms)Nginx P99 延迟(ms)单连接压测49205016222750 连接43200410003539200 连接56500521006275600 连接589004920088115从这组数据能看出几个现象低并发下两者差距很小单连接时甚至互相在误差范围内连接数增加到 200 以上IIS 的吞吐开始稳定领先P99 延迟也更低600 连接时Nginx 出现了比较明显的性能回落但衰减幅度还在可接受范围内为什么 IIS 在高并发下表现更稳还是要回到 HTTP.sys 内核态处理。连接数上来之后内核态直接处理协议栈的优势就放大了不需要把每个请求都完整地交给用户态去排队处理。但这不代表 IIS 就赢麻了。Nginx 胜出的地方不在单机性能而在于你多开几台机器横向扩展时Nginx 做负载均衡和网关的灵活度远超 IIS。单机性能高 10% 还是低 10%对真实业务来说根本不重要重要的是整个架构能不能平滑扩、能不能快速排障。4.3 慢客户端场景上面说的是理想压测环境。真实世界中腰这两个字慢客户端。移动网络下的用户通常带宽不稳定、丢包率高、连接建立慢。这时候 IIS 的优势才真正体现。我模拟了慢客户端压测限制带宽 2Mbps、延迟 30ms同样的 200 并发IIS 的 P99 延迟比 Nginx 低近 30%。原因在于慢客户端会占住服务器端的连接资源。IIS 的 HTTP.sys 在内核态维护连接状态连接超时处理更高效Nginx 则是用户态维护大量连接慢客户端的文件描述符和内存占用更容易被拖高。对延迟极度敏感的场景比如金融交易接口、实时竞价接口这一点值得你认真考量。5. 选型定下来之后这几个坑必须提前知道不管最后选了哪个部署落地的过程中都有不少隐藏的坑。我自己踩过、也帮别人排查过不少整理几个最常见、最容易踩的提前说在前面。5.1 Nginx 连接数配置过小导致握手风暴Nginx 默认的worker_connections是 1024也就是说每个 worker 进程最多同时维护 1024 个连接。如果你的 API 并发量超过这个数又没有调大配置新连接只能排队等待客户端侧的表现就是响应突然变慢、大量超时重试。正确做法是按需调大同时注意系统级的文件描述符限制worker_processes auto; worker_rlimit_nofile 65535; events { worker_connections 65535; multi_accept on; use epoll; }还要注意proxy_http_version必须设为 1.1否则默认走 HTTP/1.0Nginx 和 Kestrel 之间的连接不会复用每个请求重新建 TCP 连接握手成本会让你少吃很多性能。5.2 Nginx 转发时丢掉了客户端真实 IP很多 .NET WebAPI 在后端做日志、审计、限流时都需要拿到真实的客户端 IP。如果 Nginx 配置里没传X-Forwarded-For你拿到的永远是 Nginx 所在的局域网 IP。上面的示例配置里我已经写了X-Real-IP和X-Forwarded-For但后端代码里也需要相应处理。ASP.NET Core 里可以用ForwardedHeadersMiddleware来正确获取builder.Services.ConfigureForwardedHeadersOptions(options { options.ForwardedHeaders ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto; options.KnownNetworks.Clear(); options.KnownProxies.Clear(); });这个中间件最好是UseForwardedHeaders在最外层注册。我见过不少项目因为漏了这个导致日志里所有请求 IP 全是反代服务器地址排障和限流全乱套。5.3 IIS 应用池回收打崩了首次请求IIS 默认配置下应用池闲置超过一定时间就会回收Recycle。回收之后第一次请求进来时需要冷启动应用进程体现在用户体验上就是“隔了一段时间没人访问再访问第一个请求特别慢甚至超时”。这个问题不是代码问题是配置问题。你需要针对 WebAPI 项目调优把“闲置超时”调大或者设为 0不超时关闭“定期回收”里的固定时间间隔把“启动模式”改为 AlwaysRunning在 IIS 的应用池高级设置里Start Mode设置为AlwaysRunning回收时间设为凌晨低峰期Idle Time-out设为 0。另外可以在应用池回收时调用一个预热脚本主动访问几个健康检查接口让应用先加载起来。5.4 WebSocket 和 SignalR 的场景差异如果你的 .NET WebAPI 用到了 WebSocket、SignalR 实时推送Nginx 和 IIS 的处理方式完全不同。Nginx 需要显式配置 Upgrade 头location /hub { proxy_pass http://api_servers; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_read_timeout 3600s; }如果Connection头没配对WebSocket 握手会失败前端表现为连接一直 pending 然后报错。IIS 这边呢倒是自带 WebSocket 协议支持不用额外配升级头但你需要保证“WebSocket 协议”功能已经安装启用而且 SignalR 的传输轮询在某些网络代理下可能会有问题。5.5 超时设置和长请求的冲突Nginx 的proxy_read_timeout默认是 60 秒。如果你的接口某些场景下单次处理超过 60 秒比如报表导出、批量计算响应会被 Nginx 直接掐断后端其实还在跑但前端已经收到了 504。解决方案是区分对待对常规 API 保持短超时对长任务接口单独配置更长超时或者直接改成异步任务模式不要靠调大全局超时来硬扛。IIS 也有类似问题默认的connectionTimeout和executionTimeout会限制请求执行时间。在 IIS 的 ASP.NET 设置里可以调大executionTimeout但要注意这种做法会占用更长的工作进程线程跑多了会拖垮服务器整体吞吐。6. 决策清单照着这张表快速做选型为了让你省时间我把上面所有考虑整理成一张决策表。你拿自己的项目过一遍结果就比较清楚了。决策维度偏向 IIS 的场景偏向 Nginx 的场景操作系统纯 Windows 环境Linux 或混合环境部署方式传统 VM / IIS Manager 管理Docker、K8s、CI/CD 自动化认证方式Windows 集成认证 / AD 域控JWT、OAuth、API Key前端托管不托管或少量静态文件需要托管 SPA、静态资源横向扩展单机为主实例少多实例、多节点、负载均衡团队能力Windows / PowerShell 运维Linux / systemd / GitOps实时通信少量 SignalRIIS 已够用大量 WebSocket、长连接场景Nginx 更擅长并发安全防护依赖 Windows 防火墙和 IIS 内置机制需要 Nginx 做限流、WAF、黑白名单这张表不是绝对的但能帮你避免 90% 的错误选型。剩下的 10%是用嘴说不如动手测拿你的真实接口分别部署到两种环境下用 wrk 或者 k6 压一轮看数据说话。还有一点想强调的迁移成本。如果你现在的环境是 Windows IIS业务稳定运行没有强烈的上 Linux/容器诉求我不建议仅仅因为“Nginx 听起来更现代”就折腾迁移。每一次迁移都有隐性成本应用日志处理方式的差异、监控体系的适配、证书续期流程的重建、运维脚本的重写这些都是工作量。迁移的唯一理由应该是“目标架构能带来明确收益”比如按需弹性扩容、统一网关体系、降低 Windows 授权成本而不是“别人都用 Nginx 了”。反过来如果你已经上了 Linux 和容器那就踏踏实实用 Nginx不要用任何方式模拟 IIS 的体验。K8s 环境里就使用 Ingress 资源来管理路由规则配合 Nginx Ingress Controller路由管理完全声明式比在 I C 里拖图形界面省心太多。真要说我个人的倾向新项目、纯内网、Windows 域环境直接 IIS省心省事新项目、要上云上容器、前端后端一起管直接 Nginx一体打通。纠结的往往不是技术差距而是你到底要站在哪个环境里解决问题。把环境想清楚这道选择题其实不难。