Delen via

502-fouten in ARR oplossen

  • Artikel

Dit artikel helpt u bij het oplossen van de problemen met betrekking tot 502-fouten in ARR (Application Request Routing).

Van toepassing op: Internet Information Services

HTTP 502 - Overzicht

Wanneer u met ARR-implementaties (IIS Application Request Routing) werkt, is een van de fouten die u ziet mogelijk HTTP 502 - Ongeldige gateway. De fout 502.3 betekent dat ARR tijdens het fungeren als proxy de aanvraag niet kon voltooien naar de upstream-server en een antwoord naar de client kon sturen. Dit probleem kan om meerdere redenen optreden. Als er bijvoorbeeld geen verbinding kan worden gemaakt met de server, geen reactie van de server of de server te lang duurde om te reageren (time-out). Als u de fout kunt reproduceren door naar de webfarm te bladeren vanaf de controller en gedetailleerde fouten zijn ingeschakeld op de server, ziet u mogelijk een fout die vergelijkbaar is met het volgende foutbericht:

Schermopname van gedetailleerde 502-fouten die worden weergegeven wanneer gedetailleerde fouten zijn ingeschakeld op de server.

De hoofdoorzaak van de fout bepaalt wat u moet doen om het probleem op te lossen.

Time-outfouten van 502.3

ARR gebruikt de foutcode in de voorgaande schermopname om de aanvraag te proxyn en de bron van de fout te bepalen omdat deze de retourcode van WinHTTP bevat.

U kunt de foutcode decoderen met het hulpprogramma err.exe. In dit voorbeeld wordt de foutcode toegewezen aan ERROR_WINHTTP_TIMEOUT. U vindt deze informatie ook in de IIS-logboeken voor de bijbehorende website op de ARR-controller. Hier volgt een fragment uit de IIS-logboekvermelding voor de fout 502.3, waarbij de meeste velden zijn ingekort voor leesbaarheid:

sc-status sc-substatus sc-win32-status tijd die nodig is
502 3 12002 29889

De win32-status 12002 wordt toegewezen aan dezelfde ERROR_WINHTTP_TIMEOUT fout die is gerapporteerd op de foutpagina.

Wat is er precies een time-out?

U kunt deze time-out controleren door Tracering van mislukte aanvragen in te schakelen op de IIS-server. Het eerste punt dat u kunt zien, in het traceringslogboek van de mislukte aanvraag en dit is waar de aanvraag is verzonden in de ARR_SERVER_ROUTED gebeurtenis. Het tweede punt is de X-ARR-LOG-ID, die u kunt gebruiken om de aanvraag op de doelserver bij te houden. Dit helpt bij het traceren van het doel of doel van de HTTP-aanvraag:

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

In het volgende voorbeeld ziet u hoe dit eruit kan zien in de traceringslogboeken voor mislukte aanvragen van de doelserver. U kunt controleren of u de juiste aanvraag hebt gevonden door de X-ARR-LOG-ID-waarden in beide traceringen te vergelijken.

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

In het vorige voorbeeld ziet u dat de verbinding met de ARR-server is verbroken voordat het HTTP-antwoord werd verzonden. De tijdstempel voor GENERAL_FLUSH_RESPONSE_END kan worden gebruikt als een ruwe handleiding om de bijbehorende vermelding te vinden in de IIS-logboeken op de doelserver.

datum tijd s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username sc-status sc-substatus sc-win32-status tijd die nodig is
2011-07-18 16:51:06 192.168.0.216 GET /Tijd/ - 80 - 200 0 64 45208

IIS op de doelserver heeft een HTTP 200-statuscode geregistreerd, waarmee wordt aangegeven dat de aanvraag is voltooid. Ook is de win32-status gewijzigd in 64, die is toegewezen aan ERROR_NETNAME_DELETED. Deze statuscode geeft over het algemeen aan dat de verbinding met de client (ARR in dit geval de 'client' is) is verbroken voordat de aanvraag is voltooid.

Oorzaak

De ARR-server heeft een time-out gerapporteerd, waar u eerst moet kijken.

Hoewel het logboek van de lidserver aangeeft dat het antwoord binnen 45 seconden (45208 ms) is verzonden, geeft de IIS-logboekvermelding van de ARR-server aan dat de tijd die nodig is zeer dicht bij 30 seconden ligt. Dit geeft aan dat ARR een time-out optreedt voor de aanvraag. U kunt dit bevestigen door de time-out van de proxy in de proxy-instellingen van de serverfarm te bekijken. Deze is standaard ingesteld op 30 seconden.

