IIS迁移选型与避坑：四类Web服务器对比实战

简介：面向需要在 Windows 环境下快速搭建轻量 Web 服务、尤其是调试 ASP 页面的用户，这份小型工具包提供了一套替代 IIS 的简易思路。它围绕可执行服务程序、页面样式表与说明网页组织，适合个人开发者、教学演示或旧项目维护场景，用于低成本启动本地站点并验证动态页面运行效果。压缩包共 3 个文件，主要为 exe、css 与 htm 类型，体积约 1.01MB，结构精简，下载与部署负担较小。已有 436 人学习或下载，说明其对 IIS 替代方案与 ASP 运行环境感兴趣的读者具有一定参考价值。读者可借此了解轻量服务器工具的组成方式，结合说明页理解其配置方式，并用于 ASP 页面本地测试、简易站点发布，或在选型时与 Nginx、Apache、Caddy 等常见方案作入门对比，辅助判断工具是否契合自身开发与维护需求。

1. 换掉 IIS 之前：你要换的不是软件，是它替你兜住的那层默认行为

去年接手一个跑了七八年的老站点，机房要回收那台 Windows 主机，我第一反应是赶紧找个代替 IIS 的软件，越快越好。第一次迁移就翻了车：首页能开，后台上传接口全挂，日志里连一行有用的信息都没有。查了大半天才发现，问题根本不在新服务器软件上，而在 IIS 里那个我从没正眼看过的默认请求体大小限制，它一直默默兜着这个站点。这件事之后我改了判断顺序：先摸清你在 IIS 上依赖了什么，再谈换谁。这篇写给正在做这类决策的人，手里可能有静态站、有跑了很多年的 ASP.NET 应用、也有新写的接口服务，想知道几种替代方案各适合谁、动手前要先盘哪些东西、哪一步最容易出事。

2. 选型维度：给代替 IIS 的软件排序，先定这五把尺子

选型最怕上来就比性能跑分。静态文件谁快谁慢，在你实际并发量级下基本看不出差别，真正让你半夜爬起来的是证书过期、路径 404、上传失败这类琐事。我一般按五个维度排：托管模型、配置迁移成本、TLS 与可观测性、生态与人力，最后才是性能。下面逐个说清楚怎么判断。

2.1 托管模型：站点是跑在服务器里，还是服务器本身就是站点

IIS 是典型的容器式模型：一台机器上装一个服务，配置里挂若干个站点，每个站点绑主机头、端口、证书，应用池负责隔离和回收。Nginx、Apache、Caddy 都是同一套思路，只是换了个配置文件格式。Kestrel 恰好反过来——你的程序本身就是服务器，一个进程通常就是一个站点。

这个差别决定了迁移工作量。一台 Windows 主机上挂着七八个站点、共用不同主机头，换成 Kestrel 就意味着七个进程、七份配置、七套守护，运维复杂度直接翻倍；反过来，如果你手上只有两三个 .NET 应用，用 Kestrel 加前置反向代理反而比配置一个通用 Web 服务器更省事。

还有一条更硬的判断线：有没有 Windows 专有依赖。Windows 集成身份验证、COM 组件、注册表读写、依赖文件锁的旧代码、本地消息队列，只要命中其中一项，跨平台这条路基本就堵死了，剩下能选的是继续留在 Windows 上，只是把 IIS 换成别的服务器软件。我见过太多团队在这一点上判断失误，方案选得漂亮，最后卡在一个调不动的老 DLL 上。

2.2 配置迁移成本：web.config 里那些没人看的规则才是大头

web.config 是一个容易被低估的坑。它表面上是个配置文件，实际上承载了这个站点多年的历史：请求体大小限制、URL 重写规则、自定义响应头、默认文档、MIME 类型补充、错误页、模块注册、授权规则，一层套一层，很多条目连原作者都说不清为什么在那儿。

