Как найти причину ошибки 403.18 в IIS?

Я установил новое приложение под IIS. Новое приложение имеет выделенный пул приложений, как и многие другие приложения, установленные на том же сервере. Существует корневой веб-сайт, который также имеет собственный выделенный пул приложений. Все ранее развернутые приложения нормально работают в этой конфигурации, но самое новое приложение вызывает ошибку 403.18, когда я пытаюсь перейти к нему.

Если я перехожу к нему из сеанса RDP на сервере, я получаю подробную страницу ошибки, которая включает следующую информацию:

Ошибка HTTP 403.18 — Запрещено

Указанный запрос не может быть обработан в пуле приложений, который настроен для этого ресурса на веб-сервере.

Наиболее вероятные причины:

• Фильтр 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 установлен.

Я пытался следовать списку «Вещи, которые вы можете попробовать» на странице ошибки, и они, похоже, не применяются.

Есть ли какие-либо другие шаги, которые я могу попробовать, или подсказки, которые могут помочь мне найти основную причину этого? Я рад предоставить более подробную информацию, но я еще не уверен, какие детали относятся к делу.

Наконец-то я наткнулся на причину этой ошибки. Имя затронутого приложения ранее было настроено как виртуальный каталог, и в файле applicationHost.config все еще была запись для него.

Самая новая версия была развернута как приложение. Были и другие устаревшие записи для имени приложения в файле applicationHost.config.

Что выдало это, так это то, что я попытался развернуть приложение под новым именем, и оно сработало. Это показалось странным, поэтому я сравнил applicationHost.config между сервером, на котором приложение вызывало ошибку 403.18, и сервером разработки, где оно работало нормально.

Настоящая основная причина этой ошибки заключается в том, что мы клонировали рабочий веб-сервер и сделали его тестовым веб-сервером. Эти недопустимые записи присутствовали на рабочем сервере. Тем не менее, это сработало к лучшему, потому что в противном случае мы бы не столкнулись с ошибкой 403.18, пока не развернемся в рабочей среде.

Таким образом, проверка недопустимых записей в applicationHost.config является как минимум одним из шагов по устранению неполадок, которые можно выполнить для решения проблемы с 403.18.