Comment puis-je résoudre les erreurs HTTP 502 de l'Application Load Balancer ?

Brève description

Le protocole HTTP 502 peut avoir plusieurs causes : des erreurs de passerelle défectueuses, qui peuvent provenir de votre cible ou de votre Application Load Balancer. Pour identifier la source de l'erreur, utilisez les métriques](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html) et les journaux d'[accès Amazon CloudWatch.

Avant de résoudre l'erreur depuis votre Application Load Balancer, assurez-vous d'activer la journalisation des accès. Pour comprendre la signification de chaque champ dans le journal d'accès, voir Entrées du journal d'accès.

Si la cible est une fonction AWS Lambda, consultez** Résoudre les erreurs HTTP 502 lorsque la cible est une fonction Lambda** dans la section Résolution.

Résolution

Trouvez la source des erreurs HTTP 502

Utilisation des métriques CloudWatch

Si des points de données apparaissent sous la** métrique** HTTPCode_ELB_502_Count, cela signifie que votre équilibreur de charge est à l'origine des erreurs HTTP 502. S'ils apparaissent sous la** métrique** HTTPCode_Target_5XX_Count, votre cible est la source.

Utilisation des journaux d'accès

Si le** elb_status_code** est « 502 » et que la** target_status_code** est « - », votre équilibreur de charge est à l'origine des erreurs HTTP 502. Si le** elb_status_code** est « 502 » et que la** target_status_code** est « 502 », alors votre cible est à l'origine des erreurs.

Résoudre les erreurs HTTP 502

Remarque :Filtrez les journaux d'accès par elb_status_code = « 502 » et** target_status_code** pour vous aider à en déterminer la cause. Suivez ensuite les étapes correspondant à votre cas d'utilisation.

L'équilibreur de charge a reçu un TCP RST de la cible lors de la tentative d'établissement d'une connexion

Si vous recevez un TCP RST de la cible lors de l'établissement d'une connexion, cela signifie que l'équilibreur de charge ne peut pas établir un échange TCP à 3 voies avec la cible. Par conséquent, l'équilibreur de charge ne peut pas transmettre la demande de l'utilisateur à la cible.

• Vérifiez s'il existe des points de données pour la** métrique** TargetConnectionErrorCount. Cette métrique représente le nombre de connexions qui n'ont pas été établies avec succès entre l'équilibreur de charge et la cible.
• Vérifiez si les champs ** request_processing_time**,** target_processing_time**, et ** response_processing_time**, des journaux d'accès sont tous définis sur la valeur -1. Cette valeur signifie que l'équilibreur de charge ne peut pas envoyer la demande à la cible car elle a besoin d'une connexion réussie.

Voici un exemple d'entrée de journal d'accès :

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"

Remarque :Dans cette entrée du journal d'accès, la request_processing_time, la** target_processing_time** et la** response_processing_time** sont chacune définies sur** -1**.

L'équilibreur de charge a reçu une réponse inattendue de la cible, telle que « Destination ICMP inaccessible (hôte inaccessible) », lors de la tentative d'établissement d'une connexion

• Vérifiez si les champs** request_processing_time**,** target_processing_time** et** response_processing_time** des journaux d'accès sont tous définis sur la valeur -1.
• Vérifiez si le trafic est autorisé depuis les sous-réseaux de l'équilibreur de charge vers les cibles sur le port cible.

La cible a fermé la connexion avec un TCP RST ou un TCP FIN alors que l'équilibreur de charge avait une demande en suspens à destination de la cible

L'équilibreur de charge reçoit une demande et la transmet à la cible. La cible reçoit la demande et commence à la traiter, mais ferme la connexion à l'équilibreur de charge trop tôt. Cela se produit généralement lorsque la durée du délai de** maintien en vie** pour la cible est inférieure à la valeur de délai** d'inactivité** de l'équilibreur de charge. Assurez-vous que la durée du délai de** maintien en vie** est supérieure à la valeur du** délai d'inactivité**.

Vérifiez les valeurs des champs** request_processing_time**,** target_processing_time** et** response_processing_time**.

Consultez l'exemple d'entrée de journal d'accès suivant :

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"

Remarque :Dans cette entrée du journal d'accès, la request_processing_time est** 0,001**, la** target_processing_time** est** 4,205** et la** response_processing_time** est** -1**.

La réponse cible est mal formée ou contient des en-têtes HTTP non valides

Effectuez une capture de paquets sur la cible pendant la période du problème afin de comprendre la réponse de la cible.

L'équilibreur de charge a rencontré une erreur de liaison SSL ou un délai d'expiration de la liaison SSL (10 secondes) lors de la connexion à une cible

La connexion TCP entre l'équilibreur de charge et l'écouteur HTTPS de la cible est réussie, mais le délai d'établissement de liaison SSL suivant expire. Par conséquent, l'équilibreur de charge ne peut pas transmettre la demande à la cible.

Vérifiez si le groupe cible utilise le protocole HTTPS. S'il n'utilise pas le protocole HTTPS, le délai d'expiration de la liaison SSL n'est pas à l'origine du problème. Si le groupe cible utilise le protocole HTTPS, vérifiez les points suivants :

• Vérifiez si les champs** request_processing_time**,** target_processing_time** et** response_processing_time** des journaux d'accès sont tous définis sur la valeur -1.
• Vérifiez s'il existe des points de données pour la** métrique** TargetTLSNegotiationErrorCount.
• Effectuez une capture de paquets sur la cible pendant la période du problème afin de vérifier qu'il est lié à une prise de contact SSL. Si tel est le cas, suivez les étapes de la** section** Exécuter une capture de paquets.
• Vérifiez si les chiffrements ou les protocoles ne correspondent pas.

Le délai de désinscription s'est écoulé pour une demande traitée par une cible qui a été désenregistrée

Dans vos événements CloudTrail, recherchez la présence d'un appel d'API avec l'](https://docs.aws.amazon.com/elasticloadbalancing/latest/APIReference/API_DeregisterTargets.html)action DeregisterTargets pendant la période du problème. Si un appel d'API avec** DeregisterTargets** s'est produit pendant la période du problème, l'erreur est due à une cible qui a été désenregistrée trop tôt. Pour résoudre ce problème, augmentez le délai de[ désinscription afin que les opérations de longue durée puissent se terminer sans échec.

Résoudre les erreurs HTTP 502 lorsque la cible est une fonction Lambda

Remarque :Pour les demandes adressées à une fonction Lambda qui échouent, l'équilibreur de charge stocke les codes de raison d'erreur spécifiques à Lambda dans le champ error_reason des journaux d'accès.

La cible est une fonction Lambda et le corps de la réponse dépasse 1 Mo

• Vérifiez s'il existe un point de données pour la métrique** LambdaUserError**.
• Vérifiez si le champ** error_reason** du journal d'accès à l'équilibreur de charge est défini sur** LambdaResponseTooLarge**.

La cible est une fonction Lambda qui n'a pas répondu avant que le délai d'expiration configuré ne soit atteint

• Vérifiez la configuration du délai d'expiration de la fonction Lambda.
• Vérifiez s'il existe un point de données pour la métrique** LambdaUserError**.
• Vérifiez si le champ** error_reason** du journal d'accès à l'équilibreur de charge est défini sur** LambdaUnhandled**.

La cible est une fonction Lambda qui a renvoyé une erreur, ou la fonction a été limitée par le service Lambda

Contactez AWS Support pour obtenir des conseils sur la limitation des services.

Effectuer une capture de paquets

Pour Linux, utilisez la commande suivante :

sudo tcpdump -i any -w filename.pcap

Pour Microsoft Windows, téléchargez et utilisez l'application Wireshark (à partir du site Web de Wireshark).

Pour plus de détails, voir Comment résoudre les problèmes de performances réseau entre les instances EC2 Linux ou Windows d'un VPC et un hôte sur site via la passerelle Internet ?Reportez-vous aux** sections** Tester la capture de paquets à l'aide de tcpdump** et** Réaliser une capture de paquets.