Solución de problemas de errores 502 en ARR
Este artículo le ayuda a resolver los problemas relacionados con los errores 502 en el enrutamiento de solicitudes de aplicación (ARR).
Se aplica a: Internet Information Services
HTTP 502: información general
Cuando se trabaja con implementaciones de enrutamiento de solicitudes de aplicaciones (ARR) de IIS, uno de los errores que puede ver es "HTTP 502 - Puerta de enlace incorrecta". El error 502.3 significa que, al actuar como proxy, ARR no pudo completar la solicitud al servidor ascendente y enviar una respuesta al cliente. Este problema puede producirse por varias razones. Por ejemplo, un error al conectarse al servidor, ninguna respuesta del servidor o el servidor tardó demasiado tiempo en responder (tiempo de espera). Si puede reproducir el error examinando la granja web desde el controlador y los errores detallados están habilitados en el servidor, es posible que vea un error similar al siguiente mensaje de error:
La causa principal del error determina lo que debe hacer para resolver el problema.
Errores de tiempo de espera 502.3
ARR usa el código de error de la captura de pantalla anterior para proxyar la solicitud y determinar el origen del error porque contiene el código devuelto de WinHTTP.
Puede descodificar el código de error con la herramienta err.exe. En este ejemplo, el código de error se asigna a ERROR_WINHTTP_TIMEOUT. También puede encontrar esta información en los registros de IIS del sitio web asociado en el controlador ARR. A continuación se muestra un extracto de la entrada de registro de IIS para el error 502.3, con la mayoría de los campos recortados para mejorar la legibilidad:
| sc-status | sc-substatus | sc-win32-status | tiempo necesario |
|---|---|---|---|
| 502 | 3 | 12002 | 29889 |
El estado de win32 12002 se asigna al mismo ERROR_WINHTTP_TIMEOUT error notificado en la página de error.
¿Qué tiempo de espera se agotó exactamente?
Para comprobar este tiempo de espera, habilite Seguimiento de solicitudes con errores en el servidor IIS. El primer punto que puede ver, en el registro de seguimiento de solicitudes con error y aquí es donde se envió la solicitud en el evento ARR_SERVER_ROUTED. El segundo punto es X-ARR-LOG-ID, que puede usar para realizar un seguimiento de la solicitud en el servidor de destino. Esto ayuda a realizar un seguimiento del destino o destino de la solicitud 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
En el ejemplo siguiente se muestra cómo podría verse en los registros de seguimiento de solicitudes con error del servidor de destino. Puede validar que ha encontrado la solicitud correcta mediante la coincidencia de los valores "X-ARR-LOG-ID" en ambos seguimientos.
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
En el ejemplo anterior, puede ver que el servidor ARR se desconectó antes de enviar la respuesta HTTP. La marca de tiempo de GENERAL_FLUSH_RESPONSE_END se puede usar como guía aproximada para buscar la entrada correspondiente en los registros de IIS en el servidor de destino.
| date | time | s-ip | cs-method | cs-uri-stem | cs-uri-query | s-port | cs-username | sc-status | sc-substatus | sc-win32-status | tiempo necesario |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 2011-07-18 | 16:51:06 | 192.168.0.216 | GET | /hora/ | - | 80 | - | 200 | 0 | 64 | 45208 |
IIS en el servidor de destino registró un código de estado HTTP 200, lo que indica que la solicitud se completó correctamente. Además, el estado de win32 ha cambiado a 64, que se asigna a ERROR_NETNAME_DELETED. Este código de estado generalmente indica que el cliente (ARR es el "cliente" en este caso) desconectado antes de que se complete la solicitud.
Causa
El servidor de ARR informó de un tiempo de espera, que es donde debe buscar primero.
Aunque el registro del servidor miembro indica que la respuesta se envió en 45 segundos (45208 ms), la entrada de registro de IIS desde el servidor ARR indica que el tiempo necesario es muy cercano a 30 segundos. Esto indica que ARR agota el tiempo de espera de la solicitud y puede confirmarlo examinando el tiempo de espera del proxy en la configuración de proxy de la granja de servidores. De forma predeterminada, se establece en 30 segundos.
Por lo tanto, en este caso, puede ver claramente que el tiempo de espera de ARR era más corto que la ejecución de la solicitud. Por lo tanto, es posible que desee comprobar si este tiempo de ejecución era típico o si necesitaba examinar por qué la solicitud tardaba más de lo esperado. Si se esperaba este tiempo de ejecución y era normal, el aumento del tiempo de espera de ARR debería resolver el error.
Otras posibles razones para ERROR_WINHTTP_TIMEOUT incluyen:
ResolveTimeout: se produce si la resolución de nombres tarda más tiempo que el período de tiempo de espera especificado.ConnectTimeout: se produce si se tarda más tiempo que el período de tiempo de espera especificado en conectarse al servidor después de resolver el nombre.SendTimeout: se produce si el envío de una solicitud tarda más que este valor de tiempo de espera. Se cancela la operación de envío.ReceiveTimeout: se produce si una respuesta tarda más que este valor de tiempo de espera. La solicitud se cancela.
Al observar los dos primeros motivos, ResolveTimeout y ConnectTimeout, la metodología de solución de problemas descrita anteriormente no funcionaría. Esto se debe a que no vería ningún tráfico en el servidor de destino y, por lo tanto, no conocería el código de error. Por lo tanto, en este caso de ResolveTimeout o ConnectTimeout es posible que desee capturar un seguimiento winHTTP para obtener información adicional. Consulte la sección Seguimiento de WinHTTP o WEBIO y en los blogs siguientes para obtener otros ejemplos sobre la solución de problemas y el seguimiento:
- 502.3 Puerta de enlace incorrecta "Se agotó el tiempo de espera de la operación" con el enrutamiento de solicitudes de aplicación de IIS (ARR)
- Opciones de seguimiento de Winhttp para solucionar problemas con el enrutamiento de solicitudes de aplicación
502.3 Errores de terminación de conexión
También se devuelven errores 502.3 cuando la conexión entre ARR y el servidor miembro se desconecta a mitad del flujo. Para probar este tipo de problema, cree una página de .aspx que llame a Response.Close(). En el ejemplo siguiente, hay un directorio denominado "time", que se configura con una página de .aspx como documento predeterminado en ese directorio. Al intentar examinar el directorio, ARR muestra el siguiente mensaje de error:
El 0x80072efe de error corresponde a ERROR_INTERNET_CONNECTION_ABORTED. La solicitud se puede realizar un seguimiento del servidor que realmente la procesó con los mismos pasos usados anteriormente en este solucionador de problemas, con una excepción. Aunque el seguimiento de solicitudes con errores en el servidor de destino muestra la solicitud procesada en el servidor, la entrada de registro asociada no aparece en los registros de IIS. En su lugar, esta solicitud se registra en el registro HTTPERR de la siguiente manera:
HTTP/1.1 GET /time/ - 1 Connection_Dropped DefaultAppPool
Los registros integrados en el servidor de destino no proporcionan información adicional sobre el problema, por lo que el siguiente paso sería recopilar un seguimiento de red del servidor ARR. En el ejemplo anterior, se llamó a Response.Close() la página .aspx sin devolver datos. Ver esto en un seguimiento de red mostraría que un Connection: close encabezado HTTP provenía del servidor de destino. Con esta información, podría iniciar una investigación sobre por qué se envió el Connection: close encabezado.
El siguiente error es otro ejemplo de una respuesta no válida del servidor miembro:
En este ejemplo, ARR comenzó a recibir datos del cliente, pero algo salió mal al leer el cuerpo de la entidad de solicitud. Esto provocó que se devolvió el código de error de 0x80072f78. Para investigar más, use Monitor de red en el servidor miembro para obtener un seguimiento de red del problema. Este ejemplo de error concreto se creó llamando a Response.Close() en la página ASP.net después de enviar parte de la respuesta y, a continuación, llamar a Response.Flush(). Si el tráfico entre el servidor ARR y los servidores miembros es a través de SSL, el seguimiento winHTTP en Windows Server 2008 o el seguimiento de WebIO en Windows Server 2008 R2 puede proporcionar información adicional. El seguimiento de WebIO se describe más adelante en este solucionador de problemas.
502.4 No se encontró ningún servidor adecuado para enrutar la solicitud.
El error HTTP 502.4 con un código de error asociado de 0x00000000 generalmente indica que todos los miembros de la granja están sin conexión o no se puede acceder a ellos.
El primer paso consiste en comprobar que los servidores miembros están en línea. Para comprobarlo, vaya al nodo Servidores de la granja en el Administrador de IIS.
Para devolver los servidores sin conexión, haga clic con el botón derecho en el nombre del servidor y seleccione Agregar al equilibrio de carga. Si no puede volver a poner los servidores en línea, compruebe si los servidores miembros son accesibles desde el servidor ARR. Compruebe el panel Mensajes de seguimiento en la página Servidores para buscar algunas pistas sobre el problema. Si usa Web Farm Framework (WFF) 2.0, puede recibir este error cuando se reinicie el grupo de aplicaciones. Debe reiniciar el servicio de granja de servidores web para recuperarlo.
Seguimiento de WinHTTP o WebIO
Por lo general, las herramientas de captura de paquetes como WireShark proporcionan la información que necesita para identificar exactamente qué se agota el tiempo de espera. Sin embargo, hay ocasiones (como cuando el tráfico está cifrado con SSL) que tendrá que probar un enfoque diferente. A partir de Windows 7 y Windows Server 2008 R2, puede habilitar el seguimiento winHTTP mediante la herramienta netsh ejecutando el siguiente comando desde un símbolo del sistema administrativo:
netsh trace start scenario=internetclient capture=yes persistent=no level=verbose tracefile=c:\temp\net.etl
A continuación, reproduzca el problema. Una vez reproducido el problema, detenga el seguimiento ejecutando el siguiente comando:
netsh trace stop
El stop comando tarda unos segundos en finalizar. Cuando haya terminado, encontrará un archivo net.etl y un archivo net.cab en C:\temp. Deberá asegurarse de que la C:\temp carpeta existe antes de ejecutar los comandos anteriores. El archivo .cab contiene registros de eventos y otros datos que pueden resultar útiles para analizar el archivo .etl.
Para analizar el registro,
Ábralo en Netmon 3.4 o posterior.
Asegúrese de que ha configurado el perfil del analizador. Para ello, abra el menúOpciones de herramientas>, seleccione la pestaña >Perfiles del analizador perfil de Windows y, a continuación, seleccione el botón Establecer como activo para aplicar los cambios.
Desplácese por el seguimiento hasta encontrar la instancia dew3wp.exe donde se ejecuta ARR mediante la correlación con la columna nombre del proceso UT .
Haga clic con el botón derecho en w3wp y seleccione Agregar nombre del proceso ut para mostrar el filtro. Esto establece el filtro de visualización de forma similar a:
UTProcessName == "w3wp.exe (1432)"
Para filtrar aún más los resultados, cámbielos por lo siguiente:
UTProcessName == "w3wp.exe (<pid>)" AND ProtocolName == "WINHTTP_MicrosoftWindowsWinHttp"
Tendrá que desplazarse por la salida hasta que encuentre el error de tiempo de espera. En el ejemplo siguiente, se agotó el tiempo de espera de una solicitud porque tardó más de 30 segundos (tiempo de espera predeterminado de ARR) en ejecutarse.
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)
En el ejemplo siguiente, el servidor de contenido estaba completamente sin conexión:
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}
Otros recursos
- Herramienta de búsqueda de errores
- Códigos de error winhttp
- Seguimiento de solicitudes con error
- Seguimiento de Winhttp
- Monitor de red
Aviso de declinación de responsabilidades sobre la información de terceros
Los productos de otros fabricantes que se mencionan en este artículo han sido creados por compañías independientes de Microsoft. Microsoft no ofrece ninguna garantía, ya sea implícita o de otro tipo, sobre la confiabilidad o el rendimiento de dichos productos.
Comentarios
Próximamente: A lo largo de 2024 iremos eliminando gradualmente GitHub Issues como mecanismo de comentarios sobre el contenido y lo sustituiremos por un nuevo sistema de comentarios. Para más información, vea: https://aka.ms/ContentUserFeedback.
Enviar y ver comentarios de