判断成本的方法很土但有效：把 web.config 全文捞出来，按节点分类计数。URL 重写规则超过二十条，就要单独排期，因为重写规则的语义在 Nginx 的 rewrite、Caddy 的 try_files 之间并不一一对应，正则写法、大小写敏感、尾部斜杠处理都会产生行为差异，得逐条对着测。请求体大小、默认文档、MIME 补充、自定义头这几类倒是很快，基本是查表替换的活儿。

真正花时间的往往不是规则本身，而是规则背后的隐含假设。比如一条重写规则把/api/xxx转到/api/xxx.ashx，在 IIS 上跑得好好的，换到新服务器上因为大小写敏感或者路径拼接方式不同，直接 404。这种问题不看原始配置根本猜不到。

2.3 TLS 与进程可观测性：证书续期和日志这两件事最容易欠债

IIS 的证书绑定是手工活，续期靠人记着，这是很多团队的隐性技术债。换成 Nginx，证书还是要自己配、自己续，通常靠定时任务加一个重载命令；Caddy 把这件事直接内建了，只要域名解析正确、80 和 443 可达，签发和续期它自己管。如果你的站点数量多、证书来源杂，这一项的权重应该往上调。

可观测性是另一处容易被忽略的差异。IIS 有 W3C 格式的访问日志，还有失败请求跟踪这种能抓到具体模块和耗时的手段。Nginx 的日志默认字段和 IIS 完全不是一套，$remote_addr、$request_time、$upstream_response_time这些字段需要自己组织成log_format，否则你原来那套日志分析脚本全部失效。进程守护也一样：IIS 有应用池自动重启和快速失败保护，Nginx 是主进程带工作进程，工作进程挂了会自动拉起，而 Kestrel 单独跑的话没有任何守护，必须靠 systemd 或容器编排兜底。

我把这块叫黑匣子问题。迁移前先问自己一句：出问题时我手上有什么证据。答不上来就先别切流量。

2.4 生态与人力：冷门方案省下的性能要用人力还

模块生态这一项，Apache 底子最厚，几十年的模块积累，几乎任何奇怪需求都能找到现成方案；Nginx 的资料量和招人容易度最高，出问题搜一下基本有答案；Caddy 的配置极简，但遇到冷门需求时文档深度不如前两者；Kestrel 只在 .NET 圈子里，出了圈基本没人认。

还有一条经常被忽略：Windows 上的 Nginx 是模拟多工作进程的，官方文档也说明了它在 Windows 上的表现不适合高并发生产场景。如果你的结论是"继续留在 Windows 主机上"，那 Nginx 未必是首选，反而 Apache 或者干脆保留 IIS 换掉站点架构更实际。方案选型必须和宿主机绑定在一起考虑，脱离部署环境谈优劣没有意义。

2.5 五个维度摆在一起看的对照表

把上面几条落成一张表，选型会快很多。下表的判断基于常见的中小型站点迁移场景，并发量级在几百到几千 QPS 以内，超大流量场景需要重新评估。

这张表只是起点，具体项目里我会把权重按实际情况调。证书数量多、运维人手少，就把自动化那一列权重加倍；老应用多、重写规则复杂，就把迁移成本那一列权重加倍。

3. 四类方案逐项对比：Nginx、Apache、Caddy、Kestrel 各能接住什么

四个方案不是同一层的东西，硬拉在一起比容易失真。准确地说，Nginx、Apache、Caddy 是通用 Web 服务器，可以独立承接站点；Kestrel 是应用内服务器，通常要和前三种之一搭配使用。下面按"能接住什么、接不住什么"分别说。

3.1 Nginx：静态资源和反向代理入口的默认答案

大部分从 IIS 迁走的项目最后都落在 Nginx 上，原因很实在：静态文件处理干净，反向代理配置直观，资源占用低，出了问题网上能找到答案。它对应的 IIS 能力大致是：站点绑定对应 server 块，URL 重写对应 rewrite 与 try_files，请求过滤对应 client_max_body_size 一类指令，自定义响应头对应 add_header。

