Freigeben über

Problembehandlung bei 502 Fehlern in ARR

  • Artikel

Dieser Artikel hilft Ihnen, die Probleme im Zusammenhang mit 502 Fehlern im Application Request Routing (ARR) zu beheben.

Gilt für: Internetinformationsdienste

HTTP 502 – Übersicht

Wenn Sie mit BEREITSTELLUNGen für IIS-Anwendungsanforderungsrouting (ARR) arbeiten, ist einer der Fehler, die Möglicherweise angezeigt wird, "HTTP 502 – Ungültiges Gateway". Der Fehler 502.3 bedeutet, dass ARR beim Handeln als Proxy nicht die Anforderung an den Upstreamserver abschließen und eine Antwort an den Client senden konnte. Dieses Problem kann aus mehreren Gründen auftreten. Ein Fehler beim Herstellen einer Verbindung mit dem Server, keine Antwort vom Server oder der Server hat zu lange gedauert, um zu reagieren (Timeout). Wenn Sie den Fehler reproduzieren können, indem Sie die Webfarm vom Controller durchsuchen und detaillierte Fehler auf dem Server aktiviert sind, wird möglicherweise ein Fehler angezeigt, der der folgenden Fehlermeldung ähnelt:

Screenshot mit detaillierten 502 Fehlern, die angezeigt werden, wenn detaillierte Fehler auf dem Server aktiviert sind.

Die Ursache des Fehlers bestimmt, was Sie tun sollten, um das Problem zu beheben.

502.3 Timeoutfehler

ARR verwendet den Fehlercode im vorherigen Screenshot, um die Anforderung zu proxyn und die Quelle des Fehlers zu ermitteln, da er den Rückgabecode von WinHTTP enthält.

Sie können den Fehlercode mit dem Tool err.exe decodieren. In diesem Beispiel gehört der Fehlercode zu ERROR_WINHTTP_TIMEOUT. Sie finden diese Informationen auch in den IIS-Protokollen für die betreffende Website auf dem ARR-Controller. Im Folgenden finden Sie einen Auszug aus dem IIS-Protokolleintrag für den Fehler 502.3, wobei die meisten Felder der besseren Lesbarkeit halber gekürzt wurden:

sc-status sc-substatus sc-win32-status Zeit genommen
502 3 12002 29889

Der win32-Status 12002 entspricht dem auf der Fehlerseite gemeldeten Fehler ERROR_WINHTTP_TIMEOUT.

Was genau ist ein Timeout?

Sie können dieses Timeout überprüfen, indem Sie die Ablaufverfolgung fehlgeschlagener Anforderungen auf dem IIS-Server aktivieren. Der erste Punkt, den Sie sehen können, im Protokoll der fehlgeschlagenen Anforderungsablaufverfolgung und hier wurde die Anforderung im ARR_SERVER_ROUTED-Ereignis gesendet. Der zweite Punkt ist die X-ARR-LOG-ID, mit der Sie die Anforderung auf dem Zielserver nachverfolgen können. Dadurch können Sie das Ziel oder ziel der HTTP-Anforderung nachverfolgen:

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

Das folgende Beispiel zeigt, wie dies in den Protokollen der Fehleranforderungsprotokollierung des Zielservers aussehen kann. Sie können überprüfen, ob Sie die richtige Anforderung gefunden haben, indem Sie die Werte "X-ARR-LOG-ID" in beiden Ablaufverfolgungen abgleichen.

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

Im vorherigen Beispiel können Sie sehen, dass der ARR-Server vor dem Senden der HTTP-Antwort getrennt wurde. Der Zeitstempel für GENERAL_FLUSH_RESPONSE_END kann als grober Anhaltspunkt verwendet werden, um den entsprechenden Eintrag in den IIS-Protokollen auf dem Zielserver zu finden.

date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username sc-status sc-substatus sc-win32-status Zeit genommen
2011-07-18 16:51:06 192.168.0.216 GET /Zeit/ - 80 - 200 0 64 45208

IIS auf dem Zielserver protokollierte einen HTTP 200-Statuscode, der angibt, dass die Anforderung erfolgreich abgeschlossen wurde. Außerdem hat sich der Win32-Status in 64 geändert, der ERROR_NETNAME_DELETED zugeordnet ist. Dieser Statuscode weist im Allgemeinen darauf hin, dass der Client (ARR in diesem Fall der 'Kunde' ist), der vor Abschluss der Anforderung getrennt wurde.

Ursache

Der ARR-Server hat ein Timeout gemeldet, in dem Sie zuerst nachschauen sollten.

Obwohl das Memberserverprotokoll angibt, dass die Antwort in 45 Sekunden (45208 ms) gesendet wurde, gibt der IIS-Protokolleintrag vom ARR-Server an, dass die benötigte Zeit sehr nahe bei 30 Sekunden liegt. Dies weist darauf hin, dass ARR die Anforderung ausgibt, und Sie können dies bestätigen, indem Sie das Proxytimeout in den Proxyeinstellungen der Serverfarm anzeigen. Standardmäßig ist sie auf 30 Sekunden festgelegt.

