針對 ARR 中的 502 錯誤進行疑難解答
本文可協助您解決應用程式要求路由 (ARR) 中502錯誤的相關問題。
適用於： 因特網資訊服務
HTTP 502 - 概觀
當您使用 IIS 應用程式要求路由 (ARR) 部署時，您可能會看到其中一個錯誤是「HTTP 502 - 閘道不正確」。 502.3 錯誤表示當做 Proxy 時，ARR 無法完成對上游伺服器的要求，並將回應傳回給用戶端。 這個問題可能會因為多種原因而發生。 例如，無法連線到伺服器、伺服器沒有回應，或伺服器回應的時間太長， (逾時) 。 如果您能夠從控制器瀏覽 Web 伺服陣列來重現錯誤，且伺服器上已啟用 詳細錯誤 ，您可能會看到類似下列錯誤訊息的錯誤：
錯誤的根本原因會決定您應該採取哪些動作來解決問題。
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 | 時間 | 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：如果響應花費的時間超過這個逾時值，就會發生此情況。 要求已取消。
當您觀察到前兩個原因 ResolveTimeout 和 ConnectTimeout時，先前所述的疑難解答方法將無法運作。 這是因為您不會在目標伺服器上看到任何流量，因此不會知道錯誤碼。 因此，在此案例中，ResolveTimeoutConnectTimeout您可能會想要擷取 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伺服器收集網路追蹤。 在上一個範例中，.aspx頁呼叫 Response.Close() ，但不傳回任何數據。 在網路追蹤中檢視此項目會顯示 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 找不到適當的伺服器來路由傳送要求
相關錯誤碼為 0x00000000 的 HTTP 502.4 錯誤通常表示伺服器陣列的所有成員都是離線或無法連線。
第一個步驟是確認成員伺服器已上線。 若要檢查這一點，請移至 IIS 管理員中伺服器陣列下的 [伺服器] 節點。
![顯示如何在 IIS 管理員中瀏覽至伺服器陣列下 [伺服器陣列] 節點的螢幕快照。](media/troubleshooting-502-errors-in-arr/servers-node-under-service-farm.png)
若要回復離線伺服器，請以滑鼠右鍵按下伺服器名稱，然後選取 [ 新增至負載平衡]。 如果您無法讓伺服器重新上線，請確認成員伺服器是否可從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 命令需要幾秒鐘的時間才能完成。 完成後，您會在 中找到 net.etl 檔案和 net.cab 檔案 C:\temp。 執行上述命令之前， 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 不以默示或其他方式，提供與這些產品的效能或可靠性有關的擔保。
意見反應
即將登場：在 2024 年，我們將逐步淘汰 GitHub 問題作為內容的意見反應機制，並將它取代為新的意見反應系統。 如需詳細資訊，請參閱：https://aka.ms/ContentUserFeedback。
提交並檢視相關的意見反應