¿Cómo puedo solucionar los errores HTTP 502 del equilibrador de carga de aplicación?

Breve descripción

Los errores HTTP 502: bad gateway pueden deberse a varios motivos. El origen del error puede estar en el destino o en el equilibrador de carga de aplicación. Para identificar el origen del error, utilice las métricas de Amazon CloudWatch y los registros de acceso.

Antes de solucionar el error desde el equilibrador de carga de aplicación, asegúrese de activar el registro de acceso. Para entender qué significa cada campo del registro de acceso, consulte Entradas de los registros de acceso.

Si el destino es una función de AWS Lambda, consulte Solución de errores HTTP 502 cuando el destino es una función de Lambda en la sección Resolución.

Resolución

Búsqueda del origen de los errores HTTP 502

Uso de las métricas de CloudWatch

Si los puntos de datos aparecen en la métrica HTTPCode_ELB_502_Count, el equilibrador de carga es el origen de los errores HTTP 502. Si aparecen en la métrica HTTPCode_Target_5XX_Count, el origen de los errores está en el destino.

Uso de registros de acceso

Si el elb_status_code es «502» y el target_status_code es «-», el equilibrador de carga es el origen de los errores HTTP 502. Si el elb_status_code es «502» y el target_status_code es «502», el origen de los errores es el destino.

Solución de errores HTTP 502

Nota: Filtre los registros de acceso por elb_status_code = "502" y target_status_code para determinar la causa más fácilmente. A continuación, complete los pasos pertinentes para su caso de uso.

El equilibrador de carga recibió un TCP RST del destino al intentar establecer una conexión

Es posible que reciba TCP RST del destino al establecer una conexión. Este mensaje aparece cuando el equilibrador de carga no puede establecer un protocolo de enlace TCP de 3 vías con el objetivo. Como resultado, el equilibrador de carga no puede reenviar la solicitud del usuario al destino.

Compruebe si los campos request_processing_time, target_processing_time y response_processing_time de los registros de acceso se han configurado con el valor -1. Este valor significa que el equilibrador de carga no puede enviar la solicitud al destino porque necesita una conexión correcta.

A continuación, aparece un ejemplo de una entrada de registro de acceso:

http 2022-04-15T16:52:50.757968Z app/my-loadbalancer/50dc6c495c0c9188 192.168.131.39:2817 10.0.0.1:80 -1 -1 -1 502 - 86 155 "GET http://example.com:80/ HTTP/1.1" "curl/7.51.0" - - arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/my-targets/73e2d6bc24d8a067" Root=1-58337262-36d228ad5d99923122bbe354"

**Nota:**En esta entrada de registro de acceso, request_processing_time, target_processing_time y response_processing_time están configurados en -1.

El equilibrador de carga recibió una respuesta inesperada del destino, como «ICMP Destination unreachable (Host unreachable)» al intentar establecer una conexión

• Compruebe si los campos request_processing_time, target_processing_time y response_processing_time de los registros de acceso tienen configurado el valor -1.
• Compruebe si se permite el tráfico desde las subredes del equilibrador de carga a los destinos en el puerto de destino.

El destino cerró la conexión con un TCP RST o un TCP FIN mientras el equilibrador de carga tenía una solicitud pendiente al destino

El equilibrador de carga recibe una solicitud y la reenvía al destino. El destino recibe la solicitud y comienza a procesarla, pero cierra la conexión con el equilibrador de carga demasiado pronto. Esto suele ocurrir cuando la duración del tiempo de espera de mantenimiento de actividad del destino es inferior al valor de tiempo de espera de inactividad del equilibrador de carga. Asegúrese de que la duración del tiempo de espera de mantenimiento de actividad sea mayor que el valor del tiempo de espera de inactividad.

Compruebe los valores de los campos request_processing_time, target_processing_time y response_processing_time.

Consulte el siguiente ejemplo de entrada de registro de acceso:

