Поделиться через


Устранение ошибок HTTP 4xx и 5xx

В этой статье приведены инструкции по устранению ошибок кода состояния HTTP 4xx и 5xx в службы IIS (IIS). Коды состояния 4xx указывают на проблему на стороне клиента, а коды состояния 5xx указывают на проблему на стороне сервера. Рекомендации помогут определить причину этих ошибок и устранить их эффективно.

Определение ошибок 4xx

Коды состояния HTTP 4xx указывают на то, что произошла ошибка из-за проблемы на стороне клиента. Например, браузер клиента может запросить страницу, которая не существует, или браузер клиента, возможно, не предоставил допустимые сведения о проверке подлинности.

Чтобы определить 4xx ошибок, изучите журналы IIS и журналы HTTPERR:

  • Код состояния HTTP записывается в журналы IIS. Этот файл обычно хранится в C:\inetpub\logs\Logfiles, но можно настроить с помощью ведения журнала IIS в диспетчере IIS.

  • Код ошибки 4xx может быть создан драйвером ядра HTTP.sys , что означает, что эти запросы могут не добраться до СЛУЖБ IIS, поэтому не будут входить в журналы IIS. HTTP.sys регистрирует эти ошибки в отдельных файлах, называемых журналами HTTPERR. Этот файл обычно хранится в C:\Windows\System32\LogFiles\HTTPERR , но его можно настроить с помощью реестра HKEY\LOCAL\MACHINE\System\CurrentControlSet\Services\HTTP\Parameters\ErrorLoggingDir.

  • Один из способов подтвердить, поступает ли ответ 4xx из HTTP.sys , — собрать файл трассировки HAR на клиенте и найти заголовок ответа Microsoft-HttpApi/2.0.

    Чтобы записать файл трассировки HAR, который записывает взаимодействие браузера с веб-сайтом, следуйте инструкциям в разделе "Запись трассировки браузера" для устранения неполадок.

Проверка журналов IIS

При обнаружении ошибок в журналах IIS обратите внимание на код состояния (sc-status) и код подстатуса (sc-substatus) и ознакомьтесь с общими сведениями о коде состояния HTTP.

Чтобы получить дополнительные сведения о коде состояния и понять, какой модуль или обработчик вернул ошибки 4xx , соберите журналы трассировки неудачных запросов (FREB) в течение времени возникновения проблемы, настроив правило FREB для активации кодом состояния, отображаемым в журналах IIS.

Проверка журналов HTTPERR

Если вы найдете ошибки в журналах HTTPERR, обратите внимание на причину (s-reason) и см . сведения о типах ошибок, зарегистрированных API HTTP-сервера.

Определение ошибок 5xx

Коды состояния HTTP 5xx указывают на то, что сервер не мог завершить запрос, так как сервер столкнулся с ошибкой при обработке запроса. Используйте следующие инструкции на основе типа приложения.

500 ошибок в классическом ASP

Если ошибка 500 возникает в классическом ASP, проверьте код ошибки или сообщение об ошибке в cs-uri-query запросе журналов IIS.

Дополнительные сведения см. в журналах трассировки неудачных запросов (FREB) для 500 ошибок.

500 ошибок в общих службах IIS

Если ошибка 500 возникает в общих службах IIS, изучите журналы IIS, запишите код состояния (sc-status) и код подстатуса (sc-substatus) и ознакомьтесь с общими сведениями о сбое кода состояния HTTP.

Включите подробные сообщения об ошибках, если это возможно, чтобы получить дополнительные сведения. Чтобы включить подробные сообщения об ошибках, выполните следующие действия.

  1. Откройте окно командной строки run .

  2. Запустите inetmgr.

  3. В диспетчере IIS в области "Подключения", расположенной слева от консоли, разверните имя компьютера, разверните узел "Сайты", а затем выберите целевой веб-сайт.

    Снимок экрана: целевой веб-сайт в диспетчере IIS.

  4. Дважды щелкните значок страниц ошибок на средней панели.

    Снимок экрана: значок страниц ошибок.

  5. Справа в области "Действия " выберите "Изменить параметры компонентов".

    Снимок экрана: параметр

  6. В диалоговом окне "Изменение параметров страниц ошибок" (где вы выбираете отправку локальных и удаленных запросов), вторая кнопка — это то, что необходимо выбрать для возврата подробных ошибок для локальных и удаленных запросов. По умолчанию для отправки подробных ошибок, отправленных только для локальных запросов, выбран нижний параметр.

    Снимок экрана: диалоговое окно

    Мы не рекомендуем отправлять подробные ошибки для удаленных запросов, так как этот параметр может предоставлять конфиденциальную информацию в Интернете. После получения дополнительных сведений об ошибке необходимо вернуть изменения.

