Résolution des problèmes de vos Application Load Balancers - Elastic Load Balancing
Une cible enregistrée n'est pas en serviceLes clients ne peuvent pas se connecter à un équilibreur de charge accessible sur InternetLes requêtes envoyées à un domaine personnalisé ne sont pas reçues par l'équilibreur de chargeHTTPSles demandes envoyées à l'équilibreur de charge renvoient « NET : : ERR _ CERT _ _ COMMON NAME _ INVALID »L'équilibreur de charge affiche des temps de traitement élevésL'équilibreur de charge envoie un code de réponse de 000L'équilibreur de charge génère une erreur HTTPUne cible génère une HTTP erreurAucun AWS Certificate Manager certificat n'est disponible pour utilisationLes en-têtes multilignes ne sont pas pris en chargeRésoudre les problèmes liés aux cibles défectueuses à l'aide de la carte des ressources

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Résolution des problèmes de vos Application Load Balancers

Les informations suivantes peuvent vous aider à résoudre les problèmes liés à votre Application Load Balancer.

Une cible enregistrée n'est pas en service

Si le passage à l'état InService d'une cible est plus long que prévu, les vérifications de l'état risquent d'échouer. Votre cible ne sera pas en service tant que la vérification de l'état correspondante ne sera pas concluante. Pour de plus amples informations, veuillez consulter Contrôles de santé pour les groupes cibles d'Application Load Balancer.

Vérifiez que votre instance échoue aux surveillances de l'état, puis vérifiez les problèmes suivants :

Un groupe de configuration n'autorise pas le trafic

Le groupe de sécurité associé à une instance doit autoriser le trafic à partir de l'équilibreur de charge à l'aide du port et du protocole de vérification de l'état. Vous devez ajouter une règle au groupe de sécurité des instances pour autoriser le trafic à partir du groupe de sécurité de l'équilibreur de charge. De même, le groupe de sécurité de votre équilibreur de charge doit autoriser le trafic vers les instances.

Une liste de contrôle d'accès réseau (ACL) n'autorise pas le trafic

Le réseau ACL associé aux sous-réseaux de vos instances doit autoriser le trafic entrant sur le port de contrôle de santé et le trafic sortant sur les ports éphémères (1024-65535). Le réseau ACL associé aux sous-réseaux de vos nœuds d'équilibreur de charge doit autoriser le trafic entrant sur les ports éphémères et le trafic sortant sur le bilan de santé et les ports éphémères.

Le chemin de ping n'existe pas

Créez une page cible pour la vérification de l'état et spécifiez son chemin comme chemin de ping.

Expiration de la connexion

Vérifiez tout d'abord que vous pouvez vous connecter à la cible directement à partir du réseau en utilisant l'adresse IP privée de la cible et le protocole de vérification de l'état. Si vous ne pouvez pas vous connecter, vérifiez si l'instance n'est pas sur-utilisée, et ajoutez d'autres cibles à votre groupe cible s'il est trop occupé pour répondre. Si vous pouvez vous connecter, il est possible que la page cible ne réponde pas avant l'expiration du délai de la vérification de l'état. Choisissez une page cible plus simple pour la vérification de l'état ou ajustez les paramètres de vérification de l'état.

La cible n'a pas renvoyé de code de réponse réussie

Par défaut, le code de réussite est 200, mais vous pouvez également spécifier des codes de réussite supplémentaires lorsque vous configurez des vérifications de l'état. Confirmez les codes de réussite attendus par l'équilibreur de charge et si votre application est configurée pour renvoyer ces codes lorsque la vérification de l'état est concluante.

Le code de réponse cible était mal formé ou une erreur s'est produite lors de la connexion à la cible

Vérifiez que votre application répond aux demandes de surveillance de l'état de l'équilibreur de charge. Certaines applications nécessitent une configuration supplémentaire pour répondre aux contrôles de santé, par exemple une configuration d'hôte virtuel pour répondre à l'en-tête HTTP d'hôte envoyé par l'équilibreur de charge. La valeur de l'en-tête de l'hôte contient l'adresse IP privée de la cible, suivie du port de contrôle de santé lorsque le port par défaut n'est pas utilisé. Si la cible utilise un port de contrôle de santé par défaut, la valeur de l'en-tête de l'hôte contient uniquement l'adresse IP privée de la cible. Par exemple, si l'adresse IP privée de votre cible est 10.0.0.10 et que son port de contrôle de santé est le cas8080, l'en-tête HTTP Host envoyé par l'équilibreur de charge lors des contrôles de santé l'estHost: 10.0.0.10:8080. Si l'adresse IP privée de votre cible est 10.0.0.10 et que son port de vérification de l'état est80, l'en-tête HTTP Host envoyé par l'équilibreur de charge lors des contrôles de santé estHost: 10.0.0.10. Une configuration d'hôte virtuel pour répondre à cet hôte, ou une configuration par défaut, peut être nécessaire pour vérifier correctement l'état de votre application. Les demandes de contrôle de santé ont les attributs suivants : la User-Agent valeur est définie surELB-HealthChecker/2.0, la terminaison de ligne pour les champs d'en-tête de message est la séquenceCRLF, et l'en-tête se termine à la première ligne vide suivie d'un. CRLF

