Codes d'erreur ALB - Server Load Balancer - Centre de documentation Alibaba Cloud

Nous vous recommandons d'activer les journaux d'accès ALB pour diagnostiquer rapidement les erreurs HTTP provenant d'ALB. Commencez par comparer le code d'état ALB (dans le champ status) avec le code d'état du backend (dans le champ upstream_status) dans le journal d'accès. Si les valeurs sont identiques, ALB a probablement transmis le code d'état du serveur backend. Dans ce cas, privilégiez le dépannage du service backend.

Cinq vérifications rapides

Avant de procéder au dépannage par code d'état, effectuez ces cinq vérifications. Elles permettent de résoudre les causes racines les plus fréquentes des pannes ALB.

Exécutez l'outil de diagnostic de l'instance ALB. Sur la page Instances, repérez l'instance cible. Dans la colonne Instance Diagnostics, cliquez sur Diagnose pour lancer une vérification automatique des problèmes courants liés aux configurations de l'instance, aux écouteurs et aux services backend.
Vérifiez que l'Health Check Status de l'écouteur est défini sur Healthy. Sur la page Listener Details, consultez l'Health Check Status du groupe de serveurs backend. Si l'état est Unhealthy, reportez-vous à la rubrique Dépannage des échecs de contrôle d'intégrité ALB.
Assurez-vous que l'ECS backend ne bloque pas le bloc CIDR du vSwitch où réside l'instance ALB. ALB communique avec les serveurs backend en utilisant une adresse Local IP attribuée par son vSwitch. Si des règles iptables ou un logiciel de sécurité tiers installé sur une instance ECS backend bloque le bloc CIDR du vSwitch, ALB ne peut pas atteindre le backend, ce qui peut déclencher des erreurs telles que 502 ou 504.
Confirmez que le port configuré pour un serveur backend dans le groupe de serveurs correspond au port sur lequel le service backend écoute réellement. Le port configuré pour chaque serveur backend dans un groupe de serveurs ALB doit correspondre au port écouté par le processus applicatif. Par exemple, si le port est configuré sur 8080 dans le groupe de serveurs mais que le service backend écoute sur le port 80, la connexion échouera. Exécutez ss -tlnp | grep ':<port> ' ou netstat -tlnp | grep ':<port> ' sur l'ECS backend pour vérifier.
Pour les écouteurs HTTPS, vérifiez que le certificat n'a pas expiré et que son domaine correspond au domaine d'accès. Sur la page Listener Details, examinez le certificat associé et sa date d'expiration. Un certificat expiré ou une inadéquation de domaine peut provoquer des échecs de handshake SSL ou renvoyer un code d'état d'erreur.

502 Bad Gateway

Cette erreur survient lorsqu'un écouteur HTTP ou HTTPS reçoit une requête client, mais qu'ALB échoue à transmettre la requête à un serveur backend ou à recevoir une réponse de celui-ci.

Approche de dépannage : Vérifiez d'abord la valeur du champ upstream_status dans le journal d'accès pour déterminer les étapes suivantes.