Дополнительные сведения см. в журналах трассировки неудачных запросов (FREB) для 500 ошибок.

500 ошибок в ASP.NET

Если ошибка 500 возникает в ASP.NET, используйте следующие методы, чтобы определить первопричину ошибки:

  • Проверьте журналы событий приложения.

    Проверьте журналы событий приложения во время возникновения проблемы. ASP.NET будет записывать сведения об ошибке, включая стек вызовов, в журналах событий приложения.

    Чтобы получить доступ к журналам событий приложения, выполните следующие действия.

    1. Откройте меню "Пуск", найдите Просмотр событий и выберите Просмотр событий.
    2. В средстве просмотра событий откройте узел Журналы Windows.
    3. Выберите приложение , чтобы открыть журналы событий приложения.
    4. Выполните поиск ошибок, связанных с неудачным приложением. Значением в столбце "Источник" для ошибок является модуль IIS AspNetCore или модуль IIS Express AspNetCore.
  • Захват дампов памяти.

    В некоторых случаях может потребоваться записать дамп памяти конкретного исключения, чтобы изучить сведения, связанные с исключением, вызвавшего состояние HTTP 500.

    Чтобы записать дампы, следуйте инструкциям в разделе "Сбор дампов памяти" для исключения первого шанса при возникновении.

    Используйте средство анализа DebugDiag 2 (часть набора DebugDiag ) с правилом CrashHangAnalysis в собранных дампах, чтобы создать отчет, который можно использовать для просмотра стека вызовов и определения первопричины.

    Чтобы создать отчет с помощью средства анализа DebugDiag, выполните следующие действия.

    1. Откройте анализ DebugDiag 2.
    2. Выберите " Добавить файлы данных" и добавьте файлы .dmp .
    3. Выберите CrashHangAnalysis и PerfAnalysis и нажмите кнопку "Начать анализ".

    По завершении отчет (MHT) будет создан в C:\Program Files\DebugDiag\Reports и отображается в Internet Explorer с результатами и рекомендациями.

    При использовании пользовательских библиотек DLL можно указать путь поиска символов для пользовательских PDB-файлов, выполнив следующие действия.

    1. Откройте средство коллекции DebugDiag 2.
    2. Выберите параметры инструментов и папки параметров> поиска.>
    3. В разделе "Путь поиска символов" для отладки нажмите кнопку "Обзор ", чтобы задать путь.
  • Захват трассировки Perfview для выявления проблем ExecutionTimeout.

    Для 500 ошибок из-за превышения ASP.NET ExecutionTimeout зафиксируйте трассировку PerfView и дампы для выявления задержек.

500 ошибок в ASP.NET Core

