針對 ARR 中的 502 錯誤進行疑難解答

發行項
12/14/2024

本文可協助您解決應用程式要求路由（ARR）中 502 個錯誤相關問題。

適用於：網際網路資訊服務

HTTP 502 - 概觀

當您使用 IIS 應用程式要求路由（ARR）部署時，您可能會看到的其中一個錯誤是「HTTP 502 - 不正確的閘道」。 502.3 錯誤表示當做 Proxy 時，ARR 無法完成上游伺服器的要求，並將回應傳回用戶端。此問題可能會因為多個原因而發生。例如，無法連線到伺服器、沒有來自伺服器的回應，或伺服器回應時間過長而無法回應（逾時）。如果您能夠透過從控制器瀏覽 Web 伺服器陣列來重現錯誤，並在伺服器上啟用詳細的錯誤，您可能會看到類似下列錯誤訊息的錯誤：

此螢幕快照顯示伺服器上啟用詳細錯誤時所顯示的詳細 502 錯誤。

錯誤的根本原因會決定您應該執行哪些動作來解決問題。

502.3 逾時錯誤

ARR 使用上述螢幕快照中的錯誤碼來 Proxy 要求，並判斷失敗的來源，因為它包含來自 WinHTTP 的傳回碼。

您可以使用工具 err.exe譯碼錯誤碼。在此範例中，錯誤碼會對應至 ERROR_WINHTTP_TIMEOUT。您也可以在 ARR 控制器上相關聯網站的 IIS 記錄中找到此資訊。以下是 502.3 錯誤的 IIS 記錄專案摘錄，其中大部分欄位已修剪為可讀性：

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 毫秒）傳送，但 ARR 伺服器的 IIS 記錄專案表示所花費的時間非常接近 30 秒。這表示 ARR 已逾時要求，而且您可以藉由查看伺服器陣列 Proxy 設定中的 Proxy 逾時來確認這一點。根據預設，它會設定為30秒。

因此，在此情況下，您可以清楚地看到ARR逾時比執行要求還要短。因此，您可能想要檢查此運行時間是否為一般，或您是否需要查看要求花費的時間超過預期的原因。如果預期有此運行時間且正常，增加ARR逾時應該解決錯誤。

ERROR_WINHTTP_TIMEOUT的其他可能原因包括：

ResolveTimeout：如果名稱解析所花費的時間超過指定的逾時期間，就會發生。
ConnectTimeout：如果在解析名稱之後連線到伺服器所花費的時間超過指定的逾時期間，就會發生。
SendTimeout：如果傳送要求的時間超過這個逾時值，就會發生。傳送作業已取消。
ReceiveTimeout：如果響應花費的時間超過這個逾時值，就會發生。要求已取消。

當您觀察前兩個原因和 ConnectTimeout時，ResolveTimeout先前概述的疑難解答方法將無法運作。這是因為您不會在目標伺服器上看到任何流量，因此並不知道錯誤碼。因此，在此情況下 ResolveTimeout ，或 ConnectTimeout 您可能想要擷取 WinHTTP 追蹤以取得其他見解。如需疑難解答和追蹤的其他範例，請參閱 WinHTTP 或 WEBIO 追蹤一節和下列部落格：

502.3 連線終止錯誤

當 ARR 與成員伺服器之間的連線中斷時，也會傳回 502.3 錯誤。若要測試這種類型的問題，請建立呼叫 Response.Close()的.aspx頁面。在下列範例中，有一個名為「time」的目錄，其設定為該目錄中的預設檔.aspx頁面。當您試著瀏覽至目錄時，ARR 會顯示下列錯誤訊息：

顯示連線終止錯誤的螢幕快照。

錯誤0x80072efe對應至ERROR_INTERNET_CONNECTION_ABORTED。此要求可以追蹤到使用此疑難解答員稍早所使用的相同步驟來處理要求的伺服器，但有一個例外狀況。當目的地伺服器上的失敗要求追蹤顯示伺服器上處理的要求時，相關聯的記錄專案不會出現在 IIS 記錄中。相反地，此要求會記錄在 HTTPERR 記錄檔中，如下所示：

