简介：这份PDF资料面向需要在Windows服务器上部署.NET WebApi的开发者与运维人员，聚焦IIS环境搭建与端口开放这一常见落地难题。内容从服务器管理器添加角色和功能入手，逐步讲解勾选Web服务器(IIS)、补齐.NET Framework 3.5与4.5组件、勾选管理工具等关键环节，并延伸至站点、应用程序池与虚拟目录的配置，帮助读者打通从发布到外部访问的完整链路。资源包共1个PDF文件，约536KB，篇幅紧凑、步骤清晰，适合作为部署时的对照手册。目前已有341人学习下载，说明其在同类实操场景中具备一定参考价值。读者可据此快速完成IIS安装、应用池配置与端口开放，减少因组件缺失或配置不当导致的部署失败，提升上线效率。
1. 从一次“本地跑通、服务器 404”说起：IIS 托管 .NET WebApi 到底要过几道关
本地 IIS Express 里 Swagger 页面刷得飞起，一放到 Windows 服务器的 IIS 上，浏览器直接甩回一个 404.0，或者更气人的是 500.19——配置文件明明没动过。这个场景我见过太多次，问题基本不在代码，而在 IIS 的角色、功能、应用程序池和端口这四件事上没对齐。.NET WebApi 发布到 Windows 服务器并开放端口，本质就是让 IIS 认识你的运行时、给你的站点分配一个独立进程、再让防火墙放行外部请求。这套流程适合手里有台 Windows Server、想把接口服务正式挂上去的后端和运维同学，也适合第一次从 IIS Express 切到完整 IIS 的开发者。下面按“装 IIS → 配站点 → 排错 → 验证”的顺序拆开讲，每一步都落到能直接抄的界面路径和命令上。
2. 装 IIS 不是一路下一步：角色服务勾选与 .NET 版本对齐
IIS 的安装向导看起来只是点几下，但真正决定后面能不能跑起来的是角色服务里那几个勾。很多人装完 IIS 发现站点起不来，回头一看，要么是 .NET Framework 的版本没勾全，要么是管理工具没装导致连 IIS 管理器都打不开。这一章把安装路径和勾选逻辑讲清楚，顺带说明为什么 .NET 3.5 和 4.x 要一起勾。
2.1 添加角色和功能：从服务器管理器进入安装向导
在 Windows Server 上，IIS 不是单独下载的安装包，而是通过“服务器管理器”里的“添加角色和功能”来装。打开左下角第二个图标进入服务器管理器，点击顶部“管理”菜单，选择“添加角色和功能”，后面按向导走。安装类型选“基于角色或功能的安装”，服务器选择默认的本机即可。
到“服务器角色”这一步，勾选Web 服务器(IIS)。勾上的瞬间通常会弹出一个确认框，提示需要一并添加 IIS 管理控制台等依赖功能，点“添加功能”就行。这一步别跳过，否则后面 IIS 管理器可能根本不在开始菜单里。
# 如果习惯命令行，也可以用 PowerShell 一次性装 IIS 核心角色 # 注意：这条命令装的是基础 Web 服务器角色，.NET 相关功能需要额外指定 Install-WindowsFeature -Name Web-Server -IncludeManagementTools # 查看当前已安装的 IIS 相关功能，确认角色是否落地 Get-WindowsFeature -Name Web-* | Where-Object { $_.Installed -eq $true }上面第一条命令里-IncludeManagementTools很关键，它对应图形界面里“管理工具”那一组勾选，不装的话后面没有 IIS 管理器可用。第二条命令用来回查，输出里带[X]的才是已安装项。如果你在图形界面操作，等价路径就是在“角色服务”页把“管理工具”下的 IIS 管理控制台、IIS 管理脚本和工具全部勾上。
2.2 .NET Framework 3.5 与 4.x 功能：为什么两个都要勾
在“功能”节点下，会看到.NET Framework 3.5 功能和.NET Framework 4.5 功能（不同系统版本显示为 4.x）。这里有个血泪经验：很多人只勾了 4.x，结果部署老一点的 WebApi 项目或者某些依赖 3.5 运行时的组件时直接报错。稳妥做法是把两个大版本下的子项全部展开勾满，尤其是WCF 服务和HTTP 激活这两类，它们和 WebApi 的托管管道直接相关。
| 功能节点 | 必须勾选的子项 | 不勾的后果 |
|---|---|---|
| .NET Framework 3.5 功能 | WCF HTTP 激活、WCF 非 HTTP 激活 | 老项目或部分依赖报 500.19 |
| .NET Framework 4.5 功能 | WCF 服务、ASP.NET 4.x | WebApi 托管管道无法加载 |
| IIS 角色服务 | 管理工具全部、应用程序开发里的 ASP.NET 4.x | IIS 管理器缺失或站点 404 |
勾选时注意每个可展开的下级选项框也要点开确认，向导默认只勾父级、子级经常是半选状态。全部确认后点“下一步”再点“安装”，等待进度条走完。装完后建议重启一次服务器，让运行时注册彻底生效。
2.3 验证安装结果：三个必查项
装完别急着建站点，先做三个检查。第一，开始菜单里能不能找到“Internet Information Services (IIS) 管理器”；第二，浏览器访问http://localhost是否出现 IIS 默认欢迎页；第三，在 IIS 管理器里点开“应用程序池”，看 .NET CLR 版本下拉里有没有 v4.0。
# 在服务器上快速验证 IIS 是否在监听 80 端口 netstat -ano | findstr :80 # 查看 IIS 服务状态，W3SVC 是核心 Web 服务 sc query W3SVCnetstat那条如果看到0.0.0.0:80处于 LISTENING，说明 IIS 已经在监听所有网卡的 80 端口。sc query W3SVC返回 RUNNING 才算服务正常。这两条都过了，再往下走站点配置，能省掉一半“为什么访问不了”的排查时间。
3. 建站点、配应用程序池、放行端口：让外部请求真正进来
IIS 装好只是有了托管环境，真正让 WebApi 跑起来还需要建站点、指定物理路径、配应用程序池，最后在防火墙放行端口。这一章按操作顺序走，每一步都说明参数怎么填、为什么这么填。
3.1 添加网站：物理路径与绑定端口的填法
打开 IIS 管理器，左侧展开服务器节点，右键“网站”选“添加网站”。弹窗里几个字段别填错：
- 网站名称：自己认得就行，比如
MyWebApiSite，不要用中文和空格。 - 物理路径：指向你发布输出的文件夹，比如
D:\publish\MyWebApi。注意是发布后的目录，不是项目源码目录。 - 绑定：类型选
http，IP 地址选“全部未分配”表示监听本机所有网卡，端口填一个没被占用的，比如8080。如果你有域名，主机名可以填上，没有就留空。
<!-- 发布后的 web.config 里，aspNetCore 或 system.webServer 节点决定了 IIS 如何托管 --> <configuration> <system.webServer> <handlers> <!-- 如果是 ASP.NET Core 项目，需要 AspNetCoreModuleV2 处理器 --> <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" /> </handlers> <aspNetCore processPath="dotnet" arguments=".\MyWebApi.dll" stdoutLogEnabled="false" hostingModel="inprocess" /> </system.webServer> </configuration>上面这段是 ASP.NET Core 项目发布后web.config的典型结构。hostingModel="inprocess"表示进程内托管，性能更好，但要求服务器装了对应的 ASP.NET Core 运行时。如果是传统 .NET Framework 的 WebApi，web.config里则是system.web和system.webServer的常规配置，不需要aspNetCore节点。填完点“确定”，站点就出现在左侧列表里。
3.2 应用程序池：.NET CLR 版本与托管管道模式
站点建好后，IIS 会自动创建一个同名应用程序池。点开“应用程序池”，找到它，右键“基本设置”。这里两个参数最关键：
- .NET CLR 版本：传统 .NET Framework 项目选
v4.0.30319；ASP.NET Core 项目选“无托管代码”。 - 托管管道模式：选“集成”，不要选“经典”。经典模式走的是老式 ISAPI 管道，WebApi 的路由和中间件容易出问题。
| 项目类型 | .NET CLR 版本 | 托管管道模式 |
|---|---|---|
| .NET Framework WebApi | v4.0.30319 | 集成 |
| ASP.NET Core WebApi | 无托管代码 | 集成 |
选错 CLR 版本的典型现象是站点一访问就 503，应用程序池自动停止。这时候去“事件查看器 → Windows 日志 → 应用程序”里能看到具体的加载失败原因。改完基本设置后，右键应用程序池选“回收”，让新配置生效。
3.3 防火墙放行：入站规则与端口测试
站点在服务器本机访问通了，不代表外部能访问。Windows 防火墙默认拦掉大部分入站端口。打开“高级安全 Windows Defender 防火墙”，新建入站规则，类型选“端口”，协议 TCP，特定本地端口填你站点绑定的端口（比如 8080），操作选“允许连接”，配置文件三个都勾上，最后起个名字。
# 用 PowerShell 新建入站规则，放行 8080 端口 New-NetFirewallRule -DisplayName "MyWebApi 8080" -Direction Inbound -Protocol TCP -LocalPort 8080 -Action Allow # 查看规则是否生效 Get-NetFirewallRule -DisplayName "MyWebApi 8080" | Select-Object DisplayName, Enabled, Direction, Action第一条命令里-Direction Inbound表示入站，-LocalPort 8080要和站点绑定端口一致。第二条用来确认规则已启用。放行后，从另一台机器用浏览器或curl访问http://服务器IP:8080/接口路径，能返回数据就说明端口通了。如果还不行，回到服务器上用netstat -ano | findstr :8080确认 IIS 确实在监听这个端口，而不是只监听了 localhost。
4. 避坑与排查：IIS 部署 WebApi 最常见的五个翻车点
这一章按“现象 → 原因 → 解决”整理五个高频问题，都是实际部署里反复遇到的。遇到报错先对照这里，能省下大量翻日志的时间。
4.1 现象：访问返回 500.19，配置错误
原因：web.config里引用了 IIS 没安装的模块，比如 ASP.NET Core 项目缺少 AspNetCoreModuleV2，或者 .NET Framework 版本没勾全导致system.webServer节点无法识别。
解决：先看错误页里具体是哪个配置节报错。如果是 ASP.NET Core，去微软官网下载对应版本的 Hosting Bundle 装上，装完在命令行执行net stop was /y再net start w3svc重启 IIS。如果是 .NET Framework，回到“添加角色和功能”里把对应版本的 WCF 和 ASP.NET 子项补勾。
4.2 现象：访问返回 404.0，但本机 localhost 能通
原因：路由前缀或站点物理路径不对。常见的是发布目录里多了一层文件夹，导致 IIS 的根指向了错误位置；或者 WebApi 的路由配置带了前缀，访问时没加。
解决：在 IIS 管理器里点站点，右侧“基本设置”确认物理路径指向的是包含web.config和bin的那一层。然后用http://localhost:端口/实际路由在本机测，通了再换服务器 IP 测。如果本机 localhost 也不通，问题在应用本身，不在 IIS。
4.3 现象：应用程序池自动停止，事件日志报 503
原因：应用程序池的 .NET CLR 版本和项目不匹配，或者进程启动时崩溃。ASP.NET Core 项目如果 CLR 版本选了 v4.0，就会因为找不到托管入口而反复重启。
解决：把应用程序池的 .NET CLR 版本改成“无托管代码”（ASP.NET Core）或v4.0.30319（.NET Framework）。改完回收应用程序池。如果还停，去事件查看器看“应用程序”日志里的具体异常，通常是缺少运行时或依赖文件。
4.4 现象：外部机器访问超时，服务器本机正常
原因：防火墙没放行端口，或者云服务器还有一层安全组规则没开。
解决：先在服务器上用netstat -ano | findstr :端口确认监听地址是0.0.0.0而不是127.0.0.1。如果是127.0.0.1，说明站点绑定里 IP 地址选了具体回环地址，改成“全部未分配”。然后检查 Windows 防火墙入站规则，再检查云平台的安全组。两层都放行后，用telnet 服务器IP 端口从外部测连通性。
4.5 现象：接口返回 500，但日志里没有堆栈
原因：IIS 默认不把详细错误发给外部客户端，只返回一个笼统的 500。开发环境能看到堆栈，生产环境看不到。
解决：临时在web.config里把customErrors设为Off（.NET Framework）或在launchSettings之外配置详细错误页（ASP.NET Core），复现一次拿到堆栈后立刻改回去。更稳妥的做法是配好日志组件，把异常写到文件里，不依赖 IIS 的错误页。
注意：生产环境不要长期开着详细错误，排查完就关，避免泄露内部路径和堆栈信息。
5. 进阶验证：用 curl 和日志把“端口开放”这件事坐实
部署完最怕的是“以为通了”。我一般会走一套固定验证流程，从本机到外部、从端口到接口、从响应到日志，全部过一遍才算完。这一章把这套流程拆成可复制的命令和检查点。
5.1 三层验证：端口、站点、接口
第一层验端口，在服务器上执行netstat -ano | findstr :8080，确认状态是 LISTENING 且地址是0.0.0.0。第二层验站点，在服务器浏览器访问http://localhost:8080，看是否返回 IIS 默认页或应用首页。第三层验接口，用curl带完整路径请求一个具体 API。
# 从外部机器验证接口连通性，-i 显示响应头，-v 显示详细过程 curl -i -X GET "http://服务器IP:8080/api/values" -H "Accept: application/json" # 如果接口需要 POST，用 -d 带 JSON 体 curl -i -X POST "http://服务器IP:8080/api/values" -H "Content-Type: application/json" -d "{\"name\":\"test\"}"-i能看到 HTTP 状态码和响应头，-v在连接失败时能看出是卡在 TCP 握手还是 TLS 协商。如果返回 200 且 body 是预期 JSON，说明端口、站点、接口三层全通。如果返回 401 或 403，说明通了但认证没过，那是应用层的事，和 IIS 部署无关。
5.2 日志落盘：让每次请求都有迹可循
IIS 自带请求日志，默认在C:\inetpub\logs\LogFiles下按站点分目录。开启方法是点站点，右侧“日志”图标，确认“启用”勾上，格式选 W3C。应用层的日志则取决于你用的框架，ASP.NET Core 常用 Serilog 或 NLog 写到文件。
// ASP.NET Core 里用 Serilog 写文件日志的最小配置 Log.Logger = new LoggerConfiguration() .WriteTo.File("logs/mywebapi-.log", rollingInterval: RollingInterval.Day) .CreateLogger(); // 在 Program.cs 里挂上 builder.Host.UseSerilog();rollingInterval: RollingInterval.Day表示按天切分日志文件，方便排查某一天的请求。挂上之后，每次接口调用都会在logs目录下留记录，配合 IIS 的请求日志，能定位到是请求没到 IIS、到了 IIS 没进应用、还是进了应用报的错。
5.3 一个我常犯的错：改完配置忘了回收
最后说个习惯问题。IIS 的很多配置改完不会自动生效，尤其是应用程序池的 CLR 版本和web.config的改动。我早期经常改完web.config直接刷新浏览器，结果还是旧行为，折腾半天才发现要回收应用程序池。现在我的固定动作是：改完配置 → 右键应用程序池“回收” → 再测。如果是 ASP.NET Core 改了web.config，还要执行net stop was /y && net start w3svc重启 IIS 才能让新配置加载。从那以后我每次部署完都强制走一遍“回收 + 重启 + curl 验证”三步，再也没出现过“明明改了却没生效”的玄学问题。希望这套流程帮到你。
本文还有配套的精品资源，点击获取