In dit geval ziet u dus duidelijk dat de ARR-time-out korter was dan de uitvoering van de aanvraag. Daarom kunt u controleren of deze uitvoeringstijd normaal was of als u wilt kijken waarom de aanvraag langer duurde dan verwacht. Als deze uitvoeringstijd werd verwacht en normaal was, moet het verhogen van de ARR-time-out de fout oplossen.

Andere mogelijke redenen voor ERROR_WINHTTP_TIMEOUT zijn:

  • ResolveTimeout: treedt op als de naamomzetting langer duurt dan de opgegeven time-outperiode.
  • ConnectTimeout: treedt op als het langer duurt dan de opgegeven time-outperiode om verbinding te maken met de server nadat de naam is omgezet.
  • SendTimeout: treedt op als het verzenden van een aanvraag langer duurt dan deze time-outwaarde. De verzendbewerking wordt geannuleerd.
  • ReceiveTimeout: treedt op als een reactie langer duurt dan deze time-outwaarde. De aanvraag wordt geannuleerd.

Wanneer u de eerste twee redenen bekijkt en ResolveTimeout ConnectTimeoutde eerder beschreven probleemoplossingsmethodologie niet zou werken. Dit komt doordat u geen verkeer op de doelserver zou zien en daarom de foutcode niet zou kennen. In dit geval van ResolveTimeout of ConnectTimeout wilt u mogelijk een WinHTTP-trace vastleggen voor extra inzicht. Zie de sectie WinHTTP- of WEBIO-tracering en in de volgende blogs voor andere voorbeelden over probleemoplossing en tracering:

502.3 Verbindingsafbrekingsfouten

502.3-fouten worden ook geretourneerd wanneer de verbinding tussen ARR en de lidserver halverwege de stream wordt verbroken. Als u dit type probleem wilt testen, maakt u een .aspx pagina die aanroept Response.Close(). In het volgende voorbeeld is er een map met de naam 'time', die is geconfigureerd met een .aspx-pagina als het standaarddocument in die map. Wanneer u naar de map wilt bladeren, wordt in ARR het volgende foutbericht weergegeven:

Schermopname met verbindingsafbrekingsfouten.

De fout 0x80072efe komt overeen met ERROR_INTERNET_CONNECTION_ABORTED. De aanvraag kan worden getraceerd naar de server die deze daadwerkelijk heeft verwerkt met behulp van dezelfde stappen die eerder in deze probleemoplosser zijn gebruikt, met één uitzondering. Terwijl tracering van mislukte aanvragen op de doelserver de aanvraag weergeeft die op de server is verwerkt, wordt de bijbehorende logboekvermelding niet weergegeven in de IIS-logboeken. In plaats daarvan wordt deze aanvraag als volgt vastgelegd in het HTTPERR-logboek:

HTTP/1.1 GET /time/ - 1 Connection_Dropped DefaultAppPool

De ingebouwde logboeken op de doelserver bieden geen aanvullende informatie over het probleem, dus de volgende stap is het verzamelen van een netwerktracering van de ARR-server. In het vorige voorbeeld wordt de .aspx pagina aangeroepen Response.Close() zonder gegevens te retourneren. Als u dit in een netwerktracering bekijkt, ziet u dat er een Connection: close HTTP-header afkomstig was van de doelserver. Met deze informatie kunt u een onderzoek starten naar de reden waarom de Connection: close header is verzonden.

De volgende fout is een ander voorbeeld van een ongeldig antwoord van de lidserver:

Schermopname van een ongeldig antwoord van de lidserver.

In dit voorbeeld begon ARR gegevens van de client te ontvangen, maar er is iets misgegaan tijdens het lezen van de hoofdtekst van de aanvraagentiteit. Dit heeft geresulteerd in de 0x80072f78 foutcode die wordt geretourneerd. Als u verder wilt onderzoeken, gebruikt u Netwerkmonitor op de lidserver om een netwerktracering van het probleem op te halen. Dit specifieke foutvoorbeeld is gemaakt door het aanroepen Response.Close() op de pagina ASP.net na het verzenden van een deel van het antwoord en vervolgens het aanroepen Response.Flush(). Als het verkeer tussen de ARR-server en de lidservers via SSL is, kan WinHTTP-tracering op Windows Server 2008 of WebIO-tracering op Windows Server 2008 R2 aanvullende informatie bieden. WebIO-tracering wordt verderop in deze probleemoplosser beschreven.

