Problembehandlung für 502-Fehler in ARR

Dieser Artikel hilft Ihnen bei der Behebung der Probleme im Zusammenhang mit 502-Fehlern in Application Request Routing (ARR).

Gilt für: Internetinformationsdienste

HTTP 502 – Übersicht

Wenn Sie mit ARR-Bereitstellungen (Application Request Routing) von IIS arbeiten, wird einer der Fehler angezeigt, der möglicherweise "HTTP 502 – Ungültiges Gateway" angezeigt wird. Der Fehler 502.3 bedeutet, dass ARR während seiner Funktion als Proxy nicht die Anforderung an den Upstream Server abschließen und eine Antwort zurück an den Client senden konnte. Dieses Problem kann aus mehreren Gründen auftreten. Beispiel: 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 aus durchsuchen und detaillierte Fehler auf dem Server aktiviert sind, wird möglicherweise ein Fehler ähnlich der folgenden Fehlermeldung angezeigt:

Die Grundursache des Fehlers bestimmt, wie Sie das Problem beheben sollten.

Timeoutfehler 502.3

ARR verwendet den Fehlercode im vorherigen Screenshot, um die Anforderung als Proxy zu verwenden und die Fehlerquelle zu ermitteln, da er den Rückgabecode von WinHTTP enthält.

Sie können den Fehlercode mit dem Tool err.exedecodieren . In diesem Beispiel wird der Fehlercode ERROR_WINHTTP_TIMEOUT zugeordnet. Sie finden diese Informationen auch in den IIS-Protokollen für die zugehörige 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 zur Lesbarkeit gekürzt wurden:

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

Win32 status 12002 wird demselben ERROR_WINHTTP_TIMEOUT auf der Fehlerseite gemeldeten Fehler zugeordnet.

Was genau ist ein Timeout?

Sie können dieses Timeout überprüfen, indem Sie die Ablaufverfolgung für fehlgeschlagene Anforderungen auf dem IIS-Server aktivieren. Der erste Punkt, den Sie im Ablaufverfolgungsprotokoll für fehlgeschlagene Anforderungen sehen können, und an diesen Punkt 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. Dies hilft beim Nachverfolgen des Ziels oder Ziels der HTTP-Anforderung:

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 Ablaufverfolgung fehlgeschlagener Anforderungen des Zielservers aussehen könnte. 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 sehen Sie, dass die Verbindung des ARR-Servers getrennt wurde, bevor die HTTP-Antwort gesendet wurde. Der Zeitstempel für GENERAL_FLUSH_RESPONSE_END kann als grobe Anleitung verwendet werden, um den entsprechenden Eintrag in den IIS-Protokollen auf dem Zielserver zu finden.

date	Uhrzeit	s-ip	cs-method	cs-uri-stem	cs-uri-query	S-Port	cs-username	sc-status	sc-substatus	sc-win32-status	Zeit in Anspruch 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 status Code, der angibt, dass die Anforderung erfolgreich abgeschlossen wurde. Außerdem wurde die win32-status in 64 geändert, was ERROR_NETNAME_DELETED zugeordnet ist. Dieser status Code gibt im Allgemeinen an, dass der Client (in diesem Fall ARR ist der "Client") getrennt wurde, bevor die Anforderung abgeschlossen wurde.

Ursache

Der ARR-Server hat ein Timeout gemeldet, wo Sie sich zuerst ansehen sollten.

Obwohl das Mitgliedsserverprotokoll 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 gibt an, dass ARR einen Timeout für die Anforderung verursacht, und Sie können dies bestätigen, indem Sie sich das Proxytimeout in den Proxyeinstellungen der Serverfarm ansehen. 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 ob Sie untersuchen mussten, 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 dauert als der angegebene Timeoutzeitraum.
• ConnectTimeout: Tritt auf, wenn es länger als den angegebenen Timeoutzeitraum dauert, 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 dauert als dieser Timeoutwert. Die Anforderung wird abgebrochen.

Wenn Sie die ersten beiden Gründe und ConnectTimeoutbeobachten, ResolveTimeout funktioniert die zuvor beschriebene Problembehandlungsmethodik nicht. Dies liegt daran, dass Sie keinen Datenverkehr auf dem Zielserver sehen und daher den Fehlercode nicht kennen. In diesem Fall von ResolveTimeout oder ConnectTimeout möchten Sie möglicherweise eine WinHTTP-Ablaufverfolgung erfassen, um zusätzliche Erkenntnisse zu erhalten. Weitere Beispiele zur Problembehandlung und Ablaufverfolgung finden Sie im Abschnitt WinHTTP oder WEBIO und in den folgenden Blogs:

• 502.3 Ungültiges Gateway "Timeout des Vorgangs" mit IIS Application Request Routing (ARR)
• Winhttp-Ablaufverfolgungsoptionen für die Problembehandlung mit Anwendungsanforderungsrouting

502.3 Fehler bei der Verbindungsbeendigung

502.3-Fehler werden auch zurückgegeben, wenn die Verbindung zwischen ARR und dem Mitgliedsserver während des Streams getrennt wird. Um diese Art von Problem zu testen, erstellen Sie eine .aspx Seite, die aufruft 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:

