Code d’état HTTP 502 (Passerelle incorrecte)

CloudFront renvoie un code d'état HTTP 502 (Bad Gateway) lorsqu'il CloudFront n'a pas pu servir l'objet demandé car il n'a pas pu se connecter au serveur d'origine.

Si vous utilisez Lambda @Edge, le problème est peut-être dû à une erreur de validation Lambda. Si vous recevez une erreur HTTP 502 avec le code NonS3OriginDnsError d'erreur, il est probable qu'un problème de configuration DNS CloudFront empêche la connexion à l'origine.

Echec de négociation SSL/TLS entre CloudFront et un serveur d'origine personnalisé

Si vous utilisez une origine personnalisée qui nécessite le protocole HTTPS entre CloudFront et votre origine, des noms de domaine incompatibles peuvent provoquer des erreurs. Le certificat SSL/TLS de votre origine doit inclure un nom de domaine correspondant soit au domaine d'origine que vous avez spécifié pour la CloudFront distribution, soit à l'Hosten-tête de la demande d'origine.

Si les noms de domaine ne correspondent pas, le handshake SSL/TLS échoue et CloudFront renvoie un code d'état HTTP 502 (Bad Gateway) et définit l'en-tête sur. X-Cache Error from cloudfront

Pour déterminer si les noms de domaine du certificat correspondent au domaine d'origine de la distribution ou de l'Hosten-tête, vous pouvez utiliser un vérificateur SSL en ligne ou OpenSSL. Si les noms de domaine ne correspondent pas, vous avez deux options :

• Demandez un nouveau certificat SSL/TLS qui inclut les noms de domaine applicables.

  Si vous utilisez AWS Certificate Manager (ACM), consultez la section Demande d'un certificat public dans le guide de AWS Certificate Manager l'utilisateur pour demander un nouveau certificat.

• Modifiez la configuration de distribution afin de CloudFront ne plus essayer d'utiliser le protocole SSL pour vous connecter à votre origine.

Outil de vérification SSL en ligne

Pour trouver un outil de test SSL, recherchez sur Internet « online ssl checker ». En règle générale, vous spécifiez le nom de votre domaine, et l’outil renvoie différentes informations sur votre certificat SSL/TLS. Vérifiez que le certificat contient votre nom de domaine dans les champs Common Names ou Subject Alternative Names.

OpenSSL 

Pour résoudre les erreurs HTTP 502 provenant de CloudFront, vous pouvez utiliser OpenSSL pour essayer d'effectuer une configuration. SSL/TLS connection to your origin server. If OpenSSL is not able to make a connection, that can indicate a problem with your origin server's SSL/TLS Si OpenSSL est en mesure d'établir une connexion, il renvoie des informations sur le certificat du serveur d'origine, y compris le nom commun (champ Subject CN) et le nom alternatif d'objet (champ Subject Alternative Name) du certificat.

Utilisez la commande OpenSSL suivante pour tester la connexion à votre serveur d'origine (origin domainremplacez-la par le nom de domaine de votre serveur d'origine, tel que exemple.com) :

openssl s_client -connect origin domain name:443

Si les conditions suivantes sont réunies :

• Votre serveur d’origine prend en charge plusieurs noms de domaine avec plusieurs certificats SSL/TLS

• Votre distribution est configurée pour transférer l’en-tête Host vers l’origine

Ajoutez ensuite l'-servernameoption à la commande OpenSSL, comme dans l'exemple suivant (CNAMEremplacez-la par le CNAME configuré dans votre distribution) :

openssl s_client -connect origin domain name:443 -servername CNAME

L’origine ne répond pas avec les chiffrements/protocoles pris en charge

CloudFront se connecte aux serveurs d'origine à l'aide de chiffrements et de protocoles. Pour obtenir la liste des chiffrements et protocoles pris CloudFront en charge, consultez. Protocoles et chiffrements pris en charge entre CloudFront et l'origine Si votre origine ne répond pas avec l'un de ces chiffrements ou protocoles dans l'échange SSL/TLS, elle ne parvient pas à se connecter. CloudFront Vous pouvez vérifier que votre origine prend en charge les chiffrements et les protocoles à l’aide d’un outil en ligne tel que SSL Labs. Saisissez le nom de domaine de votre origine dans le champ Hostname, puis choisissez Submit. Consultez les champs Noms Communs et autres noms (SAN) du test pour savoir si ces noms correspondent au nom de domaine de votre origine. A la fin du test, consultez les sections Protocols et Cipher Suites des résultats pour connaître les chiffrements ou les protocoles pris en charge par votre origine. Comparez-les à la liste des Protocoles et chiffrements pris en charge entre CloudFront et l'origine.

Le certificat SSL/TLS sur l’origine a expiré, n’est pas valide, est auto-signé ou la chaîne de certificats est dans l’ordre incorrect

Si le serveur d'origine renvoie ce qui suit, CloudFront abandonne la connexion TCP, renvoie le code d'état HTTP 502 (Bad Gateway) et définit l'X-Cacheen-tête comme suit : Error from cloudfront

• Certificat expiré

• Certificat non valide

• Certificat auto-signé

• Chaîne de certificats dans le désordre

Note

