Risoluzione degli errori 502 in ARR
Questo articolo consente di risolvere i problemi relativi agli errori 502 in Application Request Routing (ARR).
Si applica a: Internet Information Services
HTTP 502 - Panoramica
Quando si usano distribuzioni ARR (Application Request Routing) IIS, uno degli errori che potrebbero verificarsi è "HTTP 502 - Gateway non valido". L'errore 502.3 indica che, mentre funge da proxy, ARR non è stato in grado di 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 impiegato 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. Queste informazioni sono disponibili anche 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 ERROR_WINHTTP_TIMEOUT errore segnalato nella pagina degli errori.
Che temporizzato esattamente?
È possibile controllare questo timeout abilitando La traccia delle richieste non riuscite nel server IIS. Il primo punto che è possibile visualizzare, nel log di traccia della richiesta non riuscita ed è qui che la richiesta è stata inviata nell'evento ARR_SERVER_ROUTED. Il secondo punto è l'X-ARR-LOG-ID, che è possibile usare per tenere traccia della richiesta nel server di destinazione. In questo modo è possibile 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 di questa operazione nei 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 è stato 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 | Tempo | s-ip | cs-method | cs-uri-stem | cs-uri-query | porta s | cs-username | sc-status | sc-substatus | sc-win32-status | tempo impiegato |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 2011-07-18 | 16:51:06 | 192.168.0.216 | GET | /Tempo/ | - | 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 viene mappato a ERROR_NETNAME_DELETED. Questo codice di stato indica in genere che il client (ARR è il "client" in questo caso) è stato disconnesso prima del completamento della richiesta.
Causa
Il server ARR ha segnalato un timeout, che è il luogo in cui si dovrebbe cercare per primo.
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 sta eseguendo il timeout della richiesta ed è possibile confermarla esaminando il timeout del proxy nelle impostazioni proxy della server farm. Per impostazione predefinita, è impostato su 30 secondi.
Pertanto, in questo caso, è possibile vedere chiaramente che il timeout ARR è stato più breve dell'esecuzione della richiesta. Pertanto, è possibile verificare se questo tempo di esecuzione era tipico o se era 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 la connessione al server richiede più tempo del periodo di timeout specificato 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, ResolveTimeout e ConnectTimeout, la metodologia di risoluzione dei problemi descritta in precedenza non funzionerebbe. Ciò è dovuto al fatto che non viene visualizzato alcun traffico nel server di destinazione e pertanto non si conosce il codice di errore. In questo caso, ResolveTimeout quindi, o ConnectTimeout potresti voler acquisire una traccia WinHTTP per altre informazioni dettagliate. Vedere la sezione di traccia WinHTTP o WEBIO e nei blog seguenti per altri esempi sulla risoluzione dei problemi e la traccia:
- 502.3 Gateway non valido "Timeout dell'operazione" con il routing delle richieste dell'applicazione IIS (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:
Il 0x80072efe di errore corrisponde a ERROR_INTERNET_CONNECTION_ABORTED. La richiesta può essere tracciata nel 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, pertanto 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. Se si visualizza questa operazione in una traccia di rete, viene indicato che un'intestazione Connection: close HTTP proviene dal server di destinazione. Con queste informazioni, è possibile avviare un'indagine sul motivo per cui l'intestazione Connection: close è stata inviata.
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à richiesta. In questo modo viene restituito il codice di errore 0x80072f78. Per approfondire l'analisi, 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 aver inviato parte della risposta e quindi chiamato 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 è 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 ripristinare 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 al riavvio del pool di applicazioni. È necessario riavviare il servizio Web farm per il ripristino.
Traccia WinHTTP o WebIO
In genere, gli strumenti di acquisizione pacchetti come WireShark forniscono le informazioni necessarie per identificare esattamente il timeout. Tuttavia, in alcuni casi, ad esempio quando il traffico è crittografato ssl, è 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, si trovano un file net.etl e un file net.cab in C:\temp. Prima di eseguire i comandi precedenti, è necessario assicurarsi che la C:\temp cartella esista. Il file .cab contiene i log 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 menuOpzionistrumenti>, 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 diw3wp.exe in cui È in esecuzione ARR correlando con la colonna UT process name (Nome 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 viene impostato in modo simile al seguente:
UTProcessName == "w3wp.exe (1432)"
È possibile filtrare ulteriormente i risultati modificandolo nel modo seguente:
UTProcessName == "w3wp.exe (<pid>)" AND ProtocolName == "WINHTTP_MicrosoftWindowsWinHttp"
È necessario scorrere l'output fino a trovare l'errore di timeout. Nell'esempio seguente è stato eseguito il timeout di una richiesta perché sono stati richiesti più di 30 secondi (timeout predefinito di 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)
Nell'esempio seguente il server del 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 richiesta non riuscita
- 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