它的短板也很明确。第三方模块大多需要重新编译，动态模块支持是后来才有的，不如 Apache 那种加载即用的体验；配置语法对新手有门槛，一个分号漏了就是 500；Windows 版本不适合生产；证书续期得自己搭。如果你的站点以静态资源加反向代理为主，这些短板基本碰不到；如果重写规则特别复杂，翻译工作量会比想象中大。

3.2 Apache HTTP Server：老站点和 .htaccess 惯性的退路

如果原站点重度依赖 .htaccess 或者大量 Apache 风格的重写规则，迁移到 Apache 反而最省事。它的模块生态最成熟，认证、改写、压缩、限流都有现成方案，配置项的可读性也比 Nginx 好一些，出了错日志提示相对友好。

代价是资源和调优复杂度。默认的多进程模型在高并发下内存占用比 Nginx 高，需要根据场景在 prefork、worker、event 几种模式之间选，这个选择对新手不友好。另外，如果原来的站点是经典 ASP 或者老式 WebForms，Apache 也接不住，那部分只能靠单独的应用服务器或者整体重写，别指望换个 Web 服务器就解决。

3.3 Caddy：把证书这件事从运维流程里拿掉

Caddy 最大的价值是把 TLS 这件事从"运维任务"变成"默认行为"。配置文件里写个域名，证书签发和续期它自己完成，不需要你写定时任务，也不会有"某张证书忘了续导致凌晨告警"这种事。配置语法也短，一个反向代理加静态文件服务几行就写完，对站点数量多、证书来源杂的环境特别友好。

限制在于生态。它的模块数量比不上前两者，遇到非常规需求时可能得自己写插件；日志格式虽然能配，但周边分析工具的支持度不如 Nginx 成熟；团队里如果有人只熟悉 Nginx，接手 Caddy 需要一点适应时间。我的判断是：如果你的团队规模小、站点多、没人愿意天天盯证书，Caddy 的性价比很高。

3.4 Kestrel 加反向代理：.NET 应用最省心的组合

如果站点本身就是 .NET 应用，最干净的做法是让 Kestrel 只监听回环地址，公网流量统一由前置的 Nginx 或 Caddy 进来。好处是应用和服务器职责分离：TLS、静态资源、限流、压缩交给前置，业务逻辑只关心请求，升级部署也只是重启一个进程。

关键点有三个。第一，监听地址必须是127.0.0.1，否则外部可以绕过前置代理直连应用端口。第二，请求体大小限制要在 Kestrel 里显式设置，IIS 的默认值和 Kestrel 的默认值并不一致，直接搬过来很可能上传失败。第三，必须启用转发头处理，否则应用里拿到的客户端 IP 永远是127.0.0.1，日志和风控全部失真。下面这段配置把这三件事一次做完。