Si la chaîne complète de certificats, y compris le certificat intermédiaire, n'est pas présente, CloudFront supprime la connexion TCP.

Pour obtenir des informations sur l’installation d’un certificat SSL/TLS sur votre serveur d’origine personnalisée, consultez Exigez le protocole HTTPS pour la communication entre CloudFront et votre origine personnalisée.

L’origine ne répond pas sur des ports spécifiés dans les paramètres de l’origine

Lorsque vous créez une origine sur votre CloudFront distribution, vous pouvez définir les ports qui CloudFront se connectent à l'origine pour le trafic HTTP et HTTPS. Par défaut, il s’agit des ports TCP 80/443. Vous avez la possibilité de modifier ces ports. Si votre point d'origine rejette le trafic sur ces ports pour une raison quelconque, ou si votre serveur principal ne répond pas sur les ports, la connexion CloudFront échouera.

Pour résoudre ces problèmes, vérifiez les pare-feu qui s’exécutent dans votre infrastructure et vérifiez qu’ils ne bloquent pas les plages IP prises en charge. Pour plus d'informations, consultez les plages d'adresses AWS IP dans le guide de l'utilisateur Amazon VPC. Vous pouvez également vérifier que votre serveur web s’exécute sur l’origine.

Erreur de validation Lambda

Si vous utilisez Lambda@Edge, un code de statut HTTP 502 peut indiquer que la réponse de votre fonction Lambda était mal formulée ou comprenait du contenu non valide. Pour de plus amples informations sur le dépannage des erreurs Lambda@Edge, veuillez consulter Tester et déboguer les fonctions Lambda @Edge.

CloudFront erreur de validation de fonction

Si vous utilisez des CloudFront fonctions, un code d'état HTTP 502 peut indiquer que la CloudFront fonction essaie d'ajouter, de supprimer ou de modifier un en-tête en lecture seule. Cette erreur ne s'affiche pas pendant le test, mais elle apparaîtra une fois que vous aurez déployé la fonction et exécuté la demande. Pour résoudre cette erreur, vérifiez et mettez à jour votre CloudFront fonction. Pour de plus amples informations, veuillez consulter Fonctions de mise à jour.

Erreur DNS (NonS3OriginDnsError)

Une erreur HTTP 502 avec le code NonS3OriginDnsError d'erreur indique qu'un problème de configuration DNS CloudFront empêche la connexion à l'origine. Si cette erreur provient de CloudFront, assurez-vous que la configuration DNS de l'origine est correcte et fonctionne.

Lorsqu'il CloudFront reçoit une demande pour un objet expiré ou qui n'est pas dans son cache, il adresse une demande à l'origine pour obtenir l'objet. Pour envoyer une demande à l'origine avec succès, CloudFront effectue une résolution DNS sur le domaine d'origine. Si le service DNS de votre domaine rencontre des problèmes, CloudFront vous ne parvenez pas à résoudre le nom de domaine pour obtenir l'adresse IP, ce qui entraîne une erreur HTTP 502 (NonS3OriginDnsError). Pour résoudre ce problème, contactez votre fournisseur DNS ou, si vous utilisez Amazon Route 53, consultez Pourquoi est-ce que je ne peux pas accéder à mon site Web qui utilise les services DNS Route 53 ?

Pour continuer à résoudre ce problème, vérifiez que les serveurs de noms faisant autorité du domaine racine ou de la zone apex (comme example.com) de votre origine fonctionne correctement. Vous pouvez utiliser les commandes suivantes pour trouver les serveurs de noms pour votre origine apex, à l'aide d'un outil tel que dig ou nslookup :

dig OriginAPEXDomainName NS +short

nslookup -query=NS OriginAPEXDomainName

Quand vous avez les noms de vos serveurs de noms, utilisez les commandes suivantes pour interroger le nom de domaine de votre origine sur ceux-ci afin de vous assurer qu’ils répondent :

dig OriginDomainName @NameServer

nslookup OriginDomainName NameServer

Important

Assurez-vous d'effectuer ce dépannage DNS à l'aide d'un ordinateur connecté à l'Internet public. CloudFront résout le domaine d'origine à l'aide du DNS public sur Internet. Il est donc important de résoudre le problème dans un contexte similaire.

Si votre origine est un sous-domaine dont l'autorité DNS est déléguée à un serveur de noms différent du domaine racine, assurez-vous que les enregistrements du serveur de noms (NS) et du début de l'autorité (SOA) sont correctement configurés pour le sous-domaine. Vous pouvez vérifier ces enregistrements à l'aide de commandes similaires aux exemples précédents.

Pour plus d'informations sur DNS, consultez les Concepts du système de noms de domaine (DNS) dans la documentation d'Amazon Route 53.

Erreur d'origine 502 de l'Application Load Balancer

Si vous utilisez Application Load Balancer comme origine et que vous recevez une erreur 502, consultez Comment résoudre les erreurs HTTP 502 d'Application Load Balancer ? .

Erreur 502 d'origine de l'API Gateway

Si vous utilisez API Gateway et que vous recevez une erreur 502, consultez Comment résoudre les erreurs HTTP 502 depuis API Gateway REST APIs avec l'intégration du proxy Lambda ? .