Les clients ne peuvent pas se connecter à un équilibreur de charge accessible sur Internet

Si l'équilibreur de charge ne répond pas aux requêtes, vérifiez les points suivants :

Votre équilibreur de charge accessible sur Internet est attaché à un sous-réseau privé

Vous devez spécifier des sous-réseaux publics pour votre équilibreur de charge. Un sous-réseau public dispose d'une route vers l'Internet Gateway pour votre cloud privé virtuel (VPC).

Un groupe de sécurité ou un réseau ACL n'autorise pas le trafic

Le groupe de sécurité pour l'équilibreur de charge et tout réseau ACLs pour les sous-réseaux de l'équilibreur de charge doivent autoriser le trafic entrant en provenance des clients et le trafic sortant vers les clients sur les ports d'écoute.

Les requêtes envoyées à un domaine personnalisé ne sont pas reçues par l'équilibreur de charge

Si l'équilibreur de charge ne reçoit pas les requêtes envoyées à un domaine personnalisé, vérifiez les points suivants :

Le nom de domaine personnalisé ne correspond pas à l'adresse IP de l'équilibreur de charge

  • Confirmez l'adresse IP à laquelle le nom de domaine personnalisé correspond à l'aide d'une interface de ligne de commande.

    • Linux, macOS ou Unix : vous pouvez utiliser la commande dig dans Terminal. Par exemple, dig example.com

    • Windows : vous pouvez utiliser la commande nslookup dans Command Prompt. Par exemple, nslookup example.com

  • Vérifiez l'adresse IP associée au DNS nom de l'équilibreur de charge à l'aide d'une interface de ligne de commande.

  • Comparez les résultats des deux sorties. Les adresses IP doivent correspondre.

Si vous utilisez Route 53 pour héberger votre domaine personnalisé, consultez Mon domaine n'est pas disponible sur Internet dans le Guide du développeur Amazon Route 53.

HTTPSles demandes envoyées à l'équilibreur de charge renvoient « NET : : ERR _ CERT _ _ COMMON NAME _ INVALID »

Si HTTPS des demandes NET::ERR_CERT_COMMON_NAME_INVALID proviennent de l'équilibreur de charge, vérifiez les causes possibles suivantes :

  • Le nom de domaine utilisé dans la HTTPS demande ne correspond pas au nom alternatif spécifié dans le ACM certificat associé aux auditeurs.

  • Le DNS nom par défaut de l'équilibreur de charge est utilisé. Le DNS nom par défaut ne peut pas être utilisé pour effectuer des HTTPS demandes car aucun certificat public ne peut être demandé pour le *.amazonaws.com domaine.

L'équilibreur de charge affiche des temps de traitement élevés

L'équilibreur de charge compte les temps de traitement différemment en fonction de la configuration.

  • S'il AWS WAF est associé à votre Application Load Balancer et qu'un client envoie une HTTP POST demande, le délai d'envoi des données pour les POST demandes est indiqué dans le request_processing_time champ des journaux d'accès à l'équilibreur de charge. Ce comportement est normal pour les HTTP POST demandes.

  • S'il n' AWS WAF est pas associé à votre Application Load Balancer et qu'un client envoie une HTTP POST demande, le délai d'envoi des données pour les POST demandes est indiqué dans le target_processing_time champ des journaux d'accès à l'équilibreur de charge. Ce comportement est normal pour les HTTP POST demandes.

L'équilibreur de charge envoie un code de réponse de 000

Avec HTTP /2 connexions, si la longueur compressée de l'un des en-têtes dépasse 8 000 octets ou si le nombre de demandes traitées via une connexion dépasse 10 000, l'équilibreur de charge envoie une GOAWAY trame et ferme la connexion avec un. TCP FIN

L'équilibreur de charge génère une erreur HTTP

Les HTTP erreurs suivantes sont générées par l'équilibreur de charge. L'équilibreur de charge envoie le HTTP code au client, enregistre la demande dans le journal d'accès et incrémente la métrique HTTPCode_ELB_4XX_Count orHTTPCode_ELB_5XX_Count.