502.4 Er kan geen geschikte server worden gevonden om de aanvraag te routeren

De HTTP 502.4-fout met een bijbehorende foutcode van 0x00000000 geeft over het algemeen aan dat alle leden van de farm offline of anderszins onbereikbaar zijn.

Schermopname van een bericht dat geen geschikte server kan worden gevonden om de aanvraag te routeren.

De eerste stap is om te controleren of de lidservers online zijn. Als u dit wilt controleren, gaat u naar het knooppunt Servers onder de farm in IIS-beheer.

Schermopname die laat zien hoe u naar het knooppunt Servers navigeert onder de Serverfarm in IIS-beheer.

Als u de offlineservers wilt terughalen, klikt u met de rechtermuisknop op de servernaam en selecteert u Toevoegen aan taakverdeling. Als u de servers niet weer online kunt brengen, controleert u of de lidservers bereikbaar zijn vanaf de ARR-server. Controleer het deelvenster Berichten traceren op de pagina Servers om te zoeken naar enkele aanwijzingen over het probleem. Als u Web Farm Framework (WFF) 2.0 gebruikt, wordt deze fout mogelijk weergegeven wanneer de groep van toepassingen opnieuw wordt gestart. U moet de webfarmservice opnieuw starten om te herstellen.

WinHTTP- of WebIO-tracering

Meestal bieden hulpprogramma's voor pakketopname, zoals WireShark , u de informatie die u nodig hebt om precies te bepalen wat er een time-out is. Er zijn echter momenten (zoals wanneer het verkeer is versleuteld met SSL) dat u een andere benadering moet proberen. Vanaf Windows 7 en Windows Server 2008 R2 kunt u WinHTTP-tracering inschakelen met behulp van het netsh-hulpprogramma door de volgende opdracht uit te voeren vanaf een beheeropdrachtprompt:

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

Reproduceer vervolgens het probleem. Nadat het probleem is gereproduceerd, stopt u de tracering door de volgende opdracht uit te voeren:

netsh trace stop

Het duurt enkele seconden voordat de stop opdracht is voltooid. Wanneer u klaar bent, vindt u een net.etl-bestand en een net.cab-bestand in C:\temp. U moet ervoor zorgen dat de C:\temp map bestaat voordat u de bovenstaande opdrachten uitvoert. Het .cab-bestand bevat gebeurtenislogboeken en andere gegevens die nuttig kunnen zijn bij het analyseren van het ETL-bestand.

Om het logboek te analyseren,

  1. Open het in Netmon 3.4 of hoger.

  2. Zorg ervoor dat u uw parserprofiel hebt ingesteld. Hiervoor opent u het menu Extra>opties, selecteert u het tabblad >Profielen van parserprofielen en selecteert u vervolgens de knop Instellen als actief om de wijzigingen toe te passen.

  3. Blader door de tracering totdat u het w3wp.exe exemplaar hebt gevonden waarop ARR wordt uitgevoerd door de kolom UT-procesnaam te correleren.

  4. Klik met de rechtermuisknop op w3wp en selecteer UT-procesnaam toevoegen om het filter weer te geven. Hiermee wordt het weergavefilter ingesteld dat vergelijkbaar is met:

    UTProcessName == "w3wp.exe (1432)"

U kunt de resultaten verder filteren door deze te wijzigen in het volgende:

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

U moet door de uitvoer schuiven totdat u de time-outfout hebt gevonden. In het volgende voorbeeld is een time-out opgetreden voor een aanvraag omdat het meer dan 30 seconden duurde (de standaardtime-out van ARR) om uit te voeren.

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)

In het volgende voorbeeld was de inhoudsserver volledig 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}

Meer informatie

Disclaimerinformatie van derden

De producten van derden die in dit artikel worden vermeld, worden vervaardigd door bedrijven die onafhankelijk zijn van Microsoft. Microsoft verleent dan ook geen enkele garantie, impliciet noch anderszins, omtrent de prestaties of de betrouwbaarheid van deze producten.