HTTP/1.1 GET /time/ - 1 Connection_Dropped DefaultAppPool

目的地伺服器上的內建記錄不會提供問題的任何其他資訊，因此下一個步驟是從ARR伺服器收集網路追蹤。在上一個範例中，呼叫 Response.Close() .aspx頁面而不傳回任何數據。在網路追蹤中檢視此值時，會顯示 Connection: close HTTP 標頭來自目的地伺服器。透過這項資訊，您可以開始調查傳送標頭的原因 Connection: close 。

下列錯誤是成員伺服器無效回應的另一個範例：

顯示成員伺服器無效回應的螢幕快照。

在此範例中，ARR 開始接收來自客戶端的數據，但在讀取要求實體主體時發生問題。這會導致傳回0x80072f78錯誤碼。若要進一步調查，請使用成員伺服器上的網路監視器來取得問題的網路追蹤。這個特定錯誤範例是在傳送回應的一部分之後，於 ASP.net 頁面中呼叫 Response.Close() ，然後呼叫 Response.Flush()來建立。 如果 ARR 伺服器與成員伺服器之間的流量是透過 SSL，則 Windows Server 2008 上的 WinHTTP 追蹤或 Windows Server 2008 R2 上的 WebIO 追蹤可能會提供其他資訊。此疑難解答員稍後會說明 WebIO 追蹤。

502.4 找不到適當的伺服器來路由要求

具有相關聯錯誤碼的 HTTP 502.4 錯誤0x00000000通常表示伺服器數位的所有成員都離線或無法連線。

顯示找不到適當伺服器訊息以路由傳送要求的螢幕快照。

第一個步驟是確認成員伺服器已上線。若要檢查此問題，請移至 IIS 管理員中伺服器陣列底下的 [伺服器] 節點。

此螢幕快照顯示如何流覽至 IIS 管理員中伺服器陣列底下的 [伺服器] 節點。

若要恢復離線伺服器，請以滑鼠右鍵按下伺服器名稱，然後選取 [新增至負載平衡]。如果您無法讓伺服器重新上線，請確認成員伺服器是否可從ARR伺服器連線。檢查 [伺服器] 頁面中的 [追蹤訊息] 窗格，以尋找有關問題的一些線索。如果您使用 Web 伺服器陣列架構（WFF） 2.0，當應用程式集區重新啟動時，您可能會收到此錯誤。您必須重新啟動 Web 伺服器陣列服務才能復原。

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 需要幾秒鐘的時間才能完成。完成後，您可以在 中找到 C:\tempnet.etl 檔案和 net.cab 檔案。執行上述命令之前，您必須確定 C:\temp 資料夾存在。 .cab檔案包含事件記錄檔和其他數據，可能有助於分析 .etl 檔案。

若要分析記錄檔，

在 Netmon 3.4 或更新版本中開啟它。
請確定您已設定剖析器設定檔。若要達成此目的，請開啟 [工具>選項] 功能表，選取 [剖析器配置檔] 索引卷標 Windows 配置檔>，然後選取 [設定為使用中] 按鈕以套用變更。
捲動追蹤， 直到您找到執行ARR的 w3wp.exe 實例，方法是與 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}

其他資源

協力廠商資訊免責聲明

本文提及的協力廠商產品是由與 Microsoft 無關的獨立廠商所製造。 Microsoft 不以默示或其他方式，提供與這些產品的效能或可靠性有關的擔保。

共用方式為

針對 ARR 中的 502 錯誤進行疑難解答

HTTP 502 - 概觀

502.3 逾時錯誤

到底逾時了什麼？

原因

502.3 連線終止錯誤

502.4 找不到適當的伺服器來路由要求

WinHTTP 或 WebIO 追蹤

其他資源

意見反應

其他資源