远程Windows2016服务器重启后IIS中ASP.NET Core应用无法自动重启求助

问题描述 #

我希望实现远程Windows 2016服务器重启后，IIS托管的ASP.NET Core应用自动重启，已执行以下步骤但未生效：

• 设置应用池StartMode=AlwaysRunning；
• 站点高级设置中开启preloadEnabled=true；
• 安装Windows的Application Initialization功能；
• 在Configuration Editor中，于web.config的system.webServer/applicationInitialization节点设置doAppInitAfterRestart为True；
• 添加initializationPage "/"、hostName ""；
• 添加initializationPage "/about"、hostNmae "localhost"。

但服务器重启后应用仍需手动发起首次请求才能启动，而本地IIS按相同配置操作可正常自动重启，能通过Serilog看到127.0.0.1的请求。请问远程服务器可能遗漏了哪些配置？或有什么调试方法可验证Application Initialization模块是否正常工作？

可能遗漏的配置项 #

• 检查应用池标识权限：远程服务器的应用池标识（比如默认的ApplicationPoolIdentity）可能没有足够权限访问网站目录或执行初始化请求。可以尝试临时将应用池标识切换为具有本地管理员权限的账户测试，若生效再细化权限配置。
• 确认ASP.NET Core模块版本：确保远程服务器安装了与本地环境一致的ASP.NET Core托管捆绑包，旧版本可能存在初始化逻辑的兼容性问题。
• 验证站点绑定与hostName匹配：如果站点绑定了特定主机头，initializationPage配置中的hostName必须与绑定的主机头完全匹配，否则初始化请求会因主机头不匹配被拒绝。比如站点绑定的是example.com，就不能用localhost作为hostName。
• 设置站点启动类型为自动：重启服务器后检查站点是否处于"已启动"状态，部分情况下服务器重启后站点可能被自动停止，需在站点属性中把"启动类型"设为"自动"。
• 排查本地防火墙拦截：远程服务器的本地防火墙可能拦截了127.0.0.1的内部请求，导致Application Initialization模块的初始化请求无法到达应用。可临时关闭防火墙测试，或添加允许回环地址的入站规则。
• 修正配置拼写错误：注意到配置中有hostNmae "localhost"，这里hostNmae是拼写错误，正确应为hostName，这个错误会导致初始化请求的主机头配置失效。

调试验证方法 #

• 查看IIS访问日志：在站点日志目录（默认C:\inetpub\logs\LogFiles）中，重启服务器后检查是否有来自127.0.0.1的初始化请求记录。无记录说明模块未触发；有4xx/5xx状态码则说明请求执行失败，可根据状态码排查原因。
• 启用失败请求跟踪：在IIS管理器中为站点启用"失败请求跟踪规则"，设置跟踪所有请求或特定状态码，重启服务器后查看跟踪日志，能详细看到初始化请求的执行流程，定位出错环节。
• 检查Windows事件日志：打开事件查看器，查看"Windows日志-应用程序"中的IIS相关事件，Application Initialization模块的异常或启动失败会在这里留下日志记录。
• 手动模拟初始化请求：在远程服务器上用PowerShell的Invoke-WebRequest http://localhost/或curl http://localhost/about命令发起请求，验证应用能否正常处理回环请求。
• 检查应用池进程状态：重启服务器后，打开任务管理器查看对应应用池的w3wp.exe进程是否启动。若进程未启动，说明应用池AlwaysRunning配置未生效，可能被其他配置覆盖。

内容的提问来源于stack exchange，提问作者KaraNoKara