Если ошибка 500 возникает в ASP.NET Core, используйте следующие методы, чтобы определить первопричину ошибки:

  • Проверьте журналы событий приложения.

    Чтобы получить доступ к журналам событий приложения, выполните следующие действия.

    1. Откройте меню "Пуск", найдите Просмотр событий и выберите Просмотр событий.
    2. В средстве просмотра событий откройте узел Журналы Windows.
    3. Выберите приложение , чтобы открыть журналы событий приложения.
    4. Выполните поиск ошибок, связанных с неудачным приложением. Значением в столбце "Источник" для ошибок является модуль IIS AspNetCore или модуль IIS Express AspNetCore.
  • Включите страницу исключений разработчика.

    Переменную ASPNETCORE_ENVIRONMENT среды можно добавить в web.config , чтобы запустить приложение в среде разработки. Если вы не переопределяете параметр среды в коде запуска приложения с помощью UseEnvironment метода в построителе узлов, переменная среды позволяет странице исключений разработчика отображаться при запуске приложения.

    <aspNetCore processPath="dotnet"
        arguments=".\MyApp.dll"
        stdoutLogEnabled="false"
        stdoutLogFile=".\logs\stdout"
        hostingModel="InProcess">
      <environmentVariables>
         <environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Development" />
      </environmentVariables>
    </aspNetCore>
    

    Установка переменной ASPNETCORE_ENVIRONMENT среды рекомендуется только на промежуточных и тестовых серверах, не предоставляемых Интернету. Завершив устранение неполадок, удалите эту переменную среды из файла web.config.

  • Включите журнал модуля ASP.NET Core stdout .

    Чтобы включить и просмотреть stdout журналы, выполните следующие действия.

    1. Перейдите в папку развертывания сайта на компьютере размещения.

    2. Если здесь нет папки logs, создайте ее. Инструкции по созданию папки журналов в развертывании msBuild см. в разделе ASP.NET Структура каталогов Core.

    3. Измените файл web.config. stdoutLogEnabled Задайте true и измените stdoutLogFile путь, чтобы указать папку журналов (например, .\logs\stdout), как показано ниже:

      <aspNetCore processPath="dotnet"
          arguments=".\App.dll"
          stdoutLogEnabled="true"
          stdoutLogFile=".\logs\stdout">
      </aspNetCore>
      
    4. Используйте stdout в качестве префикса имени файла. Метка времени, идентификатор процесса (PID) и расширение файла добавляются автоматически при создании журнала. Типичное имя файла журнала — stdout_<timestamp>_<PID>.log.

    5. Убедитесь, что удостоверение пула приложений имеет разрешения на запись в папку logs.

    6. Сохраните обновленный файл web.config.

    7. Отправьте запрос приложению.

    8. Перейдите в папку logs. Найдите и откройте последний stdout журнал.

    9. Изучите ошибки в журнале.

    Чтобы отключить ведение журнала при завершении stdout устранения неполадок, выполните следующие действия.

    1. Измените файл web.config.
    2. Задайте для параметра stdoutLogEnabled значение false.
    3. Сохраните файл.
  • Включите журнал отладки модуля ASP.NET Core (IIS).

    Чтобы включить журнал отладки модуля ASP.NET Core, добавьте следующие параметры обработчика в файл web.config приложения:

    <aspNetCore ...>
       <handlerSettings>
         <handlerSetting name="debugLevel" value="file" />
         <handlerSetting name="debugFile" value="c:\temp\ancm.log" />
       </handlerSettings>
    </aspNetCore>
    

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

Ошибки 502 в ARR

Если ошибка 502 возникает в маршрутизации запросов приложений (ARR), следуйте инструкциям в статье "Устранение ошибок 502 в ARR".

Ошибки 503

Если возникают ошибки 503, код подстатуса (sc-substatus) в журналах IIS или в s-reason HTTPERR может предоставить некоторые указания.

Дополнительные сведения см. в разделе:

Кроме того, ознакомьтесь со следующей статьей, в которой описана известная проблема, которая может привести к ошибкам 503:

HTTP-ответ 503 “Служба недоступна” от IIS: распространенная общая причина

Сбор данных

Действия по сбору журналов FREB

Внимание

Чтобы настроить журналы FREB, убедитесь, что служба роли трассировки установлена для СЛУЖБ IIS.

Чтобы установить службу роли трассировки для IIS, выполните следующие действия.

  1. Откройте диспетчер сервера и выберите пункт "Управление добавлением>ролей и компонентов".
  2. В окне мастера добавления ролей и компонентов нажмите кнопку "Далее", пока не перейдете на страницу "Роли сервера".
  3. Разверните >Работоспособность и диагностика>и установите флажок трассировки.
  4. Нажмите кнопку "Далее" для последующих шагов и нажмите кнопку "Установить".

После установки службы роли трассировки выполните следующие действия, чтобы записать FREB:

  1. Откройте окно командной строки run .

  2. Запустите inetmgr.

  3. В диспетчере IIS в области "Подключения" разверните имя компьютера, разверните узел "Сайты" и выберите целевой веб-сайт.

    Снимок экрана: целевой веб-сайт в диспетчере IIS.

  4. Дважды щелкните правила трассировки неудачных запросов.

    Снимок экрана: главная веб-сайт по умолчанию.

  5. В области "Действия" нажмите кнопку "Добавить".

  6. В мастере добавления правила трассировки неудачных запросов на странице "Указание содержимого для трассировки" выберите "Все содержимое>далее".

    Снимок экрана: страница

  7. На странице "Определение условий трассировки" обновите поле "Код состояния" до 400-600 и нажмите кнопку "Далее".

    Снимок экрана: страница

  8. На странице выбора поставщиков трассировки в разделе "Поставщики" установите все флажки. В разделе "Области" убедитесь, что для каждого поставщика выбраны все флажки. В разделе "Подробные сведения" выберите "Подробно". Нажмите Готово.

  9. Включите трассировку неудачных запросов для сайта и настройте каталог файла журнала:

    1. В области "Подключения" разверните имя компьютера, разверните узел "Сайты" и выберите "Веб-сайт по умолчанию".

    2. В области "Действия" в разделе "Настройка" выберите "Трассировка неудачных запросов".

      Снимок экрана: параметр трассировки неудачных запросов.

    3. В диалоговом окне "Изменение параметров трассировки неудачных запросов веб-сайта" установите флажок "Включить", установите для поля каталога значение %SystemDrive%\inetpub\logs\FailedReqLogFiles и задайте максимальное количество файлов трассировки равным 1000.

      Снимок экрана: окно параметров трассировки неудачного запроса на изменение веб-сайта.

    4. Нажмите кнопку ОК.

