简介：这套仅1.01MB的软件包，面向希望在Windows下摆脱IIS束缚、快速搭建轻量级ASP服务器的网站管理员与开发者，核心是“小旋风”ASP服务器绿色版。压缩包共3个文件，其中exe为服务器主程序，可直接运行并监听HTTP请求；htm与css构成自带的使用说明页面，标注了基本配置和常见操作，便于零基础用户上手部署。该资源已有433人学习/下载，特别适用于本地代码调试、小型企业站发布、教学演示等场景，也适合刚接触Web服务配置的初学者练手。相比官方IIS，小旋风主打免安装、低内存占用和极简配置，让非专业用户也能在几分钟内完成Web环境搭建；其内置的ASP解析能力，兼容老式ASP站点的迁移需求，不过若要使用ASP.NET或高并发生产环境，仍需换用更完整的方案。对追求效率和新手友好的人群来说，这份精简工具包提供了立即可用的替代选择。
1. 为什么大家都在找 IIS 的替代品：先想清楚你换掉它到底为了什么
我最早接触 IIS 是在某公司维护一台老旧的 Windows Server，上面挂着一个 ASP.NET 写的内部管理系统，跑了好几年一直没出大问题。真正让人想换掉 IIS 的，不是它托管 ASP.NET 的能力，而是它的“重”和“黑匣子”属性：IIS 管理器的配置项密密麻麻，URL 重写、身份验证、MIME 类型、应用程序池隔离，每一项都像一门小课；出了问题看日志，还得先分清是 IIS 的、ASP.NET 的还是数据库的。后来接手一个跨平台项目，需要在 Linux 服务器上部署同一套 API 服务，IIS 直接就不适用了，这成了团队讨论“代替 iis 的软件”的直接导火索。
这篇文章要聊的，就是当你想把 IIS 从生产环境里替下来时，怎么选替代品、怎么迁、参数怎么设、最容易在哪翻车。我会按自己实际切换的经验来写：先讲清楚替代 IIS 的几种路线和适用边界，再给你一套可以在本地完整复现的最小迁移步骤，最后把调优和踩坑的部分单独拿出来说。适合手里正维护着 IIS 服务、被配置复杂度或跨平台需求逼着做技术选型的从业者，也适合刚入门、想理解“Web 服务器到底是怎么被替换的”的开发者。
2. 替代 IIS 的路线不止一条：先把 Kestrel、Nginx 和反向代理的角色关系理清
2.1 IIS 到底在做什么：静态文件、反向代理和进程管理三合一
IIS 本质上是一个“三合一”的 Web 服务器：它负责监听 HTTP 请求、解析并返回静态文件（HTML、JS、CSS），也负责把动态请求交给 ASP.NET 运行时处理，同时还承担了应用程序池的进程隔离与回收职责。换句话说，IIS 既是你网站的前端网关，又是后端应用进程的托管容器。
这就导致一个尴尬：当我们说“代替 iis 的软件”时，真实意思是代替它的三份工作。如果只是托管 ASP.NET Core 应用，那 .NET 自带的 Kestrel 就已经是替代品；但如果你还需要静态文件服务、HTTP 头处理、请求日志、负载均衡、HTTPS 终结这些网关能力，Kestrel 一个人干不了，得让 Nginx 或 YARP 这类组件站在前面。如果还没理清这层分工，后面无论选哪个方案都会踩坑。
2.2 Kestrel：微软官方推荐的 ASP.NET Core 托管容器，但它是“应用服务器”而非“完整 Web 服务器”
Kestrel 是 ASP.NET Core 内置的跨平台 Web 服务器，它基于 libuv 演进而来（现在底层是自己实现的 Socket 处理），性能高、内存占用低，而且能在 Windows、Linux、macOS 上跑。如果你只是要“把 ASP.NET Core 应用跑起来”，Kestrel 其实是比 IIS 更自然的选项——因为发布 ASP.NET Core 应用时，程序本身就自带 Kestrel，根本不需要额外安装任何服务器软件。
但 Kestrel 的短板也很明显：它不擅长同时托管多个应用，也没有像 IIS 那样的一站式管理界面，静态文件性能不如 Nginx 调优后好，且默认不处理 HTTP 头里的某些安全字段。所以在生产环境里，常见做法是用 Kestrel 作为后端，前面架一个 Nginx 做反向代理来补足网关能力。这个组合其实就已经完成了“代替 IIS”这件事——把 IIS 拆成了两个开源组件。
2.3 Nginx：作为反向代理和静态文件服务器，是替换 IIS 体验差距最小的选择
Nginx 是目前替代 IIS 时提到最多的软件，它的优势在于：配置语法简单清晰、并发能力强、静态文件处理效率高、内存占用远小于 IIS。用它替代 IIS 有两种常见场景：一种是 ASP.NET Core 应用发布后，用 Nginx 将请求代理给本机的 Kestrel；另一种是把原本 IIS 上托管的纯静态网站或 PHP 站点整体迁到 Nginx 上。
这两种场景的配置思路不同。前者核心是proxy_pass加upstream，后者核心是root和location块。很多从 IIS 切过来的人会犯一个典型错误：以为 Nginx 也像 IIS 一样“一个站点一个配置文件夹”，结果把一堆 server 块塞进一个文件，改一处重启全部。实际上 Nginx 的配置是按include拆分的，每个站点一个文件更利于维护。关于具体的 server 块写法，下一章我会直接给出可复用的配置。
2.4 别忘了 YARP 和 Caddy：代理层和自动 HTTPS 场景下的另外两个选项
除了 Nginx，还有两个值得纳入选型视野的替代品。YARP（Yet Another Reverse Proxy）是微软开源的 .NET 反向代理组件，它最大的价值是让你用 C# 代码配置代理规则，适合团队本来就用 .NET、想在代理层做复杂路由或中间件逻辑的场景。Caddy 则是另一个 Web 服务器，它的杀手锏是自动申请和续期 HTTPS 证书，配置比 Nginx 还简洁，但生态和第三方模块数量不如 Nginx 丰富。
这三个选项怎么选？我的判断标准是：如果团队以 .NET 为主、希望代理层和业务代码用同一种语言维护，选 YARP；如果追求配置简单、自动 HTTPS、托管个人项目或中小站点，Caddy 值得一试；如果目标是生产环境、高并发、静态文件和反向代理都要强，Nginx 仍然是稳妥首选。下面整个迁移过程我以 Nginx + Kestrel 为主线展开，因为这个组合覆盖了最多的实际生产场景。
| 替代方案 | 适合场景 | 主要短板 | 典型配置复杂度 |
|---|---|---|---|
| Kestrel 单独使用 | 内部 API、开发环境、容器内运行 | 无静态文件优化、无管理界面 | 低 |
| Nginx + Kestrel | 生产环境 ASP.NET Core 站点 | 需要维护两套配置 | 中 |
| YARP | .NET 团队自建网关路由 | 文档和案例相对少 | 中高（涉及编码） |
| Caddy | 中小站点、自动 HTTPS 需求强 | 生态模块少、生产案例积累少 | 低 |
3. 从 IIS 迁到 Kestrel + Nginx：一次最小可复现的完整迁移过程
3.1 第一步：把 ASP.NET Core 应用发布为“框架依赖”或“独立部署”，先让 Kestrel 跑起来
从 IIS 切换的第一步，是把应用从 IIS 托管模式改成 Kestrel 自托管模式。发布方式有两种：框架依赖发布（FDD）要求目标机器装有对应版本的 .NET 运行时，体积小；独立部署（SCD）把运行时打包进发布目录，文件多、体积大，但目标机器不需要预装 .NET。我一般在生产环境用独立部署，省去服务器上装运行时的额外步骤，也避免运行时版本不一致的问题。
在开发机上发布，命令如下（以 .NET 8 为例）：
dotnet publish -c Release -r linux-x64 --self-contained true -o /tmp/myapp-release发布完成后，/tmp/myapp-release目录下会有一个可执行文件（比如MyApp），以及wwwroot静态资源目录。先在本地试着用 Kestrel 直接跑这个程序：
cd /tmp/myapp-release ./MyApp --urls "http://127.0.0.1:5000"此时如果控制台输出Now listening on: http://127.0.0.1:5000，说明 Kestrel 已经接管了 HTTP 请求。这个阶段先不要对外网开放——Kestrel 裸奔在公网有安全风险，后面让 Nginx 统一接收外部流量。
参数说明：-r linux-x64指定运行时标识，如果部署到 Windows 服务器就换成win-x64；--self-contained true表示独立部署，省略则默认框架依赖发布；--urls是给 Kestrel 指定监听地址和端口。这里用的 5000 端口是我惯用的本地测试端口，生产环境一般会换成 8080 或更高位端口，避免与系统服务冲突。
3.2 第二步：在 Linux 上安装 Nginx，并理解sites-available与sites-enabled的配置约定
接下来在 Linux 服务器上安装 Nginx。以 Ubuntu/Debian 系发行版为例：
sudo apt update sudo apt install nginx -y sudo systemctl enable nginx --now安装完成后，/etc/nginx/目录下有几个关键路径需要先认识：nginx.conf是主配置，sites-available用于存放每个站点的配置文件（但不会生效），sites-enabled里存放指向sites-available中文件的软链接（只有被链接到这里才生效）。这个设计和 IIS 的“站点+绑定”完全不同——很多人第一次接触时容易直接把文件丢进sites-available，然后发现 Nginx 根本没加载，就是因为忘了建立软链接。
验证 Nginx 是否正常启动：
sudo nginx -t sudo systemctl status nginxnginx -t会做配置语法检查，所有配置修改后都建议先跑这条命令再决定要不要重载。如果输出syntax is ok和test is successful，说明配置没有问题，再执行systemctl reload nginx让新配置生效。
3.3 第三步：配置反向代理将 80 端口转发给 Kestrel，附一份可直接抄的 server 配置
现在写核心的反向代理配置。我习惯在sites-available下为每个应用单独建文件，文件名叫应用名，内容如下：
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 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; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } location /static/ { alias /var/www/myapp/static/; expires 7d; } }这份配置有三个要点：第一，proxy_pass指向的是 Kestrel 监听的地址，必须保证和--urls参数一致；第二，X-Forwarded-For和X-Forwarded-Proto是为了让后端应用能拿到真实客户端 IP 和原始协议，否则 ASP.NET Core 里的Request.HttpContext.Connection.RemoteIpAddress会拿到 Nginx 的地址，日志里全是 127.0.0.1，排查问题时会非常头疼；第三，Upgrade和Connection "upgrade"是给 WebSocket 预留的，如果你的应用没有用到 WebSocket，去掉这两行也无妨。
配置完成后，把站点软链接到sites-enabled：
sudo ln -s /etc/nginx/sites-available/myapp.conf /etc/nginx/sites-enabled/myapp.conf sudo nginx -t sudo systemctl reload nginx到这里，外部请求访问 Nginx 的 80 端口时，会被转发到本机的 Kestrel 进程，整个链路就和之前 IIS 承载 ASP.NET 时的效果对齐了。
3.4 第四步：把 Kestrel 注册为 systemd 服务，确保服务器重启后应用自动拉起
这一步是从“手动跑通”到“生产可用”的关键一环。Kestrel 进程如果直接用命令行启动，SSH 断开或服务器重启它就没了。IIS 里的应用程序池有自动回收机制，而 Kestrel 的对应物就是 systemd 服务。
在/etc/systemd/system/myapp.service中写入：
[Unit] Description=My ASP.NET Core Application After=network.target [Service] WorkingDirectory=/opt/myapp ExecStart=/opt/myapp/MyApp --urls "http://127.0.0.1:5000" Restart=always RestartSec=10 Environment=ASPNETCORE_ENVIRONMENT=Production User=www-data [Install] WantedBy=multi-user.target保存后依次执行：
sudo systemctl daemon-reload sudo systemctl enable myapp.service --now sudo systemctl status myapp.service参数说明：WorkingDirectory必须指向发布目录，否则应用找不到wwwroot和配置文件；Restart=always让服务在异常退出时自动重启，RestartSec=10控制重启间隔，避免高频崩溃时把系统资源耗尽；User=www-data是 Nginx 的运行用户，让 Kestrel 和 Nginx 的权限保持一致，避免静态文件或日志目录的读写权限冲突。如果你发布目录在/opt/myapp而且属主不是www-data，记得先执行sudo chown -R www-data:www-data /opt/myapp。
4. 静态站点和旧版 ASP.NET 应用的替补方案：Nginx 独立托管与容器化迁移
4.1 纯静态站点：用 Nginx 的 root 指令接替 IIS 的物理路径绑定
如果你的 IIS 上托管的是纯静态网站——HTML、JS、CSS、图片、下载文件这类——那迁移到 Nginx 的难度非常低，连 Kestrel 都不需要。IIS 里配置站点时要指定“物理路径”，Nginx 里对应的是root指令。
一个最小静态站点配置：
server { listen 80; server_name static.example.com; root /var/www/static-site; index index.html; location / { try_files $uri $uri/ =404; } }这里的try_files $uri $uri/ =404的作用是：先按请求的 URI 查找对应文件，找不到再尝试作为目录找index.html，都没有则返回 404。这个写法几乎已经成了社区的标准模板，替换 IIS 时把root指到你原来的站点目录就能跑通。
需要注意的一个差异是：IIS 默认支持在 URL 里省略扩展名（比如访问/about自动匹配about.html），而 Nginx 默认不做这个。如果原站点的链接大量使用无扩展名的 URL，必须在location /里加try_files $uri $uri.html $uri/ =404;来兼容，否则迁移后一堆 404，用户会直接懵掉。
4.2 旧版 ASP.NET（非 Core）：不能直接用 Kestrel，优先考虑容器化或兼容层
如果 IIS 上跑的是旧版 ASP.NET（基于 .NET Framework 的 WebForms 或 MVC），事情就麻烦了。Kestrel 只支持 ASP.NET Core，它无法承载 .NET Framework 体系下的经典 ASP.NET 应用。这时候“代替 iis 的软件”的方案选择就变成两条路：一条是把老应用继续留在 Windows 环境，用另一个软件替代 IIS——这条路其实选择不多，商用的替代品和开源的兼容层（比如 Jexus 在某些场景下测试过）都存在维护和兼容性风险；另一条是逐步把老应用向 ASP.NET Core 迁移，成本高但一劳永逸。
我一般会给用户建议是：如果老应用规模不大、接口数量可控，优先做渐进式迁移——先拿一个模块迁到 ASP.NET Core 用 Kestrel 跑，验证稳定后再分批迁其他模块；如果应用太老、迁移成本不可控，就继续用 IIS 托管，但把它限制在内网或特定机器上，不主动扩大它的暴露面。这里不存在“零成本替换”的方案，凡是承诺老 ASP.NET 直接换服务器软件就能跑的，都要多留个心眼。
4.3 Docker 化部署：把 Kestrel 放进容器，彻底绕开服务器环境的差异
容器化是另一个绕开 IIS 环境差异（比如注册表、权限、全局程序集缓存）的思路。把 ASP.NET Core 应用打包成镜像后，无论底层是 Windows 还是 Linux，镜像里的运行环境都一样，Kestrel 在容器内监听端口，宿主机用 Nginx 做反向代理转发进容器。
一个常见的最小 Dockerfile 长这样：
FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS base WORKDIR /app EXPOSE 8080 FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build WORKDIR /src COPY ["MyApp.csproj", "."] RUN dotnet restore "MyApp.csproj" COPY . . RUN dotnet publish "MyApp.csproj" -c Release -o /app/publish FROM base AS final COPY --from=build /app/publish . ENV ASPNETCORE_URLS=http://+:8080 ENTRYPOINT ["dotnet", "MyApp.dll"]构建并运行：
docker build -t myapp:latest . docker run -d --name myapp -p 127.0.0.1:8080:8080 myapp:latest注意docker run里绑定的127.0.0.1:8080:8080：只让宿主机本机能访问 8080 端口，外部流量依然由 Nginx 代理进来。如果直接绑定0.0.0.0:8080:8080，等于把容器里的端口裸露到外网，绕过 Nginx 后，你就失去了集中的 HTTPS 管理和访问日志入口，而且 Kestrel 默认的一些限制头部大小的保护机制没有 Nginx 在前面兜底时，更容易被恶意请求打穿。容器化和裸 Kestrel 的差异要看清楚：容器解决的是环境一致性，但网关层的职责仍然要交给 Nginx 或类似组件。
5. 从 IIS 切到新方案后的避坑指南：5 个高频问题与对应排查路径
5.1 现象一：Nginx 返回 502 Bad Gateway，后端日志却显示 Kestrel 正常启动
这是迁移后最常见的问题，也是最容易让新手误判的。现象是浏览器访问域名得到 502，但 SSH 到服务器上看 Kestrel 进程还在，/var/log/nginx/error.log 里提示connect() failed (111: Connection refused) while connecting to upstream。
原因通常是 Nginx 里proxy_pass写的端口和 Kestrel 实际监听的端口不一致，或者 Kestrel 只监听了127.0.0.1，而 Nginx 用主机名解析到了::1（IPv6）。后一种情况很隐蔽：如果 Kestrel 启动参数写成--urls "http://localhost:5000"，它在某些系统上会解析到 IPv6 的::1，而 Nginx 里写proxy_pass http://localhost:5000时若解析到 IPv4 的127.0.0.1，连接自然被拒绝。
解决方法是：Kestrel 启动参数和 Nginx 配置里都显式写成127.0.0.1:5000，不要用localhost；然后执行sudo systemctl restart myapp.service和sudo systemctl reload nginx，再看curl -v http://127.0.0.1:5000能否直接通。如果 curl 通而浏览器不通，问题在 Nginx 层，继续看 error.log；如果 curl 都不通，问题在 Kestrel 启动层，看journalctl -u myapp.service -n 50。
5.2 现象二：能访问首页，但 API 接口能通，页面里的静态资源全部 404
这个坑出现在使用location /同时处理静态文件和反向代理时。如果我把location /全部proxy_pass给 Kestrel，而 Kestrel 端没有开启静态文件中间件，那么原本由 IIS 直接提供的 JS、CSS、图片会全部 404。
解决的关键是搞清楚静态文件的最终归属。常见做法是上一步配置里加了一个location /static/用alias指向物理目录，这样静态请求在 Nginx 层直接处理，不进入 Kestrel。但要注意alias和root的差异：root /var/www/myapp/static/会让/static/a.js实际查找/var/www/myapp/static/static/a.js文件，这明显是错的；alias则会替换掉匹配前缀，查找/var/www/myapp/static/a.js。所以一旦发现 404，先确认是alias写成了root。另外，如果你的应用是 ASP.NET Core 且UseStaticFiles()已启用，Kestrel 本身就能处理wwwroot下的静态文件，此时 Nginx 层可以完全不做静态映射，全部转发给后端即可，少一层配置就少一个出错点。
5.3 现象三：HTTPS 证书续期后客户端还是报证书错误，浏览器显示证书链不完整
用 Nginx 替代 IIS 后，HTTPS 的证书配置从 IIS 的“服务器证书”界面变成了 Nginx 的ssl_certificate和ssl_certificate_key指令。坑点在于：很多人做完证书配置后nginx -t通过、curl 访问也正常，但浏览器报警告说不安全。
原因多半是证书文件里只包含站点证书，没有附带中间证书链。某些证书厂商提供的是三个文件：站点证书、中间证书、根证书；Nginx 要求把它们按“站点证书 + 中间证书”的顺序合并成一个.pem文件。如果直接把站点证书单独填进配置，部分浏览器会因为中间证书缺失而报错。
解决方法是：把从证书商那里下载的fullchain.pem文件（已包含中间链）作为ssl_certificate的文件路径，不要把cert.pem单独用；配置完执行nginx -t后，用openssl s_client -connect yourdomain:443 -servername yourdomain检查输出的证书链是否完整。
5.4 现象四：应用里有 WebSocket 功能，切到 Nginx 后连接一直失败，控制台报 400
这个问题和 5.1 一样常见，而且大部分人一开始都不知道和“代理升级”有关。IIS 在托管 ASP.NET 时用的是自己的 WebSocket 适配机制，不需要额外配置；但 Nginx 转发 WebSocket 请求时，必须把 HTTP 升级请求头透传给后端。
如果 Nginx 配置里缺少下面这两行：
proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade";Nginx 默认会按普通 HTTP 请求处理，WebSocket 握手失败，后端收不到升级请求，客户端就会看到 400 或者连接直接断开。解决方法是把这两行加到对应location /块里。注意Connection "upgrade"是个固定字符串，不能写成$connection_upgrade之类的变量——除非你用 map 定义过——很多复制来的配置出错都在这个细节上。
5.5 现象五：迁移后日志里看不到用户真实 IP，分析访问来源全变成 127.0.0.1
这是反向代理模式下最容易被忽略的坑。IIS 里拿到的客户端 IP 是直连的，换成 Nginx 后，如果没有传递X-Forwarded-For头，后端应用取到的 IP 永远是 Nginx 所在机器的 IP。这个影响不只是日志统计：如果你的 ASP.NET Core 应用里有基于 IP 的限流、风控或者地域判断逻辑，全部会失效。
解决方法是 Nginx 层加proxy_set_header X-Real-IP $remote_addr;和proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;，然后在 ASP.NET Core 里配置转发头中间件。在Program.cs中启用：
builder.Services.Configure<ForwardedHeadersOptions>(options => { options.ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto; options.KnownNetworks.Clear(); options.KnownProxies.Clear(); });这里KnownNetworks.Clear()和KnownProxies.Clear()是必要的：ASP.NET Core 默认只信任本机回环代理，如果不清空，即使 Nginx 传了头，应用也会忽略。这个配置改完后必须重启应用进程生效，不要只刷新页面就判断修好了。
6. 切换到新架构后必做的三件事：自检命令、日志追踪和压测方式
替换 IIS 不是把配置写好、跑通就结束了。我每次迁移完都会按一套固定流程做验证：第一件是用curl从多个维度确认响应头和转发头正确；第二件是查看 Nginx 与 Kestrel 两侧的访问日志是否能对上；第三件是压测对比迁移前后的请求吞吐，确认网关层没有成为新的瓶颈。
先给出一组可以直接跑的自检命令：
# 模拟外部请求，查看响应头 curl -I http://127.0.0.1:5000 curl -I http://yourdomain.com # 验证转发头是否被正确传递 curl -H "X-Forwarded-For: 203.0.113.9" http://yourdomain.com # 检查 Nginx 错误日志 tail -f /var/log/nginx/error.log # 查看 Kestrel 服务最近日志 journalctl -u myapp.service -n 30 --no-pager第二件是日志对账：正常请求进来后，Nginx 的 access.log 里应该记录到客户端真实 IP（如果配置了 X-Forwarded-For，Nginx 默认打的是直连 IP，所以真实 IP 要看后端日志或者额外配置 log_format）；Kestrel 端的日志里应该能看到非 127.0.0.1 的客户端地址。如果两边都能对上，说明转发链路完整。
第三件是压测。我一般用 wrk 做简单压测，命令是：
wrk -t4 -c100 -d30s http://yourdomain.com/观察两个核心指标：一是请求成功率，只要出现Non-2xx or 3xx不为零，先查日志；二是吞吐量（Requests/sec），如果远低于直接在 Kestrel 压测的值（Kestrel 本身可以先用wrk -t4 -c100 -d30s http://127.0.0.1:5000/压一遍），就要检查 Nginx 的worker_processes、worker_connections是否调大。我这边的经验是，4 核机器上worker_processes对应 CPU 核数（或设为auto），worker_connections不低于 1024，单体 API 应用在普通配置下不会让 Nginx 成为瓶颈；但如果你用了复杂的 rewrite 规则或者正则 location，压测性能会明显下降，此时优先检查 location 匹配是否走了正则分支。
最后分享一个实战教训：有一次我把 Nginx 里的proxy_read_timeout从默认的 60s 调到了 10s，当天线上一个文件导出接口（耗时约 15 秒）频繁报 504，用户反馈“导出失败”。我一开始以为是后端代码慢，排查了很久才发现是网关层主动断掉连接。这个参数平时不会注意，但迁移后接口超时行为会从 IIS 的默认策略变成 Nginx 的策略，凡是迁完出现“偶发超时”“慢接口失败”的问题，优先看proxy_read_timeout、proxy_send_timeout和proxy_connect_timeout三个值，默认不够就调大。希望这些经验能帮你少走弯路，如果你也正在做同样的切换，把上面这份配置和自检清单在测试环境完整跑一遍，再上生产，替换 IIS 这件事并没有想象中那么玄学。
本文还有配套的精品资源，点击获取