HTTP400 : Mauvaise demande

Causes possibles :

  • Le client a envoyé une demande mal formée qui ne répond pas aux HTTP spécifications.

  • L'en-tête de la demande a dépassé 16 K par ligne de demande, 16 K par en-tête unique ou 64 K pour l'ensemble de l'en-tête de la demande.

  • Le client a fermé la connexion avant d'envoyer le corps complet de la demande.

HTTP401 : Non autorisé

Vous avez configuré une règle d'écouteur pour authentifier des utilisateurs, mais l'une des conditions suivantes est vraie :

  • Vous avez configuré OnUnauthenticatedRequest pour refuser les utilisateurs non authentifiés ou l'IdP a refusé l'accès.

  • La taille des demandes renvoyées par l'IdP dépassait la taille maximale prise en charge par l'équilibreur de charge.

  • Un client a soumis une demande HTTP /1.0 sans en-tête d'hôte et l'équilibreur de charge n'a pas pu générer de redirection. URL

  • La portée demandée ne renvoie pas un jeton d'identification.

  • Vous ne terminez pas le processus de connexion avant l'expiration du délai de connexion du client. Pour plus d'informations, consultez Expiration de connexion du client.

HTTP403 : Interdit

Vous avez configuré une liste de contrôle d'accès AWS WAF Web (WebACL) pour surveiller les demandes adressées à votre Application Load Balancer et celle-ci a bloqué une demande.

HTTP405 : Méthode non autorisée

Le client a utilisé TRACE cette méthode, qui n'est pas prise en charge par les équilibreurs de charge d'application.

HTTP408 : Délai d'expiration de la demande

Le client n'a pas envoyé les données avant l'expiration du délai d'inactivité. L'envoi d'un TCP keep-alive n'empêche pas ce délai d'expiration. Envoyez au moins 1 octet de données avant la fin de chaque délai d'inactivité. Augmentez la durée du délai d'inactivité si nécessaire.

HTTP413 : Charge utile trop importante

Causes possibles :

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

  • L'en-tête de la demande a dépassé 16 K par ligne de demande, 16 K par en-tête unique ou 64 K pour l'ensemble de l'en-tête de la demande.

HTTP414 : URI trop long

Les paramètres de la requête URL ou de la chaîne de requête sont trop grands.

HTTP460

L'équilibreur de charge a reçu une demande d'un client, mais le client a mis fin à la connexion avec l'équilibreur de charge avant la fin du délai d'inactivité.

Vérifiez si le délai d'expiration du client est supérieur au délai d'inactivité de l'équilibreur de charge. Assurez-vous que votre cible fournit une réponse au client avant la fin du délai d'expiration du client, ou augmentez ce délai d'expiration pour qu'il soit en adéquation avec celui de l'équilibreur de charge, si le client le permet.

HTTP463

L'équilibreur de charge a reçu un en-tête de demande X-Forwarded-For avec trop d'adresses IP. La limite supérieure pour les adresses IP est de 30.

HTTP464

L'équilibreur de charge a reçu un protocole de demande entrante incompatible avec la configuration de version du protocole du groupe cible.

Causes possibles :

  • Le protocole de requête est HTTP /1.1, tandis que la version du protocole du groupe cible est g RPC ou HTTP /2.

  • Le protocole de requête est un gRPC, tandis que la version du protocole du groupe cible est un HTTP /1.1.

  • Le protocole de demande est un HTTP /2, mais pas la demandePOST, tandis que la version du protocole du groupe cible est un RPC g.

HTTP500 : Erreur interne du serveur

Causes possibles :

  • Vous avez configuré une liste de contrôle d'accès AWS WAF Web (WebACL) et une erreur s'est produite lors de l'exécution des ACL règles Web.

  • L'équilibreur de charge ne peut pas communiquer avec le point de terminaison de jeton de l'IdP ou le point de terminaison d'infos utilisateur de l'IdP.

    • Vérifiez que les IdP peuvent être DNS résolus publiquement.

    • Vérifiez que les groupes de sécurité de votre équilibreur de charge et de votre réseau ACLs VPC autorisent l'accès sortant à ces points de terminaison.

    • Vérifiez que vous VPC avez accès à Internet. Si vous disposez d'un équilibreur de charge interne, utilisez une NAT passerelle pour permettre l'accès à Internet.

  • La réclamation utilisateur reçue de l'IdP a une taille supérieure à 11 Ko.

  • Le point de terminaison du jeton IdP ou le point de terminaison d'informations utilisateur de l'IdP met plus de 5 secondes à répondre.

HTTP501 : Non implémenté

