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.

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 peut être lié à 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.

SSL/TLS échec de négociation 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 SSL/TLS certificat de votre origine doit inclure un nom de domaine qui correspond 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, l' SSL/TLS établissement de liaison échoue et CloudFront renvoie un code d'état HTTP 502 (Bad Gateway) et définit l'X-Cacheen-tête sur. Error from cloudfront

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

Outil de vérification SSL en ligne

Pour trouver un outil de test SSL, recherchez sur Internet « online ssl checker ». Généralement, vous spécifiez le nom de votre domaine et l'outil renvoie diverses informations concernant votre SSL/TLS certificat. 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'établir une SSL/TLS connexion avec votre serveur d'origine. Si OpenSSL ne parvient pas à établir une connexion, cela peut indiquer un problème avec la configuration de votre serveur d'SSL/TLS origine. 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 (remplacez-la par le nom origin domain de domaine de votre serveur d'origine, tel que example.com) :

openssl s_client -connect origin domain name:443

Si les conditions suivantes sont réunies :

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

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

Origin ne répond pas avec « pris en charge » ciphers/protocols

CloudFront se connecte aux serveurs d'origine à l'aide de chiffrements et de protocoles. Pour obtenir la liste des chiffrements et des 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'SSL/TLS échange, la connexion CloudFront échoue. 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.

SSL/TLS le certificat d'origine est expiré, non valide, auto-signé ou la chaîne de certificats n'est pas dans le bon ordre

Si le serveur d'origine renvoie les informations suivantes, CloudFront interrompt la connexion TCP, renvoie le code d'état HTTP 502 (Bad Gateway) et définit l'X-Cacheen-tête sur : Error from cloudfront

Pour plus d'informations sur l'installation d'un SSL/TLS certificat sur votre serveur d'origine personnalisé, consultezExigez 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 du protocole TCP 80/443. Vous avez la possibilité de modifier ces ports. Si votre 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 Plages d’adresses IP AWS 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 plus d’informations sur le dépannage des erreurs Lambda@Edge, consultez  Test et débogage des 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 Mise à jour de fonctions.

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 vous obtenez cette erreur CloudFront, assurez-vous que la configuration DNS de l'origine est correcte et qu'elle fonctionne.

Lorsqu'il CloudFront reçoit une demande pour un objet qui a expiré ou qui n'est pas dans son cache, il adresse une demande à l'origine pour obtenir l'objet. Pour envoyer une requête à l'origine avec succès, CloudFront exécute une résolution DNS sur le domaine d'origine. Si le service DNS de votre domaine rencontre des problèmes, CloudFront impossible de 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

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 502 pour une origine 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 pour une origine API Gateway

Si vous utilisez API Gateway et que vous recevez une erreur 502, consultez Comment résoudre les erreurs HTTP 502 provenant des API REST d’API Gateway utilisant une intégration de proxy Lambda ?.