我在 IIS 下安装了一个新应用程序。与安装在同一台服务器上的许多其他应用程序一样，新应用程序也有一个专用的应用程序池。根网站也有自己的专用应用程序池。在此配置下，所有以前部署的应用程序都运行良好，但当我尝试浏览最新的应用程序时，它会导致 403.18 错误。
如果我从服务器上的 RDP 会话浏览它，我会得到包含此信息的详细错误页面：
HTTP 错误 403.18 - 禁止访问
无法在 Web 服务器上为此资源配置的应用程序池中处理指定的请求。
最可能的原因：
- ISAPI 筛选器或自定义模块将 URL 更改为在与原始 URL 不同的应用程序池中运行。
- ISAPI 扩展（或自定义模块）使用 ExecuteURL（或 ExecuteRequest）在与原始 URL 不同的应用程序池中运行。
- 您有一个自定义错误页面，它位于一个应用程序池中，但被另一个应用程序池中的网站引用。处理 URL 时，IIS 确定它应该在第一个应用程序池中处理，而不是另一个池。
- 该网站配置了多个应用程序。配置此请求在其中运行的应用程序被设置为在不存在的应用程序池中运行。
您可以尝试以下操作：
- 如果您的应用程序正在尝试处理另一个应用程序池中的 URL（例如，尝试处理自定义错误），请确保它们都在同一个应用程序池中运行（如果合适）。
- 如果您尝试处理位于另一个应用程序池中的自定义错误 URL，请启用自定义错误重定向功能。
- 验证该应用程序的应用程序池是否存在。
- 创建跟踪规则以跟踪此 HTTP 状态代码的失败请求，并查看是否正在调用 ExecuteURL。有关为失败请求创建跟踪规则的更多信息，请单击此处。
我运行了失败请求跟踪，但它基本上重复了相同的信息，似乎没有提供任何见解。我承认我并不了解该跟踪文件中的所有内容。
我尝试将根站点的应用程序池更改为与新部署的应用程序相同的池。这清除了 403.18 错误，因此应用程序和根站点之间的应用程序池差异似乎与此有关。但是，应用程序没有加载，浏览器只是在物理路径内容上列出目录。
奇怪的是，此服务器上的许多其他应用程序运行良好。新应用程序的最大区别在于它使用 .NET 5 和 Azure AD 身份验证。其他应用程序使用以前版本的 .NET Core 或 .NET Framework 和 Windows 身份验证。我已验证已安装 .NET 5 Hosting Bundle。
我确实尝试按照错误页面中的“您可以尝试的事情”列表进行操作，但似乎不适用。
还有其他我可以尝试的步骤或线索可以帮助我找到这个问题的根本原因吗？我很乐意提供更多细节，但我还不确定哪些细节是相关的。
答案1
好吧，我终于偶然发现了这个错误的原因。受影响的应用程序的名称之前已配置为虚拟目录，并且 applicationHost.config 文件中仍有一个该条目。
最新版本已部署为应用程序。applicationHost.config 文件中的应用程序名称还有一些其他过时的条目。
暴露这一点的原因是，我尝试使用新名称部署应用程序，结果成功了。这似乎很奇怪，因此我将导致 403.18 错误的应用程序所在的服务器与正常运行的开发服务器之间的 applicationHost.config 进行了比较。
此错误的真正根源在于我们克隆了生产 Web 服务器并将其作为测试 Web 服务器。这些无效条目存在于生产服务器中。不过，这在某种程度上是最好的结果，因为否则我们在部署到生产环境之前不会遇到 403.18 错误。
因此，检查 applicationHost.config 中的无效条目至少是解决 403.18 问题的故障排除步骤之一。