Действия по захвату трассировки и дампов PerfView

Чтобы записать трассировку и дампы PerfView, выполните действия, описанные в следующих разделах.

Настройка PerfView и Procdump перед проблемой

Прежде чем возникать проблема, выполните следующие действия, чтобы настроить PerfView и Procdump для сбора данных:

  1. Скачайте ProcDump. Это упрощенный исполняемый файл, который не требует установки и автоматизирует сбор дампов.

  2. Извлеките файл procdump.exe в определенную папку на сервере.

  3. Скачайте средство PerfView на сервере. Это средство профилировщика, которое фиксирует события трассировки событий Windows (ETW) (без необходимости установки).

  4. Чтобы PerfView предоставлял полезные сведения, добавьте трассировку в качестве службы ролей для IIS. Без включения трассировки трассировка трассировки ETW будет включать только HTTP.sys сведения. Если вы не уверены, установлена ли служба роли трассировки , выполните следующие действия:

    1. Откройте диспетчер сервера и выберите пункт "Управление добавлением>ролей и компонентов".
    2. В окне мастера добавления ролей и компонентов нажмите кнопку "Далее", пока не перейдете на страницу "Роли сервера".
    3. Разверните >Работоспособность и диагностика>и установите флажок трассировки.
    4. Нажмите кнопку "Далее" для последующих шагов и нажмите кнопку "Установить".
  5. Откройте средство PerfView, выберите меню "Собрать " и выберите параметр "Собрать ".

  6. Установите флажки "Zip", "Слияние" и "Время потока", как показано на следующем снимке экрана. Измените поле "Циклический МБ" на 2000:

    Снимок экрана: выбор zip, слияния и времени потока.

  7. Разверните вкладку "Дополнительные параметры" и установите флажок IIS , как показано на следующем снимке экрана.

    Снимок экрана: сбор данных по заданному пользователем интервалу.

    Если вы запускаете приложение ASP.NET Core, добавьте следующую строку в дополнительные поставщики:

    *Microsoft-Extensions-Logging:4:5,Microsoft-AspNetCore-Server-Kestrel,System.Net.Http,System.Net.Sockets,System.Net.NameResolution,System.Threading.Tasks.TplEventSource::5,Microsoft-System-Net-Http,Microsoft-Windows-Application Server-Applications::Verbose

    Примечание.

    Не пропустите звездочку (*) в начале.

Сбор данных во время проблемы

Во время проблемы выполните следующие действия, чтобы собрать данные:

  1. Нажмите кнопку "Пуск коллекции" в PerfView с параметрами конфигурации, настроенными в разделе " Настройка PerfView и Procdump".

  2. Откройте диспетчер служб IIS.

  3. Выберите имя сервера (слева).

  4. Дважды щелкните рабочие процессы , чтобы просмотреть идентификатор процесса служб. Например:

    Снимок экрана: рабочие процессы в диспетчере IIS.

  5. Откройте командную строку от имени администратора.

  6. Перейдите в папку, в которой procdump.exe извлекается, выполнив команду cd <path to procdump.exe> в окне командной строки .

  7. Выполните следующую команду, чтобы записать последовательные дампы.

    procdump.exe -accepteula -ma <PID of W3WP.exe)> -s 10 -n 3

    Примечание.

    Замените <PID of W3WP.exe> фактическим ИДЕНТИФИКАТОРом W3WP.exe процесса, который вы нашли на шаге 4.

    • В конце команды можно указать путь для хранения дампов в определенном расположении.
    • Эта команда захватывает три набора дампов через 10 секунд.
  8. После сбора дампов с помощью procdump остановите PerfView, выбрав "Остановить коллекцию" или подождите два с половиной минуты, чтобы остановить его автоматически. Разрешить PerfView объединить собранные данные, которые могут занять некоторое время. И он создаст файл Perfview.etl.zip . Если вы запрашиваете символы, выберите "Использовать серверы символов Майкрософт".

Дополнительная информация