Устранение ошибок 502 в ARR
Эта статья поможет устранить проблемы, связанные с ошибками 502 в маршрутизации запросов приложений (ARR).
Применимо к: Службы IIS
HTTP 502 — обзор
При работе с развертываниями маршрутизации запросов приложений IIS (ARR) может возникнуть ошибка "HTTP 502 — недопустимый шлюз". Ошибка 502.3 означает, что при выполнении роли прокси-сервера ARR не удалось выполнить запрос к серверу вышестоящий и отправить ответ клиенту. Эта проблема может возникнуть по нескольким причинам. Например, сбой подключения к серверу, отсутствие ответа от сервера или слишком долгое время ответа на запрос сервера (время ожидания). Если вы можете воспроизвести ошибку, просматривая веб-ферму с контроллера и включив подробные ошибки на сервере, может появиться сообщение об ошибке, похожее на следующее сообщение об ошибке:
Основная причина ошибки определяет, что необходимо сделать для устранения проблемы.
502.3. Ошибки времени ожидания
ARR использует код ошибки на предыдущем снимке экрана для прокси-сервера запроса и определения источника сбоя, так как он содержит код возврата из WinHTTP.
Код ошибки можно декодировать с помощью средства err.exe. В этом примере код ошибки сопоставляется с ERROR_WINHTTP_TIMEOUT. Эти сведения также можно найти в журналах IIS для связанного веб-сайта на контроллере ARR. Ниже приведен отрывок из записи журнала IIS для ошибки 502.3, с большинством полей, обрезанных для удобства чтения:
| sc-status | sc-substatus | sc-win32-status | время, затраченное |
|---|---|---|---|
| 502 | 3 | 12002 | 29889 |
Состояние win32 12002 сопоставляется с той же ERROR_WINHTTP_TIMEOUT ошибке, о чем сообщается на странице ошибки.
Что именно истекло время ожидания?
Это время ожидания можно проверка, включив трассировку неудачных запросов на сервере IIS. Первый момент, который можно увидеть в журнале трассировки неудачных запросов, и это место, куда был отправлен запрос в событии ARR_SERVER_ROUTED. Второй момент — это X-ARR-LOG-ID, который можно использовать для отслеживания запроса на целевом сервере. Это помогает отследить целевой или целевой объект HTTP-запроса:
77. ARR_SERVER_ROUTED RoutingReason="LoadBalancing", Server="192.168.0.216", State="Active", TotalRequests="3", FailedRequests="2", CurrentRequests="1", BytesSent="648", BytesReceived="0", ResponseTime="15225" 16:50:21.033
78. GENERAL_SET_REQUEST_HEADER HeaderName="Max-Forwards", HeaderValue="10", Replace="true" 16:50:21.033
79. GENERAL_SET_REQUEST_HEADER HeaderName="X-Forwarded-For", HeaderValue="192.168.0.204:49247", Replace="true" 16:50:21.033
80. GENERAL_SET_REQUEST_HEADER HeaderName="X-ARR-SSL", HeaderValue="", Replace="true" 16:50:21.033
81. GENERAL_SET_REQUEST_HEADER HeaderName="X-ARR-ClientCert", HeaderValue="", Replace="true" 16:50:21.033
82. GENERAL_SET_REQUEST_HEADER HeaderName="X-ARR-LOG-ID", HeaderValue="dbf06c50-adb0-4141-8c04-20bc2f193a61", Replace="true" 16:50:21.033
83. GENERAL_SET_REQUEST_HEADER HeaderName="Connection", HeaderValue="", Replace="true" 16:50:21.033
В следующем примере показано, как это может выглядеть в журналах трассировки неудачных запросов целевого сервера. Вы можете проверить, найден ли правильный запрос, сопоставив значения X-ARR-LOG-ID в обеих трассировках.
185. GENERAL_REQUEST_HEADERS Headers="Connection: Keep-Alive Content-Length: 0 Accept: */* Accept-Encoding: gzip, deflate Accept-Language: en-US Host: test Max-Forwards: 10 User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0) X-Original-URL: /time/ X-Forwarded-For: 192.168.0.204:49247 X-ARR-LOG-ID: dbf06c50-adb0-4141-8c04-20bc2f193a61
<multiple entries skipped for brevity>
345. GENERAL_FLUSH_RESPONSE_END BytesSent="0", ErrorCode="An operation was attempted on a nonexistent network connection. (0x800704cd)" 16:51:06.240
В предыдущем примере видно, что сервер ARR отключился перед отправкой HTTP-ответа. Метку времени для GENERAL_FLUSH_RESPONSE_END можно использовать в качестве грубого руководства для поиска соответствующей записи в журналах IIS на целевом сервере.
| date | time | s-ip | cs-method | cs-uri-stem | cs-uri-query | s-port | cs-username | sc-status | sc-substatus | sc-win32-status | время, затраченное |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 2011-07-18 | 16:51:06 | 192.168.0.216 | GET | /Время/ | - | 80 | - | 200 | 0 | 64 | 45208 |
Службы IIS на целевом сервере зарегистрировали код состояния HTTP 200, указывающий на успешное выполнение запроса. Кроме того, состояние win32 изменилось на 64, которое сопоставляется с ERROR_NETNAME_DELETED. Этот код состояния обычно указывает, что клиент (ARR в данном случае является клиентом) отключен до завершения запроса.
Причина
Сервер ARR сообщил об истечении времени ожидания, на которое следует обратить внимание в первую очередь.
Хотя журнал рядового сервера указывает, что ответ был отправлен за 45 секунд (45208 мс), запись журнала IIS с сервера ARR указывает, что время, затраченное на это, приближается к 30 секундам. Это означает, что ARR истекает время ожидания запроса, и вы можете подтвердить это, просмотрев время ожидания прокси-сервера в параметрах прокси-сервера фермы серверов. По умолчанию задано значение 30 секунд.
Таким образом, в этом случае можно четко увидеть, что время ожидания ARR было короче, чем выполнение запроса. Таким образом, может потребоваться проверка, чтобы узнать, было ли это время выполнения типичным или необходимо узнать, почему запрос занимает больше времени, чем ожидалось. Если это время выполнения было ожидаемым и нормальным, увеличение времени ожидания ARR должно устранить ошибку.
Другие возможные причины для ERROR_WINHTTP_TIMEOUT:
ResolveTimeout: происходит, если разрешение имен занимает больше времени, чем указанный период ожидания.ConnectTimeout: происходит, если подключение к серверу после разрешения имени занимает больше указанного времени ожидания.SendTimeout: происходит, если отправка запроса занимает больше времени, чем это значение времени ожидания. Операция отправки отменяется.ReceiveTimeout: происходит, если ответ занимает больше времени, чем это значение времени ожидания. Запрос отменен.
Если вы увидите первые две причины и ConnectTimeout, методология устранения неполадок, ResolveTimeout описанная ранее, не будет работать. Это связано с тем, что вы не увидите трафик на целевом сервере и, следовательно, не знаете код ошибки. Таким образом, в этом случае ResolveTimeoutConnectTimeout или может потребоваться записать трассировку WinHTTP для получения дополнительных сведений. Дополнительные примеры по устранению неполадок и трассировке см. в разделе трассировки WinHTTP или WEBIO и в следующих блогах:
- 502.3 Недопустимый шлюз "Истекло время ожидания операции" с маршрутизацией запросов приложений IIS (ARR)
- Параметры трассировки Winhttp для устранения неполадок с маршрутизацией запросов приложений
502.3. Ошибки завершения подключения
Ошибки 502.3 также возвращаются при отключении соединения между ARR и рядовой сервером в середине потока. Чтобы протестировать проблему этого типа, создайте .aspx страницу, которая вызывает Response.Close(). В следующем примере есть каталог с именем time, в котором .aspx страницу в качестве документа по умолчанию в этом каталоге. При попытке перейти к каталогу приложение ARR отображает следующее сообщение об ошибке:
Ошибка 0x80072efe соответствует ERROR_INTERNET_CONNECTION_ABORTED. Запрос можно отследить до сервера, который фактически обработал его, выполнив те же действия, которые использовались ранее в этом средстве устранения неполадок, за одним исключением. Хотя трассировка неудачных запросов на целевом сервере показывает запрос, обработанный на сервере, соответствующая запись журнала не отображается в журналах IIS. Вместо этого этот запрос регистрируется в журнале HTTPERR следующим образом:
HTTP/1.1 GET /time/ - 1 Connection_Dropped DefaultAppPool
Встроенные журналы на целевом сервере не предоставляют никаких дополнительных сведений о проблеме, поэтому следующим шагом будет сбор трассировки сети с сервера ARR. В предыдущем примере .aspx страница вызывается Response.Close() без возврата каких-либо данных. Просмотр этого в трассировке сети покажет, что http-заголовок Connection: close поступает с целевого сервера. С помощью этих сведений можно начать исследование причин отправки Connection: close заголовка.
Следующая ошибка является еще одним примером недопустимого ответа от рядового сервера:
В этом примере ARR начал получать данные от клиента, но что-то пошло не так при чтении текста сущности запроса. Это привело к возврату кода ошибки 0x80072f78. Для дальнейшего изучения используйте монитор сети на рядовом сервере, чтобы получить сетевую трассировку проблемы. Этот конкретный пример ошибки был создан путем вызова Response.Close() на странице ASP.net после отправки части ответа, а затем вызова Response.Flush(). Если трафик между сервером ARR и рядовой сервером осуществляется по протоколу SSL, то трассировка WinHTTP в Windows Server 2008 или трассировка WebIO в Windows Server 2008 R2 может предоставить дополнительные сведения. Трассировка WebIO описана далее в этом средстве устранения неполадок.
502.4 Не удалось найти соответствующий сервер для маршрутизации запроса
Ошибка HTTP 502.4 со связанным кодом ошибки 0x00000000 обычно указывает на то, что все члены фермы находятся в автономном режиме или недоступны иным образом.
Сначала необходимо убедиться, что рядовые серверы подключены к сети. Чтобы проверка это, перейдите в узел Серверы в ферме в диспетчере IIS.
Чтобы вернуть автономные серверы, щелкните правой кнопкой мыши имя сервера и выберите Добавить в балансировку нагрузки. Если не удается вернуть серверы в режим "в сети", проверьте, доступны ли рядовые серверы с сервера ARR. Проверьте область сообщения трассировки на странице Серверы , чтобы найти некоторые подсказки о проблеме. Если вы используете платформу веб-фермы (WFF) 2.0, вы можете получить эту ошибку при перезапуске пула приложений. Для восстановления необходимо перезапустить службу веб-фермы.
Трассировка WinHTTP или WebIO
Обычно средства отслеживания пакетов, такие как WireShark , предоставляют сведения, необходимые для точного определения времени ожидания. Однако в некоторых случаях (например, когда трафик зашифрован по протоколу SSL), вам потребуется использовать другой подход. Начиная с Windows 7 и Windows Server 2008 R2, вы можете включить трассировку WinHTTP с помощью средства netsh, выполнив следующую команду из командной строки администратора:
netsh trace start scenario=internetclient capture=yes persistent=no level=verbose tracefile=c:\temp\net.etl
Затем воспроизведите проблему. После воспроизведения проблемы остановите трассировку, выполнив следующую команду:
netsh trace stop
Выполнение stop команды занимает несколько секунд. По завершении вы найдете файл net.etl и файлnet.cab в C:\temp. Перед выполнением приведенных выше команд необходимо убедиться, что C:\temp папка существует. Файл .cab содержит журналы событий и другие данные, которые могут оказаться полезными при анализе ETL-файла.
Чтобы проанализировать журнал, выполните следующие действия:
Откройте его в Netmon 3.4 или более поздней версии.
Убедитесь, что вы настроили профиль средства синтаксического анализа. Для этого откройте меню Сервис>Параметры, выберите вкладку >Профили синтаксического анализа Профиль Windows, а затем нажмите кнопку Задать как активное, чтобы применить изменения.
Прокрутите трассировку, пока не найдете экземплярw3wp.exe , где выполняется ARR, путем сопоставления со столбцом имени процесса UT .
Щелкните правой кнопкой мыши w3wp и выберите Добавить имя процесса UT, чтобы отобразить фильтр. Это задает фильтр отображения, аналогичный следующему:
UTProcessName == "w3wp.exe (1432)"
Вы можете дополнительно отфильтровать результаты, изменив их следующим образом:
UTProcessName == "w3wp.exe (<pid>)" AND ProtocolName == "WINHTTP_MicrosoftWindowsWinHttp"
Прокрутите выходные данные, пока не обнаружите ошибку времени ожидания. В следующем примере истекло время ожидания запроса, так как для выполнения потребовалось более 30 секунд (время ожидания ARR по умолчанию).
336 2:32:22 PM 7/22/2011 32.6380453 w3wp.exe (1432) WINHTTP_MicrosoftWindowsWinHttp WINHTTP_MicrosoftWindowsWinHttp:12:32:23.123 ::sys-recver starts in _INIT state
337 2:32:22 PM 7/22/2011 32.6380489 w3wp.exe (1432) WINHTTP_MicrosoftWindowsWinHttp WINHTTP_MicrosoftWindowsWinHttp:12:32:23.123 ::current thread is not impersonating
340 2:32:22 PM 7/22/2011 32.6380584 w3wp.exe (1432) WINHTTP_MicrosoftWindowsWinHttp WINHTTP_MicrosoftWindowsWinHttp:12:32:23.123 ::sys-recver processing WebReceiveHttpResponse completion (error-cdoe = ? (0x5b4), overlapped = 003728F0)
341 2:32:22 PM 7/22/2011 32.6380606 w3wp.exe (1432) WINHTTP_MicrosoftWindowsWinHttp WINHTTP_MicrosoftWindowsWinHttp:12:32:23.123 ::sys-recver failed to receive headers; error = ? (1460)
342 2:32:22 PM 7/22/2011 32.6380800 w3wp.exe (1432) WINHTTP_MicrosoftWindowsWinHttp WINHTTP_MicrosoftWindowsWinHttp:12:32:23.123 ::ERROR_WINHTTP_FROM_WIN32 mapped (?) 1460 to (ERROR_WINHTTP_TIMEOUT) 12002
343 2:32:22 PM 7/22/2011 32.6380829 w3wp.exe (1432) WINHTTP_MicrosoftWindowsWinHttp WINHTTP_MicrosoftWindowsWinHttp:12:32:23.123 ::sys-recver returning ERROR_WINHTTP_TIMEOUT (12002) from RecvResponse()
344 2:32:22 PM 7/22/2011 32.6380862 w3wp.exe (1432) WINHTTP_MicrosoftWindowsWinHttp WINHTTP_MicrosoftWindowsWinHttp:12:32:23.123 ::sys-req completes recv-headers inline (sync); error = ERROR_WINHTTP_TIMEOUT (12002)
В следующем примере сервер содержимого полностью находится в автономном режиме:
42 2:26:39 PM 7/22/2011 18.9279133 WINHTTP_MicrosoftWindowsWinHttp WINHTTP_MicrosoftWindowsWinHttp:12:26:39.704 ::WinHttpReceiveResponse(0x11d23d0, 0x0) {WINHTTP_MicrosoftWindowsWinHttp:4, NetEvent:3}
43 2:26:39 PM 7/22/2011 18.9279633 WINHTTP_MicrosoftWindowsWinHttp WINHTTP_MicrosoftWindowsWinHttp:12:26:39.704 ::sys-recver starts in _INIT state {WINHTTP_MicrosoftWindowsWinHttp:4, NetEvent:3}
44 2:26:39 PM 7/22/2011 18.9280469 WINHTTP_MicrosoftWindowsWinHttp WINHTTP_MicrosoftWindowsWinHttp:12:26:39.704 ::current thread is not impersonating {WINHTTP_MicrosoftWindowsWinHttp:4, NetEvent:3}
45 2:26:39 PM 7/22/2011 18.9280776 WINHTTP_MicrosoftWindowsWinHttp WINHTTP_MicrosoftWindowsWinHttp:12:26:39.704 ::sys-recver processing WebReceiveHttpResponse completion (error-cdoe = WSAETIMEDOUT (0x274c), overlapped = 003728F0) {WINHTTP_MicrosoftWindowsWinHttp:4, NetEvent:3}
46 2:26:39 PM 7/22/2011 18.9280802 WINHTTP_MicrosoftWindowsWinHttp WINHTTP_MicrosoftWindowsWinHttp:12:26:39.704 ::sys-recver failed to receive headers; error = WSAETIMEDOUT (10060) {WINHTTP_MicrosoftWindowsWinHttp:4, NetEvent:3}
47 2:26:39 PM 7/22/2011 18.9280926 WINHTTP_MicrosoftWindowsWinHttp WINHTTP_MicrosoftWindowsWinHttp:12:26:39.704 ::ERROR_WINHTTP_FROM_WIN32 mapped (WSAETIMEDOUT) 10060 to (ERROR_WINHTTP_TIMEOUT) 12002 {WINHTTP_MicrosoftWindowsWinHttp:4, NetEvent:3}
48 2:26:39 PM 7/22/2011 18.9280955 WINHTTP_MicrosoftWindowsWinHttp WINHTTP_MicrosoftWindowsWinHttp:12:26:39.704 ::sys-recver returning ERROR_WINHTTP_TIMEOUT (12002) from RecvResponse() {WINHTTP_MicrosoftWindowsWinHttp:4, NetEvent:3}
Другие ресурсы
- Средство поиска ошибок
- Коды ошибок Winhttp
- Трассировка неудачных запросов
- Трассировка Winhttp
- Сетевой монитор
Заявление об отказе от ответственности за сведения о продуктах сторонних производителей
В этой статье упомянуты программные продукты независимых производителей. Корпорация Майкрософт не дает никаких гарантий, подразумеваемых и прочих, относительно производительности и надежности этих продуктов.
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по