In diesem Fall können Sie also deutlich sehen, dass das ARR-Timeout kürzer war als die Ausführung der Anforderung. Daher sollten Sie überprüfen, ob diese Ausführungszeit typisch war, oder wenn Sie prüfen müssen, warum die Anforderung länger als erwartet dauerte. Wenn diese Ausführungszeit erwartet und normal war, sollte das Erhöhen des ARR-Timeouts den Fehler beheben.

Weitere mögliche Gründe für ERROR_WINHTTP_TIMEOUT sind:

  • ResolveTimeout: Tritt auf, wenn die Namensauflösung länger als der angegebene Timeoutzeitraum dauert.
  • ConnectTimeout: Tritt auf, wenn es länger dauert als der angegebene Timeoutzeitraum, um eine Verbindung mit dem Server herzustellen, nachdem der Name aufgelöst wurde.
  • SendTimeout: Tritt auf, wenn das Senden einer Anforderung länger dauert als dieser Timeoutwert. Der Sendevorgang wird abgebrochen.
  • ReceiveTimeout: Tritt auf, wenn eine Antwort länger als dieser Timeoutwert dauert. Die Anforderung wird abgebrochen.

Wenn Sie die ersten beiden Gründe beobachten und ResolveTimeout ConnectTimeoutdie zuvor beschriebene Problembehandlungsmethode nicht funktionierte. Dies liegt daran, dass sie keinen Datenverkehr auf dem Zielserver sehen würden und daher den Fehlercode nicht kennen würden. In diesem Fall oder ConnectTimeout in diesem Fall ResolveTimeout möchten Sie möglicherweise eine WinHTTP-Ablaufverfolgung für zusätzliche Einblicke erfassen. Weitere Beispiele zur Problembehandlung und Ablaufverfolgung finden Sie im Abschnitt "WinHTTP- oder WEBIO-Ablaufverfolgung" und in den folgenden Blogs:

502.3 Verbindungsfehler

502.3 Fehler werden auch zurückgegeben, wenn die Verbindung zwischen ARR und dem Mitgliedsserver mitten im Datenstrom unterbrochen wird. Um diese Art von Problem zu testen, erstellen Sie eine .aspx Seite, die aufgerufen wird Response.Close(). Im folgenden Beispiel gibt es ein Verzeichnis namens "time", das mit einer .aspx Seite als Standarddokument in diesem Verzeichnis konfiguriert ist. Wenn Sie versuchen, zum Verzeichnis zu navigieren, zeigt ARR die folgende Fehlermeldung an:

Screenshot, der Verbindungsendfehler zeigt.

Der Fehler 0x80072efe entspricht ERROR_INTERNET_CONNECTION_ABORTED. Die Anforderung kann auf den Server zurückverfolgt werden, der sie tatsächlich verarbeitet hat, indem die gleichen Schritte verwendet werden, die weiter oben in dieser Problembehandlung verwendet wurden, mit einer Ausnahme. Während die Anforderungsablaufverfolgung auf dem Zielserver die auf dem Server verarbeitete Anforderung anzeigt, wird der zugeordnete Protokolleintrag nicht in den IIS-Protokollen angezeigt. Stattdessen wird diese Anforderung im HTTPERR-Protokoll wie folgt protokolliert:

HTTP/1.1 GET /time/ - 1 Connection_Dropped DefaultAppPool

Die integrierten Protokolle auf dem Zielserver enthalten keine zusätzlichen Informationen zum Problem, daher wäre der nächste Schritt das Sammeln einer Netzwerkablaufverfolgung vom ARR-Server. Im vorherigen Beispiel wird die .aspx Seite aufgerufen Response.Close() , ohne Daten zurückzugeben. Wenn Sie dies in einer Netzwerkablaufverfolgung anzeigen, wird angezeigt, dass ein Connection: close HTTP-Header vom Zielserver stammt. Mit diesen Informationen können Sie mit einer Untersuchung beginnen, warum die Connection: close Kopfzeile gesendet wurde.

Der folgende Fehler ist ein weiteres Beispiel für eine ungültige Antwort vom Memberserver:

Screenshot, der eine ungültige Antwort vom Memberserver zeigt.

In diesem Beispiel hat ARR damit begonnen, Daten vom Client zu empfangen, aber beim Lesen des Entity Body ist etwas schief gelaufen. Dies führte dazu, dass der 0x80072f78 Fehlercode zurückgegeben wurde. Verwenden Sie zum weiteren Untersuchen den Netzwerkmonitor auf dem Memberserver, um eine Netzwerkablaufverfolgung des Problems zu erhalten. Dieses spezielle Fehlerbeispiel wurde durch Aufrufen Response.Close() der ASP.net-Seite nach dem Senden eines Teils der Antwort und anschließenden Aufrufen Response.Flush()erstellt. Wenn der Datenverkehr zwischen dem ARR-Server und den Mitgliedsservern über SSL läuft, kann die WinHTTP-Ablaufverfolgung unter Windows Server 2008 oder die WebIO-Ablaufverfolgung unter Windows Server 2008 R2 zusätzliche Informationen liefern. Die WebIO-Ablaufverfolgung wird weiter unten in dieser Problembehandlung beschrieben.

