ASP.NET Core 6 Web API独立站正常，作为IIS子应用无响应问题排查

一、权限验证（针对ApplicationPoolIdentity） #

• 手动核验文件夹权限：打开API部署文件夹的属性→安全→编辑→添加，输入IIS AppPool\[你的应用池名称]（替换为实际名称），确认已授予读取&执行、列出文件夹内容、读取权限；进入高级设置，确保权限应用到所有子文件和文件夹。
• 检查权限继承：若部署文件夹来自复制，查看安全→高级中的“继承”设置，确认未阻断权限向下传递。
• 测试静态文件访问：在API根目录放置test.html，用当前应用池身份访问https://主域名/子应用路径/test.html，验证是否能正常返回，排除IIS权限提示的误报可能。

二、路由与子应用路径匹配 #

• 配置路径基：在Program.cs中添加app.UsePathBase("/[子应用虚拟路径]")（例如子应用路径为/api则写/api），确保API路由正确适配子应用的虚拟路径。
• 排除主站点重写冲突：在WordPress主站点的web.config中，为URL重写规则添加条件：<add input="{REQUEST_URI}" pattern="^/[子应用路径]/.*" negate="true" />，避免WordPress的规则拦截子应用请求。
• 测试最简接口：在API中新增无参数GET接口：

  [HttpGet("health")]
  public IActionResult HealthCheck() => Ok("ok");
  

  直接访问https://主域名/子应用路径/health，验证基础路由是否正常响应。

三、IIS配置与ASP.NET Core模块检查 #

• 确认Hosting Bundle安装：Windows Server 2022需安装对应.NET 6版本的ASP.NET Core Hosting Bundle，确保IIS能识别并处理ASP.NET Core请求。
• 检查子应用web.config：确保aspNetCore节点配置正确，开启日志便于排查：

  <aspNetCore processPath="dotnet" arguments=".\YourApi.dll" stdoutLogEnabled="true" stdoutLogFile=".\logs\stdout" hostingModel="inprocess" />
  

• 验证HTTPS继承：主站点的HTTPS绑定需有效，子应用无需单独绑定HTTPS；确认主站点SSL设置中“要求SSL”选项未对子应用请求造成阻断。

四、请求跟踪与日志分析 #

• 开启IIS请求跟踪：选中子应用→功能视图→请求跟踪→启用，创建失败请求规则捕获无响应请求，查看跟踪日志定位请求卡住的环节。
• 查看ASP.NET Core stdout日志：检查部署文件夹下logs目录的日志，确认API是否正常启动、有无未捕获异常。
• 排查Windows事件日志：打开事件查看器→Windows日志→应用程序，查找ASP.NET Core 6.0.X或IIS Worker Process来源的错误事件，获取详细异常信息。

五、应用池与进程状态检查 #

• 确认应用池配置：应用池的.NET CLR版本设为“无托管代码”，管道模式为“集成”。
• 检查应用池运行状态：在IIS管理器中确认应用池状态为“正在运行”，若频繁停止，调整快速失败保护的阈值设置。
• 监控w3wp进程：打开任务管理器→详细信息，找到对应应用池的w3wp.exe进程，检查CPU、内存占用，确认进程是否在正常处理请求。

补充：LocalSystem下403.19错误排查 #

切换到LocalSystem出现403.19时，可尝试：

• 运行命令解锁处理程序：%windir%\system32\inetsrv\appcmd unlock config /section:system.webServer/handlers
• 检查请求筛选规则：在子应用的IIS请求筛选设置中，确保GET、POST等HTTP动词被允许。

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