Der fehler 0x80072efe entspricht ERROR_INTERNET_CONNECTION_ABORTED. Die Anforderung kann bis zu dem Server nachverfolgt werden, der sie tatsächlich verarbeitet hat, indem Sie die gleichen Schritte ausführen, die zuvor in dieser Problembehandlung verwendet wurden, mit einer Ausnahme. Während die Ablaufverfolgung fehlgeschlagener Anforderungen auf dem Zielserver die auf dem Server verarbeitete Anforderung anzeigt, wird der zugeordnete Protokolleintrag nicht in den IIS-Protokollen angezeigt. Stattdessen wird diese Anforderung wie folgt im HTTPERR-Protokoll protokolliert:

HTTP/1.1 GET /time/ - 1 Connection_Dropped DefaultAppPool

Die integrierten Protokolle auf dem Zielserver enthalten keine zusätzlichen Informationen zum Problem, sodass der nächste Schritt darin besteht, eine Netzwerkablaufverfolgung vom ARR-Server zu sammeln. Im vorherigen Beispiel wurde 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 eine Untersuchung starten, warum der Connection: close Header gesendet wurde.

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

In diesem Beispiel hat ARR damit begonnen, Daten vom Client zu empfangen, aber beim Lesen des Anforderungsentitätstexts ist ein Fehler aufgetreten. Dies führte dazu, dass der 0x80072f78 Fehlercode zurückgegeben wurde. Verwenden Sie zur weiteren Untersuchung den Netzwerkmonitor auf dem Mitgliedsserver, um eine Netzwerkablaufverfolgung des Problems zu erhalten. Dieses Bestimmte Fehlerbeispiel wurde erstellt, indem auf der seite ASP.net aufgerufen Response.Close() wurde, nachdem ein Teil der Antwort gesendet und dann aufgerufen wurdeResponse.Flush(). Wenn der Datenverkehr zwischen dem ARR-Server und den Mitgliedsservern über SSL erfolgt, kann die WinHTTP-Ablaufverfolgung unter Windows Server 2008 oder die WebIO-Ablaufverfolgung unter Windows Server 2008 R2 zusätzliche Informationen bereitstellen. Die WebIO-Ablaufverfolgung wird weiter unten in dieser Problembehandlung beschrieben.

502.4 Es wurde kein geeigneter Server gefunden, um die Anforderung weiterzuleiten.

Der HTTP 502.4-Fehler mit dem zugeordneten Fehlercode 0x00000000 zeigt im Allgemeinen an, dass alle Mitglieder der Farm entweder offline oder anderweitig nicht erreichbar sind.

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

Klicken Sie mit der rechten Maustaste auf den Servernamen, und wählen Sie Zu Lastenausgleich hinzufügen aus, um die Offlineserver wieder zurückzugeben. Wenn Sie die Server nicht wieder online schalten können, überprüfen Sie, ob die Mitgliedsserver vom ARR-Server aus erreichbar sind. Überprüfen Sie den Bereich "Ablaufverfolgungsmeldungen " auf der Seite "Server ", um nach Hinweisen zu dem Problem zu suchen. Wenn Sie Web Farm Framework (WFF) 2.0 verwenden, wird dieser Fehler möglicherweise beim Neustart des Anwendungspools angezeigt. Sie müssen den Webfarmdienst neu starten, um die Wiederherstellung durchzuführen.

WinHTTP- oder WebIO-Ablaufverfolgung

In der Regel liefern Ihnen Paketerfassungstools wie WireShark die Informationen, die Sie benötigen, um genau zu identifizieren, was ein Timeout ist. Es gibt jedoch Zeiten (z. B. wenn der Datenverkehr SSL-verschlüsselt ist), in denen Sie einen anderen Ansatz ausprobieren 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 administrativen 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 Abschluss des Befehls dauert einige Sekunden. Wenn dies abgeschlossen 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 sich bei der Analyse der ETL-Datei als hilfreich erweisen 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>Optionen, wählen Sie die Registerkarte >ParserprofileWindows-Profil und dann die Schaltfläche Als aktiv festlegen aus, um die Änderungen anzuwenden.

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

4. Klicken Sie mit der rechten Maustaste auf w3wp, und wählen Sie Add UT Process name (Name des UT-Prozesses hinzufügen) aus, um den Filter anzuzeigen. Dadurch wird der Anzeigefilter wie folgt festgelegt:

   UTProcessName == "w3wp.exe (1432)"
   

Sie können die Ergebnisse weiter filtern, indem Sie sie wie folgt ändern:

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

Sie müssen durch die Ausgabe scrollen, bis Sie den Timeoutfehler finden. Im folgenden Beispiel ist für eine Anforderung ein Timeout auftrat, da die Ausführung mehr als 30 Sekunden (Standardtimeout von ARR) gedauert hat.

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} 

Sonstige Ressourcen

• Fehlersuchetool
• Winhttp-Fehlercodes
• Ablaufverfolgung fehlgeschlagener Anforderungen
• Winhttp-Ablaufverfolgung
• Netzwerkmonitor

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.