L'équilibreur de charge reçu un en-tête Transfer-Encoding (Encodage de transfert) avec une valeur non prise en charge. Les valeurs prises en charge pour Transfer-Encoding (Encodage de transfert) sont chunked et identity. Sinon, vous pouvez utiliser l'en-tête Content-Encoding (Encodage de contenu).

HTTP502 : Passerelle défectueuse

Causes possibles :

  • L'équilibreur de charge a reçu un TCP RST message de la cible lorsqu'il a tenté d'établir une connexion.

  • L'équilibreur de charge a reçu une réponse inattendue de la cible, telle que « ICMP Destination inaccessible (hôte inaccessible) », lors de la tentative d'établissement d'une connexion. 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 pendant un TCP RST ou un TCP FIN certain temps pendant que l'équilibreur de charge avait reçu une demande en suspens. Vérifiez si la durée d'activité (keep-alive) de la cible est inférieure à la valeur du délai d'inactivité de l'équilibreur de charge.

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

  • L'en-tête de réponse cible dépassait 32 K pour l'ensemble de l'en-tête de réponse.

  • Le retard d'annulation d'enregistrement écoulé pour une demande est géré par une cible dont l'enregistrement a été annulé. Augmentez le délai afin que les longues opérations aient le temps d'être effectuées.

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

  • La cible est une fonction Lambda qui n'a pas répondu avant la fin de son délai d'expiration configuré.

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

  • L'équilibreur de charge a rencontré une erreur SSL de connexion lors de la connexion à une cible.

Pour plus d'informations, consultez la section Comment résoudre les erreurs d'Application Load HTTP Balancer 502 dans le AWS Support Knowledge Center.

HTTP503 : Service non disponible

Les groupes cibles de l'équilibreur de charge n'ont aucune cible enregistrée, ou toutes les cibles enregistrées sont dans un unused état.

HTTP504 : expiration du délai d'expiration de la passerelle

Causes possibles :

  • L'équilibreur de charge n'a pas réussi à établir une connexion vers la cible avant l'expiration du délai de connexion (10 secondes).

  • L'équilibreur de charge à établi une connexion vers la cible mais la cible n'a pas répondu avant la fin du délai d'inactivité.

  • Les réseaux ACL ou les SecurityGroup politiques n'autorisaient pas le trafic entre les cibles et les nœuds d'équilibrage de charge sur les ports éphémères (1024-65535).

  • La cible a renvoyé un en-tête Content-length plus grand que le corps de l'entité. L'équilibreur de charge a expiré en attendant les octets manquants.

  • La cible est une fonction Lambda et le service Lambda n'a pas répondu avant l'expiration du délai de connexion.

  • L'équilibreur de charge a rencontré un SSL délai d'attente (10 secondes) lors de la connexion à une cible.

HTTP505 : Version non prise en charge

L'équilibreur de charge a reçu une demande de HTTP version inattendue. Par exemple, l'équilibreur de charge a établi une connexion HTTP /1 mais a reçu une demande HTTP /2.

HTTP507 : Stockage insuffisant

La redirection URL est trop longue.

HTTP561 : Non autorisé

Vous avez configuré une règle d'écouteur pour authentifier les utilisateurs, mais l'IdP a renvoyé un code d'erreur lors de l'authentification de l'utilisateur. Vérifiez dans vos journaux d'accès le code de motif de l'erreur correspondant.

Une cible génère une HTTP erreur

L'équilibreur de charge transmet HTTP les réponses valides des cibles au client, y compris HTTP les erreurs. Les HTTP erreurs générées par une cible sont enregistrées dans les HTTPCode_Target_5XX_Count métriques HTTPCode_Target_4XX_Count et.

Aucun AWS Certificate Manager certificat n'est disponible pour utilisation

Lorsque vous décidez d'utiliser un HTTPS écouteur avec votre Application Load Balancer AWS Certificate Manager , vous devez valider la propriété du domaine avant de délivrer un certificat. Si cette étape est manquée lors de la configuration, le certificat reste dans son état Pending Validation et ne peut pas être utilisé tant qu'il n'est pas validé.

  • Si vous utilisez la validation par e-mail, consultez Validation par e-mail dans le guide de l'utilisateur AWS Certificate Manager .

  • Si vous utilisez DNS la validation, reportez-vous à la section DNSValidation dans le guide de AWS Certificate Manager l'utilisateur.

Les en-têtes multilignes ne sont pas pris en charge

Application Load Balancers ne prennent pas en charge les en-têtes multilignes, y compris l'en-tête de type de média message/http. Lorsqu'un en-tête multiligne est fourni, Application Load Balancer ajoute un caractère deux-points, « : », avant de le transmettre à la cible.

