内容摘要：把netcore应用扔到IIS上跑，最坑人的不是配置，而是你忘了装托管模块。去年我帮朋友部署一个内部工具站，他照着网上的老教程折腾了一下午，IIS里始终显示502.3，最后发现是Hosting Bun

把netcore应用扔到IIS上跑，最坑人的不是配置，而是你忘了装托管模块。去年我帮朋友部署一个内部工具站，他照着网上的老教程折腾了一下午，IIS里始终显示502.3，最后发现是Hosting Bundle没装——这玩意儿其实就是个运行时加模块的合集，官方下载页写得很清楚，但总有人跳过。

先说你真正需要做的第一步：确认服务器上有.NET Core Runtime和Windows Hosting Bundle。前者是跑代码的底座，后者让IIS能识别你的应用。版本必须匹配，比如你本地用6.0开发的，服务器就得装6.0的bundle，别图省事装个5.0的，启动时会直接报错，错误日志里会写“The requested version of .NET Runtime is not installed”。

发布方式选“文件夹”就行，别用“依赖框架”还是“独立部署”纠结太久。内网小工具就选框架依赖，体积小，更新时只换dll；要对外提供且服务器环境不可控，那就独立部署，把整个运行时打包进去，代价是发布目录能到一百多兆。我自己的经验是：除非客户服务器上死活装不上bundle，否则永远用框架依赖。

IIS这边新建站点，物理路径指到你发布出来的文件夹。应用程序池记得把“启用32位应用程序”设为False——除非你引用了老旧的32位原生库。托管模式选“无”，因为netcore不靠IIS的托管管道，它自己跑Kestrel，IIS只是做个反向代理转发请求。这个理解很重要，很多人卡在“HTTP 500.19”就是因为配置文件里有个system.webServer节点写错了。

web.config是另一个容易翻车的地方。发布时vs会帮你生成一个，里面有个aspNetCore processPath="dotnet" arguments=".\你的应用.dll"节点。千万别手贱改成指向exe，除非你用的是独立部署。有个细节：如果应用要跑在子目录而非根路径，web.config里得加一条配置，否则路由全404。

权限问题比你想的简单。应用程序池的标识默认是ApplicationPoolIdentity，给它授予发布文件夹的读取权限就够了。别学某些教程直接给Everyone完全控制，那是给自己挖坑——万一站点被入侵，攻击者能改你的程序文件。我一般只给“读取和执行”加上“列出文件夹内容”，写权限只在需要上传文件的目录单独开。

日志是你最后的救命稻草。netcore的日志默认输出到控制台，IIS下看不到。在appsettings.json里加上"Logging": { "LogLevel": { "Default": "Information"}}，然后用Serilog或者NLog写到文件里。别图省事只依赖Windows事件查看器，那玩意儿对托管代码的报错信息经常截断，看得人脑壳疼。

最后说个冷门坑：你改了系统时间，IIS回收了应用池，然后站点就起不来了。因为Kestrel的HTTPS证书校验会检查有效期，如果你本地时间跳变导致证书“未生效”或“已过期”，连接直接断。遇到这种诡异问题，先查服务器时间同步，再查证书。

跑起来之后，用浏览器访问一下，如果看到默认的“Hello World”页面，恭喜你，IIS和netcore之间的握手成功了。如果还是502，去C盘inetpub\logs\LogFiles目录翻一下IIS的日志，看请求到底转发到哪个端口了——默认5000，但有时候你改了端口，web.config里的转发地址没跟上，那才是真的让人抓狂。反正这套流程我走了不下十遍，每次出幺蛾子的点都不一样，但根子上就是上面这些环节。