ASP.net Core 应用部署到iis的核心是IIS通过ANCM反向代理请求至Kestrel服务器。需确保安装Hosting Bundle、正确发布应用、配置IIS站点（应用程序池设为“无托管代码”）、验证web.config生效，最后通过日志排查500.19/502.5错误。
ASP.NET Core 应用部署到 IIS，核心是把它当作一个反向代理后的“独立可执行程序”来运行，IIS 本身不直接托管 .NET Core 代码，而是通过 ASP.NET Core Module（ANCM） 转发请求给后台的 Kestrel 服务器。只要环境配对、发布正确、IIS 设置到位，基本不会出问题。
一、确保服务器环境已就绪
部署前必须确认以下三项都已安装并启用：
- windows Server 或 windows 10/11（支持 IIS 10+）
- IIS 已启用：在“启用或关闭 Windows 功能”中勾选“internet Information Services”及其子项（尤其“Web 管理工具”和“万维网服务”）
- .NET Core 运行时（Runtime）或 托管捆绑包（Hosting Bundle）已安装 —— 推荐装 Hosting Bundle，它自动包含 Runtime + ANCM + IIS 注册逻辑，下载地址：https://www.php.cn/link/ac5a08fd81df9def6dd34354e08bc3bd
二、发布应用（推荐使用“自包含”或“框架依赖”发布）
在项目目录下执行命令行发布（或用 visual studio 发布向导），关键点是目标运行时和输出路径：
- 框架依赖发布（轻量，需服务器装 Runtime）：
dotnet publish -c Release -r win-x64 --self-contained false -o ./publish - 自包含发布（体积大，无需服务器装 Runtime）：
dotnet publish -c Release -r win-x64 --self-contained true -o ./publish - 发布后检查
publish文件夹里是否有yourapp.dll和web.config（若没有 web.config，VS 会自动生成；如用 CLI 发布，可手动添加或用--no-self-contained+--runtime win-x64触发生成）
三、配置 IIS 站点与应用程序池
这是最容易出错的环节，注意细节：
- 新建网站时，“物理路径”指向你发布的
publish文件夹（不是项目根目录，也不是 bin/Debug） - 应用程序池 必须设为“无托管代码”（No Managed Code） —— 因为 ASP.NET Core 自己跑 Kestrel，不需要 IIS 加载 .NET Framework 或 .NET Core 托管环境
- 确保应用程序池“启动模式”为 “始终运行”，“闲置超时”设为 0（避免冷启动延迟）
- 检查站点绑定是否正确（如 http:80 / https:443），并确认端口未被占用
四、验证 web.config 是否生效
IIS 通过 web.config 调用 ANCM，这个文件不能少，内容应类似：
<?xml version="1.0" encoding="utf-8"?> <configuration> <location path="." inheritInChildApplications="false"> <system.webServer> <handlers> <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" /> </handlers> <aspNetCore processPath="dotnet" arguments=".YourApp.dll" stdoutLogEnabled="true" stdoutLogFile=".logsstdout" hostingModel="inprocess" /> </system.webServer> </location> </configuration>重点字段说明：
-
processPath：一般填dotnet（要求服务器有全局 dotnet 命令）；若用自包含发布，可改为具体路径如.YourApp.exe -
hostingModel：推荐inprocess（性能更好），也可用outofprocess（更稳定，隔离性更强） -
stdoutLogEnabled：上线后建议开启，日志能帮你快速定位启动失败原因（比如端口冲突、缺少依赖、权限不足）
基本上就这些。部署后访问站点，如果看到 500.19 / 502.5 错误，优先查 Windows 事件查看器里的“ASP.NET Core 模块”日志，再配合 stdout 日志定位。不复杂但容易忽略细节。