Si upstream_status = 502 : ALB a transmis le code d'état 502 provenant du serveur backend. Le problème réside dans le service backend lui-même. Examinez votre service backend. Par exemple, vérifiez si une couche Nginx ou passerelle backend tente d'effectuer un reverse proxy vers un upstream inaccessible.
Si upstream_status est une autre valeur (telle que 504, 444 ou 500) : Le status qu'ALB renvoie au client diffère de upstream_status, ce qui signifie qu'ALB a modifié le code d'état. Cherchez pourquoi le service backend renvoie ce code d'état spécifique en consultant les journaux Nginx, de la passerelle ou de l'application backend.
Si upstream_status est - ou vide : ALB n'a reçu aucune réponse du backend. Cela signifie que la requête n'a jamais atteint le backend, ou que la connexion backend a été interrompue de manière anormale avant l'envoi d'une réponse. Vérifiez les causes suivantes dans l'ordre :
- La communication TCP entre ALB et le serveur backend échoue. Vérifiez que le service backend est en cours d'exécution, que le port de service écoute correctement et qu'aucune règle iptables ni logiciel de sécurité tiers sur l'ECS backend ne bloque le bloc CIDR du vSwitch où se trouve l'instance ALB. ALB communique avec les serveurs backend en utilisant une adresse Local IP attribuée par le vSwitch. Capturez les paquets pour vérifier si le handshake TCP aboutit.
- La file d'attente (backlog) du serveur backend est pleine. Cela amène le serveur à rejeter les nouvelles demandes de connexion. Exécutez netstat -s | grep -i listen sur le serveur backend et vérifiez la présence d'un compteur drop.
- Le serveur backend n'a pas pu traiter la requête à temps. Consultez les journaux du serveur backend et examinez l'utilisation du CPU et de la mémoire pour identifier d'éventuels goulets d'étranglement de performance.
- La taille des paquets de la requête client dépasse la MTU du serveur backend. Cela peut entraîner la réussite des paquets courts (comme les contrôles d'intégrité) tandis que les paquets longs échouent. Capturez les paquets sur le serveur backend pour analyser si la longueur des paquets respecte les limites requises.
- La réponse du serveur backend présente un format invalide ou contient des en-têtes HTTP invalides. Capturez les paquets sur le serveur backend pour analyser si le format de la réponse est conforme aux standards.

400 Bad Request

Le format de la requête est invalide.

Le backend renvoie directement 400 : Consultez le journal d'accès. Si upstream_status est 400, ALB a probablement transmis le code d'état du backend. Examinez le service backend.
Une requête HTTP est envoyée à un écouteur HTTPS : Un écouteur HTTPS ALB rejette les requêtes non HTTPS et renvoie un code d'état 400. Vérifiez si le client envoie incorrectement une requête HTTP vers un port HTTPS.
La taille de l'en-tête de requête dépasse la limite : ALB exige que chaque en-tête de requête HTTP ne dépasse pas 32 Ko. Si cette limite est dépassée, ALB renvoie un code d'état 400. Réduisez la taille de l'en-tête de requête.
Le client n'a pas envoyé la requête complète : Le client a fermé la connexion avant d'envoyer la requête HTTP entière. Capturez les paquets sur le client pour identifier la cause.
Le format de l'en-tête de requête est invalide : Par exemple, la valeur de Content-Length ne correspond pas à la longueur réelle du corps de la requête. Capturez les paquets sur le client, analysez le format de la requête HTTP et comparez-le avec une requête valide.

405 Method Not Allowed

La méthode de requête n'est pas prise en charge.

Restriction ALB : ALB ne prend pas en charge la méthode de requête TRACE. Utilisez une autre méthode.
Restriction du service backend : À l'exception de TRACE, la prise en charge des autres méthodes de requête dépend du serveur backend. Pour vérifier, exécutez curl -X METHOD http://<backend_service_IP>:<service_port>, où METHOD est la méthode de requête utilisée par le client.

408 Request Timeout

La requête a expiré et ALB ferme la connexion.

Transmission lente des données côté client : Pendant la période de délai d'attente de la requête client-vers-ALB (par défaut : 60 s), le client n'a envoyé que des données partielles, comme l'envoi de l'HTTP Header sans l'HTTP Body. Capturez les paquets sur le client pour vérifier l'existence de goulets d'étranglement de performance ou d'autres problèmes.
Mauvaise qualité réseau entre le client et ALB : Le temps aller-retour (RTT) TCP est élevé ou d'autres problèmes réseau, tels que la perte de paquets, existent. Nous vous recommandons de vérifier les champs request_time et tcpinfo_rtt dans le journal d'accès, ou d'exécuter des diagnostics réseau sur le client.
Limitation de la bande passante de l'instance ALB : Un trafic élevé vers l'instance ALB a déclenché une limitation de bande passante et une perte de paquets. Vérifiez les métriques outbound bandwidth et Dropped Connections dans Cloud Monitor.

413 Request Entity Too Large

Le corps de la requête est trop volumineux. Vérifiez d'abord la valeur du champ upstream_status dans le journal d'accès pour déterminer si le code d'état 413 est renvoyé par ALB ou transmis depuis le serveur backend.

Si upstream_status = 413 : Le serveur backend a renvoyé le code d'état 413 et ALB l'a transmis. Il s'agit du cas le plus courant. Cela est généralement dû à une limite de taille du corps de la requête configurée sur un serveur proxy backend (tel que Nginx). Examinez la configuration pertinente du service backend, par exemple le paramètre client_max_body_size de Nginx.
Si upstream_status est - ou vide : ALB renvoie lui-même le code d'état 413, ce qui signifie que le corps de la requête dépasse la propre limite de taille d'ALB (50 Go). Ce cas est rare. Nous vous recommandons de réduire la taille du corps de la requête client.

414 URI Too Long

La longueur de l'URI de la requête dépasse la limite et ALB ou le serveur backend a rejeté la requête.

Restriction ALB : ALB exige qu'un URI de requête ne dépasse pas 32 Ko. Sinon, un code d'état 414 est renvoyé. Raccourcissez l'URI. Pour transmettre de grandes quantités de données, vous pouvez utiliser la méthode POST et placer les données dans le corps de la requête. ALB prend en charge un corps de requête POST pouvant atteindre 50 Go.
Restriction du service backend : Si la longueur de l'URI ne dépasse pas la limite ALB mais que le service backend impose une limite plus stricte, ALB transmet le code d'état 414 renvoyé par le backend. Examinez le service backend.

463

Le code d'état 463 est renvoyé uniquement lorsque l'écouteur est associé à un groupe de serveurs de type IP.

Une boucle existe dans le chemin de la requête. Lorsqu'une requête traverse ALB, le système ajoute un champ ALICLOUD-ALB-TRACE à l'HTTP Header. La valeur du champ est un hachage de 16 caractères généré à partir de l'ID de règle. Si des ID de règle en double sont détectés, ou si le nombre de champs ALICLOUD-ALB-TRACE dépasse 16, ALB identifie une boucle. ALB cesse alors de transférer la requête pour éviter une tempête réseau et renvoie un code d'état 463.

Mauvaise configuration du service backend : Le service backend est mal configuré, ce qui l'amène à renvoyer des requêtes vers ALB en boucle. Vérifiez la configuration du service backend de votre ALB.
Défaut d'architecture réseau : Par exemple, plusieurs instances SLB existent dans le chemin de transfert d'une seule requête. Nous vous recommandons d'optimiser l'architecture réseau.

499 Client Closed Request

Le client a activement fermé la connexion.

Mauvaise qualité réseau entre le client et ALB : Le RTT TCP est élevé ou d'autres problèmes réseau, tels que la perte de paquets, existent. Nous vous recommandons de vérifier les champs request_time et tcpinfo_rtt dans le journal d'accès, ou d'exécuter des diagnostics réseau sur le client.
Limitation de la bande passante de l'instance ALB : Un trafic élevé vers l'instance ALB a déclenché une limitation de bande passante et une perte de paquets. Vérifiez les métriques outbound bandwidth et Dropped Connections dans Cloud Monitor.
Temps de traitement backend long : Le temps de traitement backend a dépassé le délai d'attente du client. Vérifiez le champ upstream_response_time dans le journal d'accès, qui indique le temps de traitement backend. Si cette valeur est constamment élevée, examinez le service backend pour identifier les goulets d'étranglement de performance.
Le délai d'attente de la requête client est trop court : Le client a fermé la connexion en raison d'un délai d'attente avant d'avoir fini d'envoyer la requête. Vérifiez le champ request_time dans le journal d'accès, qui indique le temps total de la requête. Utilisez cette valeur comme référence pour définir un délai d'attente de requête côté client plus approprié.
Le client a rencontré un problème inconnu : Le client a fermé la connexion avant que la requête ne soit terminée. Examinez le client pour identifier tout comportement susceptible de provoquer une fermeture prématurée de la connexion.

500 Internal Server Error

Le serveur backend a rencontré une erreur interne et n'a pas pu traiter la requête.

Le backend renvoie directement 500 : Consultez le journal d'accès. Si upstream_status est 500, ALB a probablement transmis le code d'état du backend. Examinez le service backend.
Le serveur backend a fermé la connexion de manière inattendue : Le serveur backend a fermé la connexion avant d'envoyer une réponse complète. Capturez les paquets sur le serveur backend pour identifier la cause de la fermeture inattendue de la connexion.

503 Service Temporarily Unavailable

Le serveur est temporairement indisponible, généralement parce que le trafic dépasse les limites ou que le service backend est indisponible.

Le backend renvoie directement 503 : Consultez le journal d'accès. Si upstream_status est 503, ALB a probablement transmis le code d'état du backend. Examinez le service backend.
La requête client déclenche la limitation de débit d'ALB :
- Dans Cloud Monitor, vérifiez la métrique Requests per second.
- Cloud Monitor affiche des données au niveau de la minute et peut ne pas refléter les pics au niveau de la seconde. Consultez le journal d'accès. Si le champ upstream_status est -, la requête n'a pas atteint le serveur backend.
- Vérifiez l'en-tête du paquet de réponse. S'il contient le champ ALB-QPS-Limited:Limited, la requête a déclenché la limitation de débit d'ALB.
Accès direct par IP ou résolution DNS anormale : Cela peut concentrer le trafic sur seulement quelques adresses IP et déclencher une limitation de débit. Accédez à ALB via son nom de domaine (voir Configuration d'un CNAME pour une instance ALB) et vérifiez que la résolution DNS fonctionne comme prévu.
L'écouteur ne possède aucun serveur backend configuré, ou les serveurs backend configurés ont un poids de 0.

La règle de transfert par défaut d'ALB Ingress provoque une erreur 503

Après avoir installé le composant ALB Ingress dans un cluster ACK, le composant crée automatiquement une règle de transfert par défaut et un groupe de serveurs correspondant sous l'instance ALB. Le groupe de serveurs est initialement vide.

Lorsqu'une requête atteint ALB mais ne correspond à aucune des règles de transfert Ingress basées sur le domaine configurées, la requête est routée vers cette règle de transfert par défaut. Étant donné que le groupe de serveurs par défaut est vide, ALB n'a aucun backend vers lequel transférer la requête et renvoie une erreur 503 Service Temporarily Unavailable.

Il s'agit d'un comportement attendu et vous n'avez pas besoin de supprimer manuellement la règle de transfert par défaut. Pour résoudre le problème, configurez les règles de transfert Ingress basées sur le domaine correctes dans le cluster ACK afin de router le trafic métier vers les groupes de serveurs backend correspondants.

Une configuration incorrecte du chemin générique provoque une erreur 503

Lorsque le type de correspondance de chemin d'une règle de transfert ALB est Exact match and wildcard, le caractère générique * correspond à une chaîne de n'importe quelle longueur. Le chemin /zhpt/* correspond aux chemins commençant par /zhpt/ (tels que /zhpt/test), mais n'inclut pas le chemin de base /zhpt lui-même. Par conséquent, lorsqu'une règle est configurée uniquement avec /zhpt/*, une requête vers /zhpt ne correspond pas à la règle et retombe sur l'action de transfert par défaut. Si le groupe de serveurs par défaut est vide, ALB renvoie une erreur 503 Service Temporarily Unavailable. Pour plus d'informations sur les règles de correspondance de chemin, consultez Exemples de configuration de règles de transfert et règles de correspondance de nom de domaine et de chemin.

Solutions : Choisissez l'une des options suivantes en fonction de la plage de chemins que vous devez faire correspondre :

Si vous devez uniquement faire correspondre le chemin de base /zhpt, modifiez le chemin de la règle de /zhpt/* à /zhpt.
Si vous devez faire correspondre à la fois le chemin de base /zhpt et ses sous-chemins /zhpt/*, configurez deux règles de transfert distinctes (/zhpt et /zhpt/*) et faites attention à l'ordre des règles.
Si vous avez besoin d'une correspondance de chemin plus flexible, modifiez le type de correspondance en Regular expression match et écrivez le chemin sous forme d'expression régulière (par exemple, utilisez ^/zhpt(/.*)?$ pour faire correspondre à la fois /zhpt et ses sous-chemins). Ancrez l'expression régulière avec ^ et $ pour éviter les correspondances involontaires telles que /zhptxxx.

504 Gateway Timeout

ALB a expiré en attendant une réponse du serveur backend.

Le backend renvoie directement 504 : Consultez le journal d'accès. Si upstream_status est 504, ALB a probablement transmis le code d'état du backend. Examinez le service backend.
La tentative de connexion d'ALB au serveur backend expire : Ce délai d'attente est de 5 secondes par défaut et ne peut pas être modifié. Capturez les paquets pour identifier pourquoi le serveur backend ne répond pas à temps.
Délai d'attente de la réponse backend : Le délai d'attente de la demande de connexion est de 60 secondes par défaut. Vous pouvez vérifier la métrique UpstreamResponseTime dans Cloud Monitor et le champ upstream_response_time dans le journal d'accès pour déterminer si la réponse du serveur backend a expiré.