Risoluzione degli errori 502 in ARR
Questo articolo illustra come risolvere i problemi relativi agli errori 502 in Application Request Routing (ARR).
Si applica a: Internet Information Services
HTTP 502 - Panoramica
Quando si lavora con le distribuzioni di routing delle richieste di applicazione IIS( ARR), uno degli errori visualizzati è "HTTP 502 - Gateway non valido". L'errore 502.3 indica che, mentre funge da proxy, ARR non è riuscito a completare la richiesta al server upstream e inviare una risposta al client. Questo problema può verificarsi per diversi motivi. Ad esempio, l'errore di connessione al server, nessuna risposta dal server o il server ha richiesto troppo tempo per rispondere (timeout). Se è possibile riprodurre l'errore esplorando la web farm dal controller e gli errori dettagliati sono abilitati nel server, è possibile che venga visualizzato un errore simile al seguente:
La causa radice dell'errore determina le operazioni da eseguire per risolvere il problema.
Errori di timeout 502.3
ARR usa il codice di errore nello screenshot precedente per eseguire il proxy della richiesta e determinare l'origine dell'errore perché contiene il codice restituito da WinHTTP.
È possibile decodificare il codice di errore con lo strumento err.exe. In questo esempio il codice di errore viene mappato a ERROR_WINHTTP_TIMEOUT. È anche possibile trovare queste informazioni nei log IIS per il sito Web associato nel controller ARR. Di seguito è riportato un estratto della voce di log iis per l'errore 502.3, con la maggior parte dei campi tagliati per la leggibilità:
| sc-status | sc-substatus | sc-win32-status | tempo impiegato |
|---|---|---|---|
| 502 | 3 | 12002 | 29889 |
Lo stato win32 12002 viene mappato allo stesso errore di ERROR_WINHTTP_TIMEOUT segnalato nella pagina di errore.
Che timeout esattamente?
È possibile controllare questo timeout abilitando La traccia delle richieste non riuscite nel server IIS. Il primo punto visualizzato, nel log di traccia delle richieste non riuscite e in questo caso la richiesta è stata inviata nell'evento ARR_SERVER_ROUTED. Il secondo punto è L'ID X-ARR-LOG-ID, che è possibile usare per tenere traccia della richiesta nel server di destinazione. Ciò consente di tracciare la destinazione o la destinazione della richiesta 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
Nell'esempio seguente viene illustrato l'aspetto dei log di traccia delle richieste non riuscite del server di destinazione. È possibile verificare di aver trovato la richiesta corretta associando i valori "X-ARR-LOG-ID" in entrambe le tracce.
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
Nell'esempio precedente è possibile notare che il server ARR è disconnesso prima dell'invio della risposta HTTP. Il timestamp per GENERAL_FLUSH_RESPONSE_END può essere usato come guida approssimativa per trovare la voce corrispondente nei log IIS nel server di destinazione.
| data | Ora | s-ip | cs-method | cs-uri-stem | cs-uri-query | s-port | cs-username | sc-status | sc-substatus | sc-win32-status | tempo impiegato |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 2011-07-18 | 16:51:06 | 192.168.0.216 | GET | /Ore/ | - | 80 | - | 200 | 0 | 64 | 45208 |
IIS nel server di destinazione ha registrato un codice di stato HTTP 200 che indica che la richiesta è stata completata correttamente. Inoltre, lo stato win32 è cambiato in 64, che esegue il mapping a ERROR_NETNAME_DELETED. Questo codice di stato indica in genere che il client (che è il "client" in questo caso) disconnesso prima del completamento della richiesta.
Causa
Il server ARR ha segnalato un timeout, che è la posizione in cui è necessario cercare prima.
Anche se il log del server membro indica che la risposta è stata inviata in 45 secondi (45208 ms), la voce di log IIS dal server ARR indica che il tempo impiegato è molto vicino a 30 secondi. Ciò indica che ARR esegue il timeout della richiesta ed è possibile confermarlo esaminando il timeout del proxy nelle impostazioni proxy della server farm. Per impostazione predefinita, è impostato su 30 secondi.
In questo caso, è quindi possibile vedere chiaramente che il timeout ARR è più breve dell'esecuzione della richiesta. Pertanto, potrebbe essere necessario verificare se il tempo di esecuzione è tipico o se è necessario esaminare il motivo per cui la richiesta richiedeva più tempo del previsto. Se questo tempo di esecuzione era previsto e normale, l'aumento del timeout ARR dovrebbe risolvere l'errore.
Altri possibili motivi per ERROR_WINHTTP_TIMEOUT includono:
ResolveTimeout: si verifica se la risoluzione dei nomi richiede più tempo del periodo di timeout specificato.ConnectTimeout: si verifica se sono necessari più tempo del periodo di timeout specificato per connettersi al server dopo la risoluzione del nome.SendTimeout: si verifica se l'invio di una richiesta richiede più tempo di questo valore di timeout. L'operazione di invio viene annullata.ReceiveTimeout: si verifica se una risposta richiede più tempo di questo valore di timeout. La richiesta viene annullata.
Quando si osservano i primi due motivi e ResolveTimeout ConnectTimeout, la metodologia di risoluzione dei problemi descritta in precedenza non funziona. Ciò è dovuto al fatto che non viene visualizzato alcun traffico nel server di destinazione e pertanto non si conosce il codice di errore. Quindi, in questo caso di ResolveTimeout o ConnectTimeout potresti voler acquisire una traccia WinHTTP per ottenere informazioni aggiuntive. Per altri esempi sulla risoluzione dei problemi e sulla traccia, vedere la sezione di traccia WinHTTP o WEBIO e nei blog seguenti:
- 502.3 Gateway non valido "The operation timeout" with IIS Application Request Routing (ARR)
- Opzioni di traccia Winhttp per la risoluzione dei problemi con il routing delle richieste di applicazione
502.3 Errori di terminazione della connessione
Gli errori 502.3 vengono restituiti anche quando la connessione tra ARR e il server membro viene disconnessa a metà flusso. Per testare questo tipo di problema, creare una pagina di .aspx che chiama Response.Close(). Nell'esempio seguente è presente una directory denominata "time", configurata con una pagina .aspx come documento predefinito in tale directory. Quando si tenta di passare alla directory, ARR visualizza il messaggio di errore seguente:
L'errore 0x80072efe corrisponde a ERROR_INTERNET_CONNECTION_ABORTED. La richiesta può essere tracciata al server che l'ha effettivamente elaborata usando gli stessi passaggi usati in precedenza in questo strumento di risoluzione dei problemi, con un'eccezione. Mentre la traccia delle richieste non riuscite nel server di destinazione mostra la richiesta elaborata nel server, la voce di log associata non viene visualizzata nei log IIS. Questa richiesta viene invece registrata nel log HTTPERR come indicato di seguito:
HTTP/1.1 GET /time/ - 1 Connection_Dropped DefaultAppPool
I log predefiniti nel server di destinazione non forniscono informazioni aggiuntive sul problema, quindi il passaggio successivo consiste nel raccogliere una traccia di rete dal server ARR. Nell'esempio precedente la pagina .aspx chiamata Response.Close() senza restituire dati. La visualizzazione in una traccia di rete mostra che un'intestazione Connection: close HTTP proviene dal server di destinazione. Con queste informazioni, è possibile avviare un'indagine sul motivo per cui è stata inviata l'intestazione Connection: close .
L'errore seguente è un altro esempio di risposta non valida dal server membro:
In questo esempio ARR ha iniziato a ricevere dati dal client, ma si è verificato un problema durante la lettura del corpo dell'entità della richiesta. In questo modo viene restituito il codice di errore 0x80072f78. Per ulteriori indagini, usare Monitoraggio di rete nel server membro per ottenere una traccia di rete del problema. Questo particolare esempio di errore è stato creato chiamando Response.Close() nella pagina ASP.net dopo l'invio di parte della risposta e quindi la chiamata a Response.Flush(). Se il traffico tra il server ARR e i server membri è su SSL, la traccia WinHTTP in Windows Server 2008 o la traccia WebIO in Windows Server 2008 R2 può fornire informazioni aggiuntive. La traccia WebIO viene descritta più avanti in questo strumento di risoluzione dei problemi.
502.4 Non è stato trovato alcun server appropriato per instradare la richiesta
L'errore HTTP 502.4 con un codice di errore associato di 0x00000000 indica in genere che tutti i membri della farm sono offline o altrimenti non raggiungibili.
Il primo passaggio consiste nel verificare che i server membri siano online. Per verificarlo, passare al nodo Server nella farm in Gestione IIS.
Per riportare i server offline, fare clic con il pulsante destro del mouse sul nome del server e scegliere Aggiungi al bilanciamento del carico. Se non è possibile riportare online i server, verificare se i server membri sono raggiungibili dal server ARR. Controllare il riquadro Messaggi di traccia nella pagina Server per cercare alcuni indizi sul problema. Se si usa Web Farm Framework (WFF) 2.0, è possibile che venga visualizzato questo errore quando il pool di applicazioni viene riavviato. Per eseguire il ripristino, è necessario riavviare il servizio Web Farm.
Traccia WinHTTP o WebIO
In genere, gli strumenti di acquisizione di pacchetti come WireShark forniscono le informazioni necessarie per identificare esattamente il timeout. Tuttavia, in alcuni casi,ad esempio quando il traffico è crittografato SSL, sarà necessario provare un approccio diverso. A partire da Windows 7 e Windows Server 2008 R2, è possibile abilitare la traccia WinHTTP usando lo strumento netsh eseguendo il comando seguente da un prompt dei comandi amministrativo:
netsh trace start scenario=internetclient capture=yes persistent=no level=verbose tracefile=c:\temp\net.etl
Riprodurre quindi il problema. Dopo aver riprodotto il problema, arrestare la traccia eseguendo il comando seguente:
netsh trace stop
Il completamento del stop comando richiede alcuni secondi. Al termine, trovare un file net.etl e un file net.cab in C:\temp. È necessario assicurarsi che la C:\temp cartella esista prima di eseguire i comandi precedenti. Il file .cab contiene i registri eventi e altri dati che possono risultare utili per l'analisi del file con estensione etl.
Per analizzare il log,
Aprirlo in Netmon 3.4 o versione successiva.
Assicurarsi di aver configurato il profilo del parser. A tale scopo, aprire il menu Opzioni strumenti>, selezionare la scheda> Profili parser Profilo di Windows e quindi selezionare il pulsante Imposta come attivo per applicare le modifiche.
Scorrere la traccia fino a trovare l'istanza di w3wp.exe in cui È in esecuzione ARR correlando con la colonna del nome del processo UT.
Fare clic con il pulsante destro del mouse su w3wp e scegliere Aggiungi nome processo UT per visualizzare il filtro. In questo modo il filtro di visualizzazione è simile al seguente:
UTProcessName == "w3wp.exe (1432)"
È possibile filtrare ulteriormente i risultati modificandolo nel modo seguente:
UTProcessName == "w3wp.exe (<pid>)" AND ProtocolName == "WINHTTP_MicrosoftWindowsWinHttp"
Sarà necessario scorrere l'output fino a trovare l'errore di timeout. Nell'esempio seguente si è verificato il timeout di una richiesta perché sono trascorsi più di 30 secondi (timeout predefinito di ARR) per l'esecuzione.
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)
Nell'esempio seguente il server di contenuto era completamente 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}
Altre risorse
- Strumento di ricerca degli errori
- Codici di errore Winhttp
- Traccia delle richieste non riuscite
- Winhttp Tracing
- Network Monitor
Dichiarazione di non responsabilità sulle informazioni di terze parti
I prodotti di terzi citati in questo articolo sono prodotti da società indipendenti da Microsoft. Microsoft non rilascia alcuna garanzia implicita o esplicita relativa alle prestazioni o all'affidabilità di tali prodotti