Résoudre les problèmes liés aux cibles défectueuses à l'aide de la carte des ressources

Si les tests de santé de vos cibles Application Load Balancer échouent, vous pouvez utiliser la carte des ressources pour détecter les cibles défectueuses et prendre des mesures en fonction du code de cause de l'échec. Pour de plus amples informations, veuillez consulter Afficher la carte des ressources de l'Application Load Balancer.

La carte des ressources fournit deux vues : Vue d'ensemble et Carte cible malsaine. L'option Vue d'ensemble est sélectionnée par défaut et affiche toutes les ressources de votre équilibreur de charge. La sélection de la vue Malhealthy Target Map affichera uniquement les cibles malsaines de chaque groupe cible associé à l'Application Load Balancer.

Note

Vous devez activer Afficher les détails des ressources pour afficher le résumé du bilan de santé et les messages d'erreur pour toutes les ressources applicables dans la carte des ressources. Lorsque cette option n'est pas activée, vous devez sélectionner chaque ressource pour en afficher les détails.

La colonne Groupes cibles affiche un résumé des cibles saines et malsaines pour chaque groupe cible. Cela peut aider à déterminer si toutes les cibles échouent aux tests de santé ou si seules des cibles spécifiques échouent. Si toutes les cibles d'un groupe cible échouent aux tests de santé, vérifiez la configuration du groupe cible. Sélectionnez le nom d'un groupe cible pour ouvrir sa page détaillée dans un nouvel onglet.

La colonne Targets affiche le TargetID et l'état actuel du bilan de santé pour chaque cible. Lorsqu'une cible n'est pas saine, le code de la raison de l'échec du contrôle de santé s'affiche. Lorsqu'une cible échoue à un contrôle de santé, vérifiez que la cible dispose de ressources suffisantes et que les applications exécutées sur la cible sont disponibles. Sélectionnez l'ID d'une cible pour ouvrir sa page détaillée dans un nouvel onglet.

La sélection d'Exporter vous donne la possibilité d'exporter la vue actuelle de la carte des ressources de votre équilibreur de charge d'PDFapplication sous forme de fichier.

Vérifiez que les tests de santé de votre instance échouent, puis, en fonction du code de cause de l'échec, vérifiez les problèmes suivants :

  • Malsain : incompatibilité des HTTP réponses

    • Vérifiez que l'application exécutée sur la cible envoie la bonne HTTP réponse aux demandes de vérification de l'état de l'application Load Balancer.

    • Vous pouvez également mettre à jour la demande de vérification de l'état de l'application Load Balancer pour qu'elle corresponde à la réponse de l'application exécutée sur la cible.

  • Malsain : le délai imparti pour la demande a expiré

    • Vérifiez que les groupes de sécurité et les listes de contrôle d'accès réseau (ACL) associés à vos cibles et à Application Load Balancer ne bloquent pas la connectivité.

    • Vérifiez que la cible dispose de suffisamment de ressources pour accepter les connexions depuis l'Application Load Balancer.

    • Vérifiez l'état de toutes les applications exécutées sur la cible.

    • Les réponses au bilan de santé de l'équilibreur de charge d'application peuvent être consultées dans les journaux des applications de chaque cible. Pour plus d'informations, consultez la section Codes de raison du contrôle de santé.

  • Malsain : FailedHealthChecks

    • Vérifiez l'état de toutes les applications exécutées sur la cible.

    • Vérifiez que la cible écoute le trafic sur le port de contrôle de santé.

      Lorsque vous utilisez un HTTPS écouteur

      Vous choisissez la politique de sécurité à utiliser pour les connexions frontales. La politique de sécurité utilisée pour les connexions dorsales est automatiquement sélectionnée en fonction de la stratégie de sécurité frontale utilisée.

      • Si votre HTTPS écouteur utilise une politique de sécurité TLS 1.3 pour les connexions frontales, la politique de ELBSecurityPolicy-TLS13-1-0-2021-06 sécurité est utilisée pour les connexions dorsales.

      • Si votre HTTPS écouteur n'utilise pas de politique de sécurité TLS 1.3 pour les connexions frontales, la politique de ELBSecurityPolicy-2016-08 sécurité est utilisée pour les connexions dorsales.

      Pour plus d'informations, consultez la section Politiques de sécurité.

    • Vérifiez que la cible fournit un certificat de serveur et une clé au format correct spécifié par la politique de sécurité.

    • Vérifiez que la cible prend en charge un ou plusieurs chiffrements correspondants, ainsi qu'un protocole fourni par l'Application Load Balancer pour établir des handshakes. TLS