Устранение ошибок 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 на целевом сервере.
| Дата | Время | 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 описанной ранее, не будет работать. Это связано с тем, что трафик на целевом сервере не отображается и поэтому не будет знать код ошибки. Таким образом, в этом случае может потребоваться записать трассировку WinHTTP для получения дополнительных ResolveTimeout ConnectTimeout сведений. См. раздел трассировки 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() без возврата данных. При просмотре этого в трассировке сети показано, что Connection: close заголовок HTTP поступает с целевого сервера. С помощью этой информации можно начать расследование причин отправки заголовка 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. Проверьте область "Сообщения трассировки" на странице "Серверы", чтобы найти некоторые подсказки о проблеме. Если вы используете web Farm Framework (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
- Сетевой монитор
Заявление об отказе от ответственности за сведения о продуктах сторонних производителей
В этой статье упомянуты программные продукты независимых производителей. Корпорация Майкрософт не дает никаких гарантий, подразумеваемых и прочих, относительно производительности и надежности этих продуктов.