http 2022-04-15T16:52:50.757968Z app/my-loadbalancer/50dc6c495c0c9188 192.168.131.39:2817 10.0.0.1:80 0.001 4.205 -1 502 - 94 326 "GET http://example.com:80 HTTP/1.1" "curl/7.51.0" - - arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/my-targets/73e2d6bc24d8a067 "Root=1-58337262-36d228ad5d99923122bbe354"

**Nota:**En esta entrada del registro de acceso, request_processing_time es 0.001, target_processing_time es 4.205 y response_processing_time es -1.

La respuesta del destino tiene un formato incorrecto o encabezados HTTP que no son válidos

Haga una captura de paquetes en el destino durante el período de tiempo del problema para comprender la respuesta del destino.

El equilibrador de carga detectó un error de protocolo de enlace SSL o un tiempo de espera de protocolo de enlace SSL (10 segundos) al conectarse a un destino

La conexión TCP desde el equilibrador de carga al agente de escucha HTTPS del destino se lleva a cabo correctamente, pero se agota el tiempo de espera del protocolo de enlace SSL posterior. Como resultado, el equilibrador de carga no puede reenviar la solicitud al destino.

Compruebe si el grupo de destino utiliza el protocolo HTTPS. Si no es así, el problema no se debe al tiempo de espera del protocolo de enlace de SSL. Si el grupo de destino utiliza el protocolo HTTPS, compruebe los siguientes puntos:

• Compruebe si los campos request_processing_time, target_processing_time y response_processing_time de los registros de acceso tienen configurado el valor -1.
• Compruebe si existen puntos de datos para la métrica TargetTLSNegotiationErrorCount.
• Haga una captura de paquetes en el destino durante el período de tiempo del problema para validar que esté relacionado con un protocolo de enlace SSL. Si es así, complete los pasos de la sección Realización de una captura de paquetes.
• Verifique que los cifrados o los protocolos coincidan.

El periodo de retraso de cancelación del registro transcurrió para una solicitud gestionada por un destino cuyo registro se canceló

En los eventos de CloudTrail, compruebe si hay una llamada a la API con la acción DeregisterTargets durante el periodo de tiempo del problema. Una llamada a la API con DeregisterTargets durante la duración del problema provoca un error. Este error se produce si el registro del destino se canceló demasiado pronto. Para solucionar este problema, aumente el periodo de retraso de cancelación del registro para que las operaciones más prolongadas puedan completarse sin errores.

Solución de los errores HTTP 502 cuando el destino es una función de Lambda

Nota: Para las solicitudes a una función de Lambda que fallan, el equilibrador de carga almacena los códigos de motivo de error específicos de Lambda en el campo error_reason de los registros de acceso.

El destino es una función de Lambda y el cuerpo de la respuesta supera 1 MB

• Compruebe si existe un punto de datos para la métrica LambdaUserError.
• Compruebe si el campo error_reason del registro de acceso del equilibrador de carga se ha configurado como LambdaResponseTooLarge.

El destino es una función de Lambda que no respondió antes de que se alcanzara el tiempo de espera configurado

• Verifique la configuración del tiempo de espera de la función de Lambda.
• Compruebe si existe un punto de datos para la métrica LambdaUserError.
• Compruebe si el campo error_reason del registro de acceso del equilibrador de carga se ha configurado como LambdaUnhandled.

El destino es una función de Lambda que devolvió un error o la función fue limitada por el servicio de Lambda

• Verifique que exista un punto de datos para la métrica Throttles.
• Póngase en contacto con AWS Support para que le orienten acerca de la limitación de servicios.

Realización de una captura de paquetes

En Linux, utilice el siguiente comando:

sudo tcpdump -i any -w filename.pcap

En Windows, descargue la aplicación Wireshark (del sitio web de Wireshark) y utilícela.

Para obtener instrucciones sobre cómo probar muestras de captura de paquetes con tcpdump o utilizar un paquete de captura, consulte ¿Cómo soluciono los problemas de rendimiento de red entre las instancias de EC2 de Linux o Windows en una VPC y un host local a través de la puerta de enlace de Internet?