.Net Core 3.1应用部署IIS遇403/404错误的配置排查

环境背景 #

• 域名：example.com，下挂auth、services等多个应用
• services目录下包含sub-application1、sub-application2等子应用
• 新增子应用example.com/services/sub-applicationNew为.Net Core 3.1版本，和其他应用版本一致

异常现象 #

• 线上访问example.com/services/sub-applicationNew根路径返回403错误，但把该目录下的文件替换成其他正常应用的文件后，就能正常访问
• 本地环境访问example.local.com/services/sub-applicationNew根路径返回404（符合Web API无默认页面的特性），但调用接口example.local.com/services/sub-applicationNew/api/public/test能正常返回结果
• 线上调用同一个接口example.com/services/sub-applicationNew/api/public/test却返回404错误

重点排查的IIS配置项 #

1. 应用程序池配置 #

• 确认子应用对应的应用程序池，.NET CLR版本是否设为无托管代码——.Net Core应用是自托管模式，不需要IIS提供托管CLR，选错版本会直接导致运行异常
• 检查应用程序池的标识权限：确保该标识对sub-applicationNew的文件目录有读取、执行权限，权限不够会触发403错误

2. 模块映射配置 #

• 检查线上环境是否为.Net Core 3.1正确注册了AspNetCoreModuleV2模块，缺少这个模块的话，IIS无法处理.Net Core的请求，会返回404
• 对比其他正常子应用的web.config，确认sub-applicationNew的配置里是否正确引用了该模块，正确的配置片段如下：

<system.webServer>
  <handlers>
    <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
  </handlers>
  <aspNetCore processPath="dotnet" arguments=".\sub-applicationNew.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="inprocess" />
</system.webServer>

3. URL重写规则 #

• 检查services父应用或者sub-applicationNew自身的URL重写规则，有没有规则拦截了/api/public/test这条路径，导致请求没法正确路由到.Net Core应用
• 同时确认子应用代码里是否启用了UseRouting和UseEndpoints中间件，线上环境可能因为重写规则冲突导致路由失效

4. 目录浏览与默认文档设置 #

• 线上访问根路径返回403，大概率是因为IIS开启了目录浏览，但sub-applicationNew没有默认文档，且目录浏览权限被拒绝；替换正常应用文件后，正常应用有默认文档或允许目录浏览，所以能访问。需要检查子应用的目录浏览是否禁用（Web API不需要这个功能），同时确认有没有错误配置默认文档

5. 父应用配置继承问题 #

• 检查services父应用的web.config里有没有诸如authorization、handlers之类的配置被子应用继承，导致子应用的请求被拦截，引发403或404。可以在子应用的web.config里添加<location path="." inheritInChildApplications="false" />来阻断不必要的配置继承

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