var builder = WebApplication.CreateBuilder(args); builder.WebHost.ConfigureKestrel(options => { // 只监听回环地址，公网流量必须经过前置代理，防止绕过 options.ListenLocalhost(5000); // 对应 IIS 的 maxAllowedContentLength，默认值往往撑不住大文件上传 options.Limits.MaxRequestBodySize = 100 * 1024 * 1024; // 长上传或慢客户端场景下，默认的头部超时可能不够 options.Limits.RequestHeadersTimeout = TimeSpan.FromSeconds(60); }); builder.Services.Configure<ForwardedHeadersOptions>(options => { options.ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto; // 代理与应用同机部署时清空已知网络；跨机部署改成代理所在的内网段 options.KnownNetworks.Clear(); options.KnownProxies.Clear(); }); var app = builder.Build(); // 必须放在任何读取 RemoteIpAddress 的中间件之前 app.UseForwardedHeaders(); app.Run();

ListenLocalhost决定了应用端口的暴露范围，改成ListenAnyIP就等于把应用直接挂到公网，这一步别图省事。MaxRequestBodySize的单位是字节，和 IIS 里按 KB 计的maxRequestLength换算容易出错，迁移时对着原配置逐项核一遍。UseForwardedHeaders的位置极其关键，放在鉴权中间件之后的话，限流和审计拿到的仍然是代理地址。

3.5 同一个站点在三种方案下的配置对照

光看文字不直观，把同一个站点——静态资源加/api/反向代理——分别写成 Nginx 和 Caddy 的配置，差异一眼就能看出来。

# Nginx：站点绑定 + 静态资源 + 反向代理 server { listen 80; server_name app.internal.example; # 换成你自己的域名 return 301 https://$host$request_uri; } server { listen 443 ssl; http2 on; server_name app.internal.example; ssl_certificate /etc/ssl/site/fullchain.pem; ssl_certificate_key /etc/ssl/site/privkey.pem; # IIS 的请求体限制在这里没有等价默认值，必须显式放宽 client_max_body_size 100m; client_body_timeout 120s; root /srv/app/wwwroot; index index.html; # 对应 IIS 里 SPA 的 URL 重写回退规则 location / { try_files $uri $uri/ /index.html; } location /api/ { 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; # WebSocket 与长连接场景必须显式声明 proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_read_timeout 120s; } }

# Caddy：同样的站点，证书由它自己申请和续期 app.internal.example { encode gzip zstd root * /srv/app/wwwroot # 反向代理规则写在前面，命中 /api/ 的请求不进静态文件逻辑 handle /api/* { reverse_proxy 127.0.0.1:5000 { header_up X-Real-IP {remote_host} } } # SPA 回退：找不到文件时交给 index.html try_files {path} /index.html file_server }

两份配置的差别不只是行数。Nginx 版本里，证书路径、续期任务、日志格式、请求体限制全部要人写；Caddy 版本里，证书那一段直接消失了，请求体限制默认就足够宽松，代价是你对细节的掌控少一些。迁移时我的习惯是先写 Caddy 版本验证业务能不能跑通，确认没问题再决定要不要换成 Nginx 做精细调优，这样能快速排掉"是不是服务器软件的问题"这类干扰。

4. 迁移实战：从 IIS 站点到新服务器的四步走

方案定下来之后，真正的活儿才开始。整个迁移我会拆成四步：盘点、分类、改写、切换。顺序不能乱，跳过盘点直接改配置，大概率会在某个不起眼的模块上翻车。

4.1 迁移前盘点：五张清单缺一不可

盘点做得越细，后面返工越少。我一般会整理出五张清单，缺一张都会在切换当天出问题。

第一张清单里最容易漏的是应用池身份。IIS 里站点默认以某个应用池身份运行，这个身份对物理路径、对数据库、对共享目录都有授权，换成新服务器后进程用户变了，权限全断。第二张里最容易漏的是 SNI，一台机器多个证书时没有 SNI 会返回错误的证书。

4.2 三类站点的搬迁路径

不同类型站点的做法差别很大，混在一起谈容易误导。

纯静态站最简单：文件拷过去，注意保留目录结构和文件名大小写，写一个 server 块或者一段 Caddyfile，加上缓存头和压缩，基本就完事。唯一要小心的是中文文件名和原来依赖的默认文档顺序。

.NET 应用分两种。较新的框架版本本身跨平台，直接把发布产物拷到目标机器，用 Kestrel 跑起来，前置加一层反向代理，配置文件里的连接字符串和路径改成新环境的。老一些的 WebForms 或者重度依赖 Windows 组件的项目，不要硬迁，让它留在 Windows 上，只是把 IIS 换成"反向代理 + 应用内服务器"的组合，先把入口层统一，应用本身慢慢重写。

经典 ASP 这类老技术栈基本没有官方跨平台方案。现实做法是继续保留一台 Windows 主机专门跑它，外面统一用一层反向代理把流量分过来，等业务下线或者重写到新框架再彻底关掉。这个决定不好看，但比强行迁移再回滚要省事得多。

4.3 配置改写对照：从 web.config 到新配置

改写阶段最实用的是一张对照表，照着填比凭记忆靠谱。

重写规则是最容易出错的一块。IIS 的规则里常见^$、^(.+)$这类写法，配合{R:1}做反向引用，翻译到 Nginx 时要换成$1，同时注意rewrite默认在 server 上下文里对 URI 做匹配，而location匹配的是解码后的路径。尾部斜杠尤其坑人：IIS 默认对目录补斜杠，Nginx 需要try_files $uri $uri/才会做同样的事，少写一个$uri/，目录访问就变成 404。

4.4 切换与验证：灰度、回滚、验收项

切换那天不要一次性把流量全切过去。我的做法是让新旧两套并行跑一段时间，先通过内网 hosts 或者测试域名验证功能，再按比例把流量引到新服务器，观察至少一个完整业务周期。日志里的 5xx 比例、接口平均耗时、上传成功率这三个指标是核心观察项。

回滚开关必须提前准备好，而且要是"停流量"而不是"停服务"——旧服务器保持运行状态，只是不接新流量，出问题时改一行上游配置就能切回来。这一条是后悔药，希望你用不上，但一定要有。

验收项至少覆盖：首页与深层链接、登录与鉴权、文件上传下载（含大文件）、带中文的参数与文件名、静态资源缓存命中、WebSocket 或长轮询连接、错误页返回码、以及日志里客户端 IP 是否真实。每一条都实际点一遍，别只看监控面板上的曲线。

5. 避坑与排查：迁移路上最容易翻车的五个点

下面这五条是我自己或者身边人真实踩过的，按「现象 → 原因 → 解决」写，遇到同类问题时可以直接对照。

5.1 上传接口集体失败，返回 413 或 500

现象：站点其他功能正常，只有上传接口挂掉，小文件能传，超过几兆就失败，日志里要么是 413，要么是一句没有上下文的 500。

原因：IIS 里maxRequestLength和maxAllowedContentLength两个限制同时存在，一个按 KB 一个按字节，很多人只调了其中一个。换到新服务器后这两个限制都不存在了，取而代之的是 Nginx 的client_max_body_size（默认值很小）和 Kestrel 的MaxRequestBodySize（默认也有上限），任何一层没放开都会拦下来。

解决：把链路每一层的限制都显式写出来，Nginx 的client_max_body_size、Kestrel 的MaxRequestBodySize、以及应用框架自身如果有独立限制也要一起改。改完用一个刚好超过原限制的文件实测，别用几十 K 的小文件自欺欺人。另外，client_body_timeout也要跟着调，大文件慢速上传时默认超时会提前断开。

5.2 日志里客户端 IP 全变成 127.0.0.1

现象：切换后风控规则全部失效，日志里所有请求的来源地址都是本机回环地址，限流和黑名单形同虚设。

原因：请求经过了前置反向代理，应用看到的是代理的地址。IIS 时代如果启用了反向代理模块，它会帮忙处理转发头；换成 Nginx 加 Kestrel 之后，转发头需要显式设置和显式信任，缺任何一环都不生效。

解决：代理侧加proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for和X-Forwarded-Proto，应用侧启用转发头中间件并把它放在管道最前面。如果是跨机部署，还要把代理所在的内网段加进已知网络，否则框架出于安全考虑会忽略这些头。验证方法很直接：随便发一个请求，看应用日志里记录的 IP 是不是你自己的出口地址。

5.3 Linux 上路径大小写不一致导致 404

现象：页面能打开，但部分图片、样式、接口 404，开发环境完全正常。

原因：原来跑在 Windows 上，文件系统对大小写不敏感，代码里写~/Content/Site.css还是~/content/site.css都能找到文件；换到大小写敏感的文件系统后，只要有一个字母对不上就是 404。反斜杠也是同理，\在 Windows 里是路径分隔符，在别的系统里不是。

解决：迁移前用脚本扫一遍代码和配置里的静态资源引用，把大小写和分隔符统一。已经上线的环境，可以用访问日志里的 404 路径反查实际文件名，逐个修正。长期做法是在构建流程里加一步校验，避免以后再犯。

5.4 中文文件名和 URL 参数出现乱码

现象：下载文件名变成一串百分号编码，或者带中文的查询参数到后端变成问号。

原因：文件系统编码、HTTP 响应头编码、页面编码三者不一致。IIS 环境下很多项目默认走的是本地编码，迁到新环境后统一成了 UTF-8，原来"恰好能跑"的代码就暴露了问题。下载场景里常见的是Content-Disposition只写了filename=，没有按规范补filename*=。

解决：统一全链路 UTF-8，包括文件系统、应用配置、响应头、数据库连接。下载接口按规范同时输出filename和filename*两个参数，兼容旧客户端。URL 里的中文参数在代理层不要做二次编码，Nginx 默认会对 URI 做一次解码，配置里如果开了二次解码反而会乱。

5.5 WebSocket 和长连接在代理后面连不上

现象：实时推送功能在测试环境正常，切换后一直 502 或者连接几秒就断。

原因：WebSocket 需要Upgrade和Connection两个头透传，Nginx 默认不透传这两项；另外长连接的空闲超时默认值偏短，连接被代理主动断掉。如果用了平滑重载，工作进程退出时也会把长连接一起切断。

解决：代理的 location 里显式加proxy_set_header Upgrade $http_upgrade和proxy_set_header Connection "upgrade"，把proxy_read_timeout调到业务能接受的范围。重载时设置工作进程的优雅退出时间，让存量连接自然结束再退出。切换前一定要单独测一遍实时功能，这类问题不会在普通页面上暴露出来。

6. 按场景落地：三个答案加一条验证命令

把上面的内容收成三个可执行的判断，你对号入座就行。

定完方案之后，别急着切流量，先跑一条最朴素的验证命令。下面这段用 curl 把整条链路的关键行为一次性验一遍，包括大文件上传、转发头、错误页返回码。

# 1. 大文件上传：验证请求体限制是否放开（构造 50MB 随机文件） head -c 52428800 /dev/urandom > /tmp/probe.bin curl -s -o /dev/null -w "upload:%{http_code}\n" \ -F "file=@/tmp/probe.bin" https://app.internal.example/api/upload # 2. 转发头：确认后端拿到的客户端地址不是 127.0.0.1 curl -s https://app.internal.example/api/whoami # 3. 深层链接：确认 SPA 回退规则生效，返回 200 而不是 404 curl -s -o /dev/null -w "spa:%{http_code}\n" \ https://app.internal.example/some/deep/route # 4. 错误页：请求不存在的接口，确认返回码和自定义页都符合预期 curl -s -o /dev/null -w "error:%{http_code}\n" \ https://app.internal.example/api/not-exist

四个检查项分别对应四类最容易出问题的地方。第一项失败说明请求体限制没改全，第二项失败说明转发头链路断了，第三项失败说明重写或回退规则翻错了，第四项失败多半是错误页配置把返回码一并改成了 200，而返回码被改写会直接影响监控告警和搜索引擎行为，比页面显示错误更隐蔽。

说实话，我最早做这类迁移时吃过最大的亏，不是技术选型选错，而是没把「原环境到底依赖了什么」当回事。那次上传翻车之后，我给自己定了个死规矩：不管站点多小，动手前必须把 web.config 从头到尾读一遍，把每一条限制、每一条重写规则都抄到一张表上，逐条标注在新环境怎么落地。这个动作看着笨，但它把不确定性从"切换当天才发现"挪到了"动手之前就清楚"，后面所有事都轻松了。

希望这些踩坑记录能帮你少走一段弯路。

本文还有配套的精品资源，点击获取