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

Résolution

Identifier la source des erreurs HTTP 502

Le protocole HTTP 502 : Passerelle erronée peut avoir plusieurs causes. La source de l'erreur peut être votre cible ou votre équilibreur de charge. Pour identifier la source de l’erreur, utilisez les métriques CloudWatch et les journaux d’accès.

Utiliser les métriques CloudWatch

Si la métrique HTTPCode_ELB_502_Count comporte des points de données, votre équilibreur de charge est la source de l'erreur. Si la métrique HTTPCode_Target_5XX_Count comporte des points de données, la cause provient de votre cible.

Utiliser les journaux d'accès

Si elb_status_code est "502" et que target_status_code est "-", votre équilibreur de charge est à l'origine de l’erreur. Si elb_status_code est "502" et target_status_code est "502", votre cible est à l'origine de l’erreur.

Résoudre les erreurs HTTP 502

Pour déterminer la cause, filtrez les journaux d'accès par **elb_status_code = **** et **target_status_code"502". Puis, terminez la résolution du problème que vous rencontrez.

L'équilibreur de charge reçoit un RST TCP de la cible lorsqu'il tente d'établir une connexion

Vous pouvez recevoir un message TCP RST de la cible lorsque vous établissez une connexion. Ce message apparaît lorsque l’équilibreur de charge ne parvient pas à établir une liaison TCP tridirectionnelle avec la cible. Par conséquent, l’équilibreur de charge ne peut pas transmettre la requête de l’utilisateur à la cible.

Vérifiez la métrique TargetConnectionErrorCount pour les points de données indiquant que la cible rejette les connexions de l'équilibreur de charge avec un TCP RST.

Dans les journaux d’accès, définissez les champs request_processing_time, target_processing_time et response_processing_time sur la valeur -1. Lorsque vous définissez la valeur sur \ -1, l'équilibreur de charge ne peut pas envoyer la requête à la cible car vous devez connecter l'équilibreur de charge.

Voici un exemple d'entrée de journal d'accès dont les champs request_processing_time, target_processing_time et response_processing_time sont définis sur -1 :

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"

**L'équilibreur de charge reçoit une réponse inattendue de la cible, par exemple **, lorsqu'il essaie de se connecter"ICMP Destination unreachable (Host unreachable)"

Vérifiez si les champs request_processing_time, target_processing_time et response_processing_time dans les journaux d’accès sont définis sur la valeur -1. Puis, vérifiez que les sous-réseaux de l'équilibreur de charge autorisent le trafic 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 requête en suspens à destination de la cible

L'équilibreur de charge reçoit une requête et la transmet à la cible. La cible reçoit la requête 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 d’expiration keep-alive pour la cible est inférieure à la valeur du délai d'inactivité de l'équilibreur de charge. Assurez-vous que la durée du délai d’expiration keep-alive est supérieure à la valeur d’inactivité.

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

Pour comprendre la réponse cible, effectuez une capture de paquets sur la cible pendant la période du problème.

Pour effectuer une capture de paquets pour Linux, exécutez la commande suivante :

sudo tcpdump -i any -w filename.pcap

Important : Si le trafic de l'instance cible est important, le fichier PCAP (Packet Capture) généré par la collection tcpdump peut affecter votre espace disque. Un trafic important peut également affecter les services de votre instance cible.

Pour Windows, téléchargez et utilisez l’application Wireshark à partir du site Web de Wireshark.

Pour tester les échantillons de capture de paquets à l’aide de tcpdump, consultez la section Comment résoudre les problèmes de performance entre les instances Amazon Elastic Compute Cloud (Amazon EC2) Linux ou Windows d’un hôte Amazon Virtual Private Cloud (Amazon VPC) et sur site via la passerelle Internet ?

L'équilibreur de charge rencontre une erreur d'établissement de liaison SSL lorsqu'il se connecte à 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 rencontre une erreur. Par conséquent, l’équilibreur de charge ne peut pas transmettre la requête à la cible.

Si le groupe cible utilise le protocole HTTPS, effectuez une capture de paquets sur la cible pendant la durée du problème.

Votre serveur doit utiliser une suite de chiffrement TLS prise en charge par la politique de sécurité utilisée par votre équilibreur de charge pour les connexions de backend.

Le délai d’annulation d’enregistrement écoulé pour une requête gérée par une cible dont l’enregistrement a été annulé

Dans vos événements CloudTrail, recherchez l’action d’API DeregisterTargets pendant la période du problème. Si l’enregistrement de la cible a été annulé trop tôt, une erreur HTTP 502 se produit. Pour résoudre ce problème, augmentez le délai d’annulation d’enregistrement afin que les opérations de longue durée puissent se terminer.

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

Pour les requêtes qui ne parviennent pas à une fonction AWS Lambda, vérifiez les codes de raison de l'erreur Lambda dans le champ error_reason des journaux d'accès de l'équilibreur de charge.

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

Pour confirmer le problème, vérifiez s'il existe un point de données pour la métrique LambdaUserError. Ou bien, vérifiez si le champ error_reason du journal d'accès à l'équilibreur de charge est défini sur LambdaResponseTooLarge.

Pour résoudre le problème, mettez à jour votre code Lambda et ajoutez une logique de gestion d’erreurs.

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

Pour confirmer le problème, vérifiez s'il existe un point de données pour la métrique LambdaUserError. Ou bien, 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 Lambda a limité la fonction

Pour vérifier si Lambda a limité la fonction, vérifiez la métrique Limitations pour un point de données. Si Lambda a limité la fonction, utilisez AWS Service Quotas pour demander une augmentation du quota pour l'exécution simultanée de Lambda.

Pour plus d'informations, consultez la section Comprendre les limites de limitation des appels Lambda.