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ésoudre les problèmes liés à votre Classic Load Balancer
Les tableaux suivants répertorient les ressources de résolution des problèmes qui pourront vous être utiles lors de l'utilisation d'un Classic Load Balancer.
**erreurs d’API**
| Erreur |
| --- |
| [CertificateNotFound: Non défini](ts-elb-error-api-response.md#ts-elb-error-message-certificate) |
| [OutofService: une erreur passagère s'est produite](ts-elb-error-api-response.md#ts-elb-error-message-service) |
**Erreurs HTTP**
| Erreur |
| --- |
| [HTTP 400 : BAD\$1REQUEST](ts-elb-error-message.md#ts-elb-errorcodes-http400) |
| [HTTP 405 : METHOD\$1NOT\$1ALLOWED](ts-elb-error-message.md#ts-elb-errorcodes-http405) |
| [HTTP 408 : Délai d'attente des demandes](ts-elb-error-message.md#ts-elb-errorcodes-http408) |
| [HTTP 502 : Passerelle erronée](ts-elb-error-message.md#ts-elb-errorcodes-http502) |
| [HTTP 503 : Service indisponible](ts-elb-error-message.md#ts-elb-errorcodes-http503) |
| [HTTP 504 : Délai de passerelle expiré](ts-elb-error-message.md#ts-elb-errorcodes-http504) |
**Métriques de code de réponse**
| Métrique de code de réponse |
| --- |
| [HTTPCode\$1ELB\$14XX](ts-elb-http-errors.md#ts-elb-error-metrics-ELB_4XX) |
| [HTTPCode\$1ELB\$15XX](ts-elb-http-errors.md#ts-elb-error-metrics-ELB_5XX) |
| [HTTPCode\$1Backend\$12xx](ts-elb-http-errors.md#ts-elb-error-metrics-Backend_2XX) |
| [HTTPCode\$1Backend\$13xx](ts-elb-http-errors.md#ts-elb-error-metrics-Backend_3XX) |
| [HTTPCode\$1Backend\$14xx](ts-elb-http-errors.md#ts-elb-error-metrics-Backend_4XX) |
| [HTTPCode\$1Backend\$15xx](ts-elb-http-errors.md#ts-elb-error-metrics-Backend_5XX) |
**Problèmes de surveillance de l'état**
| Problème |
| --- |
| [Erreur de page cible de vérification de l'état](ts-elb-healthcheck.md#ts-elb-healthcheck-targetpage) |
| [La connexion aux instances a expiré](ts-elb-healthcheck.md#ts-elb-healthcheck-failed) |
| [L'authentification par clé publique échoue](ts-elb-healthcheck.md#ts-elb-healthcheck-publickey) |
| [L'instance ne reçoit pas le trafic provenant de l'équilibreur de charge](ts-elb-healthcheck.md#ts-elb-healthcheck-securitygroup) |
| [Des ports sur l'instance ne sont pas ouverts](ts-elb-healthcheck.md#ts-elb-healthcheck-ports) |
| [Les instances d'un groupe Auto Scaling ne réussissent pas la surveillance de l'état ELB](ts-elb-healthcheck.md#ts-elb-healthcheck-autoscaling) |
**Problèmes de connectivité**
| Problème |
| --- |
| [Les clients ne peuvent pas se connecter à un équilibreur de charge accessible sur Internet](ts-elb-connection-failed.md#client-cannot-connect) |
| [Les requêtes envoyées à un domaine personnalisé ne sont pas reçues par l'équilibreur de charge](ts-elb-connection-failed.md#custom-domain-request) |
| [Les requêtes HTTPS envoyées à l'équilibreur de charge renvoient « NET::ERR\$1CERT\$1COMMON\$1NAME\$1INVALID »](ts-elb-connection-failed.md#https-cert-invalid) |
**Problèmes d'enregistrement d'instance**
| Problème |
| --- |
| [L'enregistrement d'une instance EC2 prend trop de temps](ts-elb-register-instance.md#ts-elb-register-too-long) |
| [Impossible d'enregistrer une instance lancée à partir d'une AMI payante](ts-elb-register-instance.md#ts-elb-paid-ami-instance) |
# Résoudre les problèmes liés à un Classic Load Balancer : erreurs d'API
Voici des messages d'erreur renvoyés par l'API Elastic Load Balancing, les causes potentielles et les étapes que vous pouvez suivre pour résoudre les problèmes.
**Topics**
+ [
## CertificateNotFound: Non défini
](#ts-elb-error-message-certificate)
+ [
## OutofService: une erreur passagère s'est produite
](#ts-elb-error-message-service)
## CertificateNotFound: Non défini
**Cause 1** : la propagation du certificat vers toutes les Régions est retardée lorsque ce certificat est créé à l'aide de la AWS Management Console. Lorsque ce retard a lieu, le message d'erreur apparaît lors de la dernière étape du processus de création de l'équilibreur de charge.
**Solution 1** : attendez environ 15 minutes, puis réessayez. Si le problème persiste, accédez au [Centre AWS Support](https://console.aws.amazon.com/support/home#/) pour obtenir de l'aide.
**Cause 2** : Si vous utilisez directement l'API AWS CLI or, vous pouvez recevoir cette erreur si vous fournissez un Amazon Resource Name (ARN) pour un certificat qui n'existe pas.
**Solution 2** : utilisez l'action Gestion des identités et des accès AWS (IAM) [GetServerCertificate](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetServerCertificate.html)pour obtenir l'ARN du certificat et vérifier que vous avez fourni la bonne valeur pour l'ARN.
## OutofService: une erreur passagère s'est produite
**Cause** : un problème interne temporaire s'est produit au sein du service Elastic Load Balancing ou du réseau sous-jacent. Ce problème temporaire peut également se produire lorsqu'Elastic Load Balancing interroge l'état de santé de l'équilibreur de charge et des instances enregistrées de ce dernier.
**Solution** : relancez l'appel d'API. Si le problème persiste, accédez au [Centre AWS Support](https://console.aws.amazon.com/support/home#/) pour obtenir de l'aide.
# Résoudre les problèmes liés à un Classic Load Balancer : erreurs HTTP
La méthode HTTP (également appelée *verbe*) spécifie l'action à exécuter sur la ressource qui reçoit une demande HTTP. Les méthodes standard pour les demandes HTTP sont définies dans la section du RFC 2616 concernant les [définitions de méthode](http://tools.ietf.org/html/rfc2616#section-9). Les méthodes standard incluent GET, POST, PUT, HEAD et OPTIONS. Certaines applications web ont besoin (et parfois introduisent) de méthodes qui sont des extensions de méthodes HTTP/1.1. Les exemples courants de méthodes étendues HTTP incluent PATCH, REPORT, MKCOL, PROPFIND, MOVE et LOCK. Elastic Load Balancing accepte toutes les méthodes HTTP standard et non standard.
Les demandes et les réponses HTTP utilisent des champs d'en-tête pour envoyer des informations concernant les messages HTTP. Les champs d'en-tête sont des paires nom-valeur dont les noms et les valeurs sont séparés par un signe deux points, et qui sont séparées entre elles par un retour chariot (CR) et un saut de ligne (LF). Un ensemble standard de champs d'en-tête HTTP est défini dans la section du RFC 2616 concernant les [en-têtes de message](http://tools.ietf.org/html/rfc2616#section-4.2). Pour de plus amples informations, veuillez consulter [En-têtes HTTP et Classic Load Balancers](x-forwarded-headers.md).
Lorsqu'un équilibreur de charge reçoit une demande HTTP, il vérifie que cette dernière est correcte et contrôle la longueur de la méthode. La longueur totale de la méthode dans une demande HTTP vers un équilibreur de charge ne doit pas dépasser 127 caractères. Si la demande HTTP réussit les deux contrôles, l'équilibreur de charge l'envoie à l'instance EC2. Si le champ de méthode de la demande est incorrect, l'équilibreur de charge répond par une erreur [HTTP 400 : BAD\$1REQUEST](#ts-elb-errorcodes-http400). Si la longueur de la méthode dans la demande dépasse 127 caractères, l'équilibreur de charge répond par une erreur [HTTP 405 : METHOD\$1NOT\$1ALLOWED](#ts-elb-errorcodes-http405).
L'instance EC2 traite une demande valide en implémentant la méthode dans la demande et en envoyant une réponse au client. Vos instances doivent être configurées pour traiter les méthodes prises en charge et non prises en charge.
Voici des messages d'erreur renvoyés par votre équilibreur de charge, les causes potentielles et les étapes que vous pouvez suivre pour résoudre les problèmes.
**Topics**
+ [
## HTTP 400 : BAD\$1REQUEST
](#ts-elb-errorcodes-http400)
+ [
## HTTP 405 : METHOD\$1NOT\$1ALLOWED
](#ts-elb-errorcodes-http405)
+ [
## HTTP 408 : Délai d'attente des demandes
](#ts-elb-errorcodes-http408)
+ [
## HTTP 502 : Passerelle erronée
](#ts-elb-errorcodes-http502)
+ [
## HTTP 503 : Service indisponible
](#ts-elb-errorcodes-http503)
+ [
## HTTP 504 : Délai de passerelle expiré
](#ts-elb-errorcodes-http504)
## HTTP 400 : BAD\$1REQUEST
**Description** : indique que le client a envoyé une demande incorrecte.
**Cause 1** : le client a envoyé une demande incorrecte qui ne respecte pas les spécifications HTTP. Par exemple, une demande ne peut pas comporter d'espace dans l'URL.
**Cause 2** : le client utilise la méthode HTTP CONNECT, qui n'est pas prise en charge par Elastic Load Balancing.
**Solution** : connectez-vous directement à votre instance et saisissez les détails de la demande du client. Vérifiez que les demandes sont correctes dans les en-têtes et l'URL. Vérifiez que la demande respecte les spécifications HTTP. Vérifiez que la méthode HTTP CONNECT n'est pas utilisés.
## HTTP 405 : METHOD\$1NOT\$1ALLOWED
**Description** : indique que la longueur de la méthode n'est pas valide.
**Cause** : la longueur de la méthode dans l'en-tête de la demande dépasse 127 caractères.
**Solution** : vérifiez la longueur de la méthode.
## HTTP 408 : Délai d'attente des demandes
**Description** : indique que le client a annulé la demande ou n'a pas pu envoyer une demande complète.
**Cause 1** : une interruption du réseau ou une structure de demande incorrecte, comme des en-têtes partiellement formés, une taille de contenu spécifiée ne correspondant pas à la taille de contenu réelle transmise, etc.
**Solution 1** : inspectez le code qui constitue la demande et essayez de l'envoyer directement à vos instances enregistrées (ou à un environnement de développement/test) où vous aurez plus de contrôle pour examiner la demande réelle.
**Cause 2** : la connexion au client est fermée (l'équilibreur de charge n'a pas pu envoyer une réponse)
**Solution 2** : vérifiez que le client ne ferme pas la connexion avant l'envoi d'une réponse en utilisant un renifleur de paquets sur la machine sur laquelle vous effectuez la demande.
## HTTP 502 : Passerelle erronée
**Description** : indique que l'équilibreur de charge n'a pas pu analyser la réponse envoyée à partir d'une instance enregistrée.
**Cause** : réponse incorrecte d'une instance ou problème éventuel lié à l'équilibreur de charge.
**Solution** : vérifiez que la réponse envoyée à partir de l'instance est conforme aux spécifications HTTP. Accédez au [Centre AWS Support](https://console.aws.amazon.com/support/home#/) pour obtenir de l'aide.
## HTTP 503 : Service indisponible
**Description** : indique que l'équilibreur de charge ou les instances enregistrées sont à l'origine de l'erreur.
**Cause 1** : capacité insuffisante dans l'équilibreur de charge pour traiter la demande.
**Solution 1** : il doit s'agir d'un problème temporaire qui ne devrait pas durer plus de quelques minutes. Si le problème persiste, accédez au [Centre AWS Support](https://console.aws.amazon.com/support/home#/) pour obtenir de l'aide.
**Cause 2** : aucune instance n'est enregistrée.
**Solution 2** : enregistrez au moins une instance dans chaque zone de disponibilité dans laquelle votre équilibreur de charge est configuré pour répondre. Vérifiez cela en consultant les `HealthyHostCount` indicateurs contenus dans CloudWatch. Si vous ne pouvez pas vérifier qu'une instance est enregistrée dans chaque zone de disponibilité, nous vous recommandons d'activer l'équilibrage de charge entre zones. Pour de plus amples informations, veuillez consulter [Configurer la répartition de charge entre zones pour votre Classic Load Balancer](enable-disable-crosszone-lb.md).
**Cause 3** : il n'y a aucune instance saine.
**Solution 3** : vérifiez que vous avez des instances saines dans chaque zone de disponibilité dans laquelle votre équilibreur de charge est configuré pour répondre. Vérifiez ceci en examinant la métrique `HealthyHostCount`.
**Cause 4** : la file d'attente des hausses est saturée.
**Solution 4** : assurez-vous que vos instances ont une capacité suffisante pour gérer le taux de demandes. Vérifiez ceci en examinant la métrique `SpilloverCount`.
## HTTP 504 : Délai de passerelle expiré
**Description** : indique que l'équilibreur de charge a fermé une connexion parce qu'une demande ne s'est pas achevée avant la fin du délai d'inactivité.
**Cause 1** : le délai de réponse de l'application est supérieur au délai d'inactivité configuré.
**Solution 1** : surveillez les métriques `HTTPCode_ELB_5XX` et `Latency`. Si ces métriques augmentent, cela peut être dû au fait que l'application ne répond pas avant la fin du délai d'inactivité. Pour plus d'informations sur les demandes qui dépassent le délai imparti, activez les journaux d'accès sur l'équilibreur de charge et vérifiez les codes de réponse 504 dans les journaux générés par Elastic Load Balancing. Si nécessaire, vous pouvez augmenter votre capacité ou le délai d'inactivité configuré afin que les opérations longues (par exemple, le chargement d'un fichier volumineux) puissent se terminer. Pour plus d'informations, consultez [Configurer le délai d'inactivité des connexions de votre Classic Load Balancer](config-idle-timeout.md) et [Comment résoudre les problèmes de latence élevée liés à Elastic Load Balancing](https://repost.aws/knowledge-center/elb-latency-troubleshooting).
**Cause 2** : des instances enregistrées ferment la connexion à Elastic Load Balancing.
**Solution 2** : activez les paramètres keep-alive sur vos instances EC2 et veillez à ce que le délai d'attente keep-alive ait une valeur supérieure ou égale aux paramètres de délai d'inactivité de votre équilibreur de charge.
# Résoudre les problèmes liés à un Classic Load Balancer : métriques de code de réponse
Votre équilibreur de charge envoie des métriques à Amazon CloudWatch pour les codes de réponse HTTP envoyés aux clients, en identifiant la source des erreurs comme étant l'équilibreur de charge ou les instances enregistrées. Vous pouvez utiliser les métriques renvoyées par votre équilibreur de charge CloudWatch pour résoudre les problèmes. Pour de plus amples informations, veuillez consulter [CloudWatch statistiques pour votre Classic Load Balancer](elb-cloudwatch-metrics.md).
Vous trouverez ci-dessous les mesures du code de réponse renvoyées par CloudWatch votre équilibreur de charge, les causes potentielles et les mesures que vous pouvez prendre pour résoudre les problèmes.
**Topics**
+ [
## HTTPCode\$1ELB\$14XX
](#ts-elb-error-metrics-ELB_4XX)
+ [
## HTTPCode\$1ELB\$15XX
](#ts-elb-error-metrics-ELB_5XX)
+ [
## HTTPCode\$1Backend\$12xx
](#ts-elb-error-metrics-Backend_2XX)
+ [
## HTTPCode\$1Backend\$13xx
](#ts-elb-error-metrics-Backend_3XX)
+ [
## HTTPCode\$1Backend\$14xx
](#ts-elb-error-metrics-Backend_4XX)
+ [
## HTTPCode\$1Backend\$15xx
](#ts-elb-error-metrics-Backend_5XX)
## HTTPCode\$1ELB\$14XX
**Cause** : demande incorrecte ou annulée par le client.
**Des solutions**
+ Consultez [HTTP 400 : BAD\$1REQUEST](ts-elb-error-message.md#ts-elb-errorcodes-http400).
+ Consultez [HTTP 405 : METHOD\$1NOT\$1ALLOWED](ts-elb-error-message.md#ts-elb-errorcodes-http405).
+ Consultez [HTTP 408 : Délai d'attente des demandes](ts-elb-error-message.md#ts-elb-errorcodes-http408).
## HTTPCode\$1ELB\$15XX
**Cause** : l'équilibreur de charge ou l'instance enregistrée est à l'origine de l'erreur, ou l'équilibreur de charge ne peut pas analyser la réponse.
**Des solutions**
+ Consultez [HTTP 502 : Passerelle erronée](ts-elb-error-message.md#ts-elb-errorcodes-http502).
+ Consultez [HTTP 503 : Service indisponible](ts-elb-error-message.md#ts-elb-errorcodes-http503).
+ Consultez [HTTP 504 : Délai de passerelle expiré](ts-elb-error-message.md#ts-elb-errorcodes-http504).
## HTTPCode\$1Backend\$12xx
**Cause** : réponse de réussite normale des instances enregistrées.
**Solution** : aucune.
## HTTPCode\$1Backend\$13xx
**Cause** : réponse de redirection envoyée par les instances enregistrées.
**Solution** : affichez les journaux d'accès ou d'erreurs sur votre instance afin de déterminer la cause. Envoyez les demandes directement à l'instance (sans passer par l'équilibreur de charge) pour afficher les réponses.
## HTTPCode\$1Backend\$14xx
**Cause** : réponse d'erreur de client envoyée par les instances enregistrées.
**Solution** : affichez les journaux d'accès ou d'erreurs sur vos instances afin de déterminer la cause. Envoyez les demandes directement à l'instance (sans passer par l'équilibreur de charge) pour afficher les réponses.
**Note**
Si le client annule une demande HTTP qui a été lancée avec un en-tête `Transfer-Encoding: chunked`, un problème connu a lieu avec lequel l'équilibreur de charge transmet la demande à l'instance, même si le client a annulé à la demande. Cela peut entraîner des erreurs de serveur backend.
## HTTPCode\$1Backend\$15xx
**Cause** : réponse d'erreur de serveur envoyée par les instances enregistrées.
**Solution** : affichez les journaux d'accès ou les journaux d'erreurs sur vos instances afin de déterminer la cause. Envoyez les demandes directement à l'instance (sans passer par l'équilibreur de charge) pour afficher les réponses.
**Note**
Si le client annule une demande HTTP qui a été lancée avec un en-tête `Transfer-Encoding: chunked`, un problème connu a lieu avec lequel l'équilibreur de charge transmet la demande à l'instance, même si le client a annulé à la demande. Cela peut entraîner des erreurs de serveur backend.
# Résoudre les problèmes liés à un Classic Load Balancer : surveillance de l'état de santé
Votre équilibreur de charge vérifie l'état de santé de ses instances enregistrées à l'aide de la configuration de surveillance de l'état par défaut fournie par Elastic Load Balancing ou d'une surveillance de l'état personnalisée que vous spécifiez. La configuration de la vérification de l'état contient des informations comme le protocole, le port de ping, le chemin de ping, le délai de réponse et l'intervalle de vérification de l'état. Une instance est considérée comme saine si elle retourne un code de réponse 200 dans l'intervalle de vérification de l'état. Pour de plus amples informations, veuillez consulter [Health des instances de votre Classic Load Balancer](elb-healthchecks.md).
Si l'état actuel de tout ou partie de vos instances est `OutOfService` et que le champ de description affiche le message `Instance has failed at least the Unhealthy Threshold number of health checks consecutively`, les instances n'ont pas réussi la vérification de l'état de l'équilibreur de charge. Voici les problèmes à rechercher, les causes potentielles et les étapes que vous pouvez suivre pour résoudre les problèmes.
**Topics**
+ [
## Erreur de page cible de vérification de l'état
](#ts-elb-healthcheck-targetpage)
+ [
## La connexion aux instances a expiré
](#ts-elb-healthcheck-failed)
+ [
## L'authentification par clé publique échoue
](#ts-elb-healthcheck-publickey)
+ [
## L'instance ne reçoit pas le trafic provenant de l'équilibreur de charge
](#ts-elb-healthcheck-securitygroup)
+ [
## Des ports sur l'instance ne sont pas ouverts
](#ts-elb-healthcheck-ports)
+ [
## Les instances d'un groupe Auto Scaling ne réussissent pas la surveillance de l'état ELB
](#ts-elb-healthcheck-autoscaling)
## Erreur de page cible de vérification de l'état
**Problème** : une demande HTTP GET envoyée à l'instance sur le port de ping et le chemin de ping spécifiés (par exemple, HTTP:80/index.html) reçoit un code de réponse autre que 200.
**Cause 1** : aucune page cible n'est configurée sur l'instance.
**Solution 1** : créez une page cible (par exemple, `index.html`) sur chaque instance enregistrée et spécifiez son chemin comme chemin de ping.
**Cause 2** : la valeur de l'en-tête Content-Length dans la réponse n'est pas définie.
**Solution 2** : si la réponse inclut un corps, définissez la valeur de l'en-tête Content-Length sur une valeur supérieure ou égale à zéro, ou définissez la valeur de Transfer-Encoding sur « chunked ».
**Cause 3** : l'application n'est pas configurée pour recevoir des demandes de l'équilibreur de charge ou pour renvoyer un code de réponse 200.
**Solution 3** : vérifiez l'application sur votre instance pour enquêter sur la cause.
## La connexion aux instances a expiré
**Problème** : des demandes de vérification de l'état de votre équilibreur de charge à vos instances EC2 dépassent le délai imparti, ou échouent par intermittence.
Tout d'abord, vérifiez le problème en vous connectant directement à l'instance. Nous vous recommandons de vous connecter à votre instance à partir du réseau en utilisant l'adresse IP privée de l'instance.
Utilisez la commande suivante pour une connexion TCP :
```
telnet private-IP-address-of-the-instance port
```
Utilisez la commande suivante pour une connexion HTTP ou HTTPS :
```
curl –I private-IP-address-of-the-instance:port/health-check-target-page
```
Si vous utilisez une HTTP/HTTPS connexion et que vous obtenez une réponse autre que 200, consultez[Erreur de page cible de vérification de l'état](#ts-elb-healthcheck-targetpage). Si vous pouvez vous connecter directement à l'instance, vérifiez les points suivants :
**Cause 1** : l'instance ne peut pas répondre dans le délai de réponse configuré.
**Solution 1** : ajustez les paramètres de délai de réponse dans la configuration de vérification de l'état de votre équilibreur de charge.
**Cause 2** : l'instance est soumise à une charge importante et dépasse votre délai de réponse configuré pour répondre.
**Solution 2** :
+ Vérifiez dans le graphique de surveillance si l'UC est sur-utilisée. Pour plus d'informations, consultez [Obtenir des statistiques pour une instance EC2 spécifique](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/US_SingleMetricPerInstance.html) dans le guide de l'*utilisateur Amazon EC2.*
+ Vérifiez l'utilisation d'autres ressources d'application, comme la mémoire ou les limites en vous connectant à vos instances EC2.
+ Si nécessaire, ajoutez des instances supplémentaires ou activez Auto Scaling. Pour plus d’informations, consultez le [Guide de l’utilisateur Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/).
**Cause 3** : si vous utilisez une connexion HTTP ou HTTPS et que la vérification de l'État est effectuée sur une page cible spécifiée dans le champ de chemin de ping (par exemple, `HTTP:80/index.html`), la page cible peut prendre plus de temps pour répondre que votre délai d'attente configuré.
**Solution 3** : utilisez une page cible de vérification de l'état plus simple ou ajustez les paramètres d'intervalle de vérification de l'état.
## L'authentification par clé publique échoue
**Problème** : un équilibreur de charge configuré pour utiliser le protocole HTTPS ou SSL avec l'authentification principale activée ne réussit pas l'authentification par clé publique.
**Cause** : la clé publique sur le certificat SSL ne correspond pas à la clé publique configurée sur l'équilibreur de charge. Utilisez la commande `s_client` pour afficher la liste des certificats de serveur dans la chaîne de certificats. Pour de plus amples informations, veuillez consulter [s\$1client](https://www.openssl.org/docs/man1.1.1/man1/openssl-s_client.html) dans la documentation OpenSSL.
**Solution** : vous devez peut-être mettre à jour votre certificat SSL. Si votre certificat SSL est à jour, essayez de le réinstaller sur votre équilibreur de charge. Pour de plus amples informations, veuillez consulter [Remplacer le certificat SSL pour votre Classic Load Balancer](elb-update-ssl-cert.md).
## L'instance ne reçoit pas le trafic provenant de l'équilibreur de charge
**Problème** : le groupe de sécurité pour l'instance bloque le trafic provenant de l'équilibreur de charge.
Effectuez une capture de paquet sur l'instance pour vérifier le problème. Utilisez la commande suivante :
```
# tcpdump port health-check-port
```
**Cause 1** : le groupe de sécurité associé à l'instance n'autorise pas le trafic provenant de l'équilibreur de charge.
**Solution 1** : modifiez le groupe de sécurité de l'instance pour autoriser le trafic provenant de l'équilibreur de charge. Ajoutez une règle pour autoriser tout le trafic à partir du groupe de sécurité de l'équilibreur de charge.
**Cause 2** : le groupe de sécurité de votre équilibreur de charge n'autorise pas le trafic vers les instances EC2.
**Solution 2** : modifiez le groupe de sécurité de votre équilibreur de charge pour autoriser le trafic vers les sous-réseaux et les instances EC2.
Pour plus d'informations sur la gestion des groupes de sécurité, consultez [Configurez les groupes de sécurité pour votre Classic Load Balancer](elb-vpc-security-groups.md).
## Des ports sur l'instance ne sont pas ouverts
**Problème** : la vérification de l'état envoyée à l'instance EC2 par l'équilibreur de charge est bloquée par le port ou un pare-feu.
Vérifiez le problème en utilisant la commande suivante :
```
netstat –ant
```
**Cause** : le port de vérification de l'état ou le port d'écouteur spécifié (s'ils sont configurés différemment) n'est pas ouvert. Les ports spécifiés pour la vérification de l'état et le port d'écoute doivent être ouverts et à l'écoute.
**Solution** : ouvrez le port d'écoute et le port spécifié dans votre configuration de vérification de l'état (s'ils sont configurés différemment) sur vos instances pour recevoir le trafic de l'équilibreur de charge.
## Les instances d'un groupe Auto Scaling ne réussissent pas la surveillance de l'état ELB
**Problème** : les instances de votre groupe Auto Scaling réussissent la surveillance de l'état Auto Scaling par défaut, mais pas la surveillance de l'état ELB.
**Cause** : Auto Scaling utilise des contrôles de statut EC2 afin de détecter les problèmes matériels et logiciels liés aux instances, mais l'équilibreur de charge effectue des vérifications de l'état en envoyant une demande à l'instance et en attendant un code de réponse 200 ou en établissant une connexion TCP (pour une vérification de l'état basée sur TCP) avec l'instance.
Une instance peut ne pas réussir la vérification de l'état ELB, parce qu'une application s'exécutant sur l'instance connaît des problèmes faisant que l'équilibreur de charge considère l'instance comme étant hors service. Cette instance peut réussir la vérification de l'état Auto Scaling. Elle ne sera pas remplacée par la politique Auto Scaling car elle est considérée comme saine selon le contrôle de statut EC2.
**Solution** : utilisez la surveillance de l'état ELB pour votre groupe Auto Scaling. Lorsque vous utilisez la surveillance de l'état ELB, Auto Scaling détermine l'état de santé de vos instances en vérifiant les résultats de la surveillance de l'état de l'instance et de la surveillance de l'état ELB. Pour plus d'informations, consultez [Surveillances de l'état Elastic Load Balancing dans votre groupe Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/attach-load-balancer-asg.html) dans le manuel *Guide de l'utilisateur Amazon EC2 Auto Scaling*.
# Résolution des problèmes liés à un Classic Load Balancer : connectivité client
## 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 une passerelle Internet pour Virtual Private Cloud (VPC).
**Un groupe de sécurité ou une liste 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. Pour de plus amples informations, veuillez consulter [Configurez les groupes de sécurité pour votre Classic Load Balancer](elb-vpc-security-groups.md).
## 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 à quelle adresse IP le nom DNS de l'équilibreur de charge correspond à l'aide d'une interface de ligne de commande.
+ Comparez les résultats des deux sorties. Les adresses IP doivent correspondre.
## Les requêtes HTTPS envoyées à l'équilibreur de charge renvoient « NET::ERR\$1CERT\$1COMMON\$1NAME\$1INVALID »
Si des requêtes HTTPS reçoivent `NET::ERR_CERT_COMMON_NAME_INVALID` de l'équilibreur de charge, vérifiez les causes possibles suivantes :
+ Le nom de domaine utilisé dans la requête HTTPS ne correspond pas au nom alternatif spécifié dans le certificat ACM associé aux écouteurs.
+ Le nom DNS par défaut de l'équilibreur de charge est utilisé. Le nom DNS par défaut ne peut pas être utilisé pour effectuer des requêtes HTTPS, car aucun certificat public ne peut être demandé pour le domaine `*.amazonaws.com`.
# Résoudre les problèmes liés à un Classic Load Balancer : enregistrement d'instance
Lorsque vous enregistrez une instance auprès de votre équilibreur de charge, plusieurs étapes doivent être suivies avant que l'équilibreur de charge puisse commencer à envoyer des demandes à votre instance.
Voici les problèmes que votre équilibreur de charge peut rencontrer lors de l'enregistrement de vos instances EC2, les causes potentielles et les étapes que vous pouvez suivre pour résoudre les problèmes.
**Topics**
+ [
## L'enregistrement d'une instance EC2 prend trop de temps
](#ts-elb-register-too-long)
+ [
## Impossible d'enregistrer une instance lancée à partir d'une AMI payante
](#ts-elb-paid-ami-instance)
## L'enregistrement d'une instance EC2 prend trop de temps
**Problème** : il faut plus de temps que prévu pour que les instances EC2 enregistrées soient à l'état `InService`.
**Cause** : votre instance peut ne pas avoir réussi la vérification de l'état. Une fois les étapes initiales de l'enregistrement d'instance achevées (cela peut prendre jusqu'à environ 30 secondes), l'équilibreur de charge commence à envoyer des demandes de vérification de l'état. Votre instance n'est pas à l'état `InService` tant que qu'une vérification de l'état n'a pas réussi.
**Solution** : consultez [La connexion aux instances a expiré](ts-elb-healthcheck.md#ts-elb-healthcheck-failed).
## Impossible d'enregistrer une instance lancée à partir d'une AMI payante
**Problème** : Elastic Load Balancing n'enregistre pas une instance lancée à l'aide d'une AMI payante.
**Cause** : Vos instances ont peut-être été lancées à l'aide d'une AMI payante d'[Amazon DevPay](https://aws.amazon.com/devpay/).
**Solution** : Elastic Load Balancing ne prend pas en charge l'enregistrement des instances lancées via [Amazon Payed DevPay](https://aws.amazon.com/devpay/). AMIs Notez que vous pouvez utiliser les produits payants AMIs depuis [AWS Marketplace](https://aws.amazon.com/marketplace). Si vous utilisez déjà une AMI payante AWS Marketplace et que vous ne parvenez pas à enregistrer une instance lancée à partir de cette AMI payante, adressez-vous au [AWS Support Centre](https://console.aws.amazon.com/support/home#/) pour obtenir de l'aide.