ARR에서 502 오류 문제 해결
이 문서는 ARR(애플리케이션 요청 라우팅)의 502 오류와 관련된 문제를 resolve 데 도움이 됩니다.
적용 대상: 인터넷 정보 서비스
HTTP 502 - 개요
IIS ARR(애플리케이션 요청 라우팅) 배포를 사용하는 경우 발생할 수 있는 오류 중 하나는 "HTTP 502 - 잘못된 게이트웨이"입니다. 502.3 오류는 프록시 역할을 하는 동안 ARR이 업스트림 서버에 대한 요청을 완료하고 클라이언트에 응답을 다시 보낼 수 없음을 의미합니다. 이 문제는 여러 가지 이유로 발생할 수 있습니다. 예를 들어 서버에 연결하지 못하거나 서버의 응답이 없거나 서버가 응답하는 데 너무 오래 걸렸습니다(시간 초과). 컨트롤러에서 웹 팜을 검색하여 오류를 재현할 수 있고 서버에서 자세한 오류를 사용하도록 설정한 경우 다음 오류 메시지와 유사한 오류가 표시될 수 있습니다.
오류의 근본 원인은 문제를 resolve 위해 수행해야 하는 작업을 결정합니다.
502.3 시간 제한 오류
ARR은 이전 스크린샷의 오류 코드를 사용하여 요청을 프록시하고 WinHTTP의 반환 코드를 포함하기 때문에 실패의 원인을 확인합니다.
err.exe도구를 사용하여 오류 코드를 디코딩할 수 있습니다. 이 예제에서 오류 코드는 ERROR_WINHTTP_TIMEOUT 매핑됩니다. 이 정보는 ARR 컨트롤러의 연결된 웹 사이트에 대한 IIS 로그에서도 찾을 수 있습니다. 다음은 502.3 오류에 대한 IIS 로그 항목에서 발췌한 것으로, 대부분의 필드가 가독성을 위해 잘립니다.
| sc-상태 | sc-substatus | sc-win32-상태 | 시간이 소요되었습니다. |
|---|---|---|---|
| 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
이전 예제에서는 HTTP 응답을 보내기 전에 ARR 서버의 연결이 끊어진 것을 확인할 수 있습니다. GENERAL_FLUSH_RESPONSE_END 대한 타임스탬프를 대략적인 가이드로 사용하여 대상 서버의 IIS 로그에서 해당 항목을 찾을 수 있습니다.
| date | 시간 | s-ip | cs-method | cs-uri-stem | cs-uri-query | s-port | cs-username | sc-상태 | sc-substatus | sc-win32-상태 | 시간이 소요되었습니다. |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 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초(45208ms)로 전송되었음을 나타내지만 ARR 서버의 IIS 로그 항목은 소요 시간이 30초에 매우 가깝다는 것을 나타냅니다. 이는 ARR이 요청 시간을 초과하고 있음을 나타내며 서버 팜의 프록시 설정에서 프록시 시간 제한을 확인하여 이를 확인할 수 있습니다. 기본적으로 30초로 설정됩니다.
따라서 이 경우 ARR 시간 제한이 요청 실행보다 짧다는 것을 분명히 알 수 있습니다. 따라서 이 실행 시간이 일반적인지 또는 요청이 예상보다 오래 걸리는 이유를 확인해야 하는지 확인하기 위해 검사 수 있습니다. 이 실행 시간이 예상되고 정상인 경우 ARR 시간 제한을 늘리면 오류가 resolve.
ERROR_WINHTTP_TIMEOUT 다른 가능한 이유는 다음과 같습니다.
ResolveTimeout: 이름 확인이 지정된 시간 제한 기간보다 오래 걸리는 경우에 발생합니다.ConnectTimeout: 이름이 확인된 후 서버에 연결하는 데 지정된 시간 제한 기간보다 오래 걸리는 경우에 발생합니다.SendTimeout: 요청을 보내는 데 이 제한 시간 값보다 오래 걸리는 경우 발생합니다. 보내기 작업이 취소되었습니다.ReceiveTimeout: 응답이 이 제한 시간 값보다 오래 걸리는 경우 발생합니다. 요청이 취소되었습니다.
처음 두 가지 이유인 ResolveTimeout 및 ConnectTimeout을 관찰하면 이전에 설명한 문제 해결 방법론이 작동하지 않습니다. 대상 서버에 트래픽이 표시되지 않으므로 오류 코드를 알 수 없기 때문입니다. 따라서 이 경우 또는 ConnectTimeout 의 경우 ResolveTimeout 추가 인사이트를 위해 WinHTTP 추적을 캡처할 수 있습니다. 문제 해결 및 추적에 대한 다른 예제는 WinHTTP 또는 WEBIO 추적 섹션 및 다음 블로그를 참조하세요.
502.3 연결 종료 오류
502.3 오류는 ARR과 멤버 서버 간의 연결이 스트림 중간에 연결이 끊어질 때도 반환됩니다. 이러한 유형의 문제를 테스트하려면 를 호출 Response.Close()하는 .aspx 페이지를 만듭니다. 다음 예제에는 해당 디렉터리의 기본 문서로 .aspx 페이지로 구성된 "time"이라는 디렉터리가 있습니다. 디렉터리로 이동하려고 하면 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 오류 코드가 반환되었습니다. 자세히 조사하려면 멤버 서버의 네트워크 모니터 를 사용하여 문제의 네트워크 추적을 가져옵니다. 이 특정 오류 예제는 응답의 일부를 보낸 후 ASP.net 페이지에서 를 호출 Response.Close() 한 다음 를 호출Response.Flush()하여 만들었습니다. ARR 서버와 멤버 서버 간의 트래픽이 SSL을 초과하면 Windows Server 2008 또는 Windows Server 2008 R2의 WebIO 추적에서 WinHTTP 추적이 추가 정보를 제공할 수 있습니다. WebIO 추적은 이 문제 해결사 뒷부분에서 설명합니다.
502.4 요청을 라우팅할 적절한 서버를 찾을 수 없습니다.
연결된 오류 코드가 0x00000000 HTTP 502.4 오류는 일반적으로 팜의 모든 멤버가 오프라인이거나 연결할 수 없음을 나타냅니다.
첫 번째 단계는 멤버 서버가 온라인인지 확인하는 것입니다. 이를 검사 IIS 관리자의 팜 아래에 있는 서버 노드로 이동합니다.
오프라인 서버를 다시 가져오려면 서버 이름을 마우스 오른쪽 단추로 클릭하고 부하 분산에 추가를 선택합니다. 서버를 다시 온라인 상태로 만들 수 없는 경우 ARR 서버에서 구성원 서버에 연결할 수 있는지 확인합니다. 서버 페이지에서 추적 메시지 창을 확인하여 문제에 대한 몇 가지 단서를 찾습니다. WFF(Web Farm Framework) 2.0을 사용하는 경우 애플리케이션 풀이 다시 시작될 때 이 오류가 나타날 수 있습니다. 복구하려면 웹 팜 서비스를 다시 시작해야 합니다.
WinHTTP 또는 WebIO 추적
일반적으로 WireShark 와 같은 패킷 캡처 도구는 타이밍을 정확히 파악하는 데 필요한 정보를 제공합니다. 그러나 트래픽이 SSL 암호화되는 경우와 같이 다른 방법을 시도해야 하는 경우가 있습니다. Windows 7 및 Windows Server 2008 R2부터 관리 명령 프롬프트에서 다음 명령을 실행하여 netsh 도구를 사용하여 WinHTTP 추적을 사용하도록 설정할 수 있습니다.
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 프로필을 선택한 다음 활성 으로 설정 단추를 선택하여 변경 내용을 적용합니다.
UT 프로세스 이름 열과 상관 관계를 지정하여 ARR이 실행되는 w3wp.exe instance 찾을 때까지 추적을 스크롤합니다.
w3wp를 마우스 오른쪽 단추로 클릭하고 필터를 표시할 UT 프로세스 이름 추가를 선택합니다. 이렇게 하면 다음과 유사한 표시 필터가 설정됩니다.
UTProcessName == "w3wp.exe (1432)"
결과를 다음으로 변경하여 추가로 필터링할 수 있습니다.
UTProcessName == "w3wp.exe (<pid>)" AND ProtocolName == "WINHTTP_MicrosoftWindowsWinHttp"
시간 제한 오류가 발견될 때까지 출력을 스크롤해야 합니다. 다음 예제에서는 ARR의 기본 시간 제한(ARR의 기본 시간 제한)을 실행하는 데 30초 이상이 걸렸기 때문에 요청 시간이 초과되었습니다.
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}
다른 리소스
타사 정보 고지 사항
이 문서에 나와 있는 다른 공급업체 제품은 Microsoft와 무관한 회사에서 제조한 것입니다. Microsoft는 이들 제품의 성능이나 안정성에 관하여 명시적이든 묵시적이든 어떠한 보증도 하지 않습니다.
피드백
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기