502.4 Es konnte kein geeigneter Server gefunden werden, um die Anforderung weiterzuleiten

Der HTTP 502.4-Fehler mit einem zugeordneten Fehlercode von 0x00000000 weist im Allgemeinen darauf hin, dass alle Member der Farm offline oder anderweitig nicht erreichbar sind.

Screenshot, der eine Meldung ohne geeigneten Server zeigt, um die Anforderung weiterzuleiten.

Der erste Schritt besteht darin, zu überprüfen, ob die Mitgliedsserver online sind. Um dies zu überprüfen, wechseln Sie zum Knoten "Server " unter der Farm im IIS-Manager.

Screenshot, der zeigt, wie Sie unter der Serverfarm im IIS-Manager zum Knoten

Um die Offlineserver zurückzugeben, klicken Sie mit der rechten Maustaste auf den Servernamen, und wählen Sie "Zum Lastenausgleich hinzufügen" aus. Wenn Sie die Server nicht wieder online schalten können, überprüfen Sie, ob die Mitgliedsserver vom ARR-Server erreichbar sind. Überprüfen Sie den Bereich "Ablaufverfolgungsnachrichten " auf der Seite "Server ", um nach Hinweisen zum Problem zu suchen. Wenn Sie Web Farm Framework (WFF) 2.0 verwenden, wird diese Fehlermeldung möglicherweise angezeigt, wenn der Anwendungspool neu gestartet wird. Sie müssen den Webdienst neu starten, um wiederherzustellen.

WinHTTP- oder WebIO-Ablaufverfolgung

In der Regel liefern Paketerfassungstools wie WireShark Ihnen die Informationen, die Sie benötigen, um genau zu identifizieren, was zeitüberschreitung ist. Es gibt jedoch Zeiten (z. B. wenn der Datenverkehr SSL verschlüsselt ist), die Sie für einen anderen Ansatz verwenden müssen. Ab Windows 7 und Windows Server 2008 R2 können Sie die WinHTTP-Ablaufverfolgung mithilfe des Netsh-Tools aktivieren, indem Sie den folgenden Befehl an einer Administrator-Eingabeaufforderung ausführen:

netsh trace start scenario=internetclient capture=yes persistent=no level=verbose tracefile=c:\temp\net.etl

Reproduzieren Sie dann das Problem. Nachdem das Problem reproduziert wurde, beenden Sie die Ablaufverfolgung, indem Sie den folgenden Befehl ausführen:

netsh trace stop

Der stop Befehl dauert ein paar Sekunden, bis er abgeschlossen ist. Wenn sie fertig ist, finden Sie eine net.etl-Datei und eine net.cab Datei in C:\temp. Sie müssen sicherstellen, dass der C:\temp Ordner vorhanden ist, bevor Sie die obigen Befehle ausführen. Die .cab Datei enthält Ereignisprotokolle und andere Daten, die bei der Analyse der ETL-Datei hilfreich sein können.

So analysieren Sie das Protokoll

  1. Öffnen Sie es in Netmon 3.4 oder höher.

  2. Stellen Sie sicher, dass Sie Ihr Parserprofil eingerichtet haben. Um dies zu erreichen, öffnen Sie das Menü "Extras>", wählen Sie die Registerkarte "Parserprofile" >aus, und wählen Sie dann die Schaltfläche "Als aktiv festlegen" aus, um die Änderungen anzuwenden.

  3. Scrollen Sie durch die Ablaufverfolgung, bis Sie die w3wp.exe Instanz finden, in der ARR ausgeführt wird, indem Sie mit der Spalte mit dem UT-Prozessnamen korrelieren.

  4. Klicken Sie mit der rechten Maustaste auf w3wp, und wählen Sie "Namen des UT-Prozesses hinzufügen" aus, um den Filter anzuzeigen. Dadurch wird der Anzeigefilter ähnlich wie folgt festgelegt:

    UTProcessName == "w3wp.exe (1432)"

Sie können die Ergebnisse weiter filtern, indem Sie folgende Änderung vornehmen:

UTProcessName == "w3wp.exe (<pid>)" AND ProtocolName == "WINHTTP_MicrosoftWindowsWinHttp"

Sie müssen durch die Ausgabe scrollen, bis Sie den Timeoutfehler gefunden haben. Im folgenden Beispiel wurde ein Timeout für eine Anforderung ausgeführt, da es mehr als 30 Sekunden (Standardtimeout von ARR) dauerte.

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)

Im folgenden Beispiel war der Inhaltsserver vollständig offline:

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}

Weitere Ressourcen

Informationen zum Haftungsausschluss von Drittanbietern

Die in diesem Artikel genannten Drittanbieterprodukte stammen von Herstellern, die von Microsoft unabhängig sind. Microsoft gewährt keine implizite oder sonstige Garantie in Bezug auf die Leistung oder Zuverlässigkeit dieser Produkte.