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 codes d'état des réponses aux erreurs dans CloudFront
Si CloudFront vous demandez un objet à votre origine et que celle-ci renvoie un code d'état HTTP 4xx ou 5xx, cela signifie qu'il y a un problème de communication entre CloudFront et votre origine.
Cette rubrique décrit également les étapes de résolution des problèmes liés à ces codes d'état lors de l'utilisation de Lambda @Edge ou CloudFront de Functions.
Les rubriques suivantes fournissent des explications détaillées sur les causes potentielles de ces réponses d'erreur et proposent des step-by-step conseils sur la manière de diagnostiquer et de résoudre les problèmes sous-jacents.
**Topics**
+ [Code d’état HTTP 400 (Requête incorrecte)](http-400-bad-request.md)
+ [Code d’état HTTP 401 (Accès non autorisé)](http-401-unauthorized.md)
+ [Code d’état HTTP 403 (méthode non valide)](http-403-invalid-method.md)
+ [Code d’état HTTP 403 (Autorisation refusée)](http-403-permission-denied.md)
+ [Code d’état HTTP 404 (Introuvable)](http-404-not-found.md)
+ [Code d’état HTTP 412 (échec de condition préalable)](http-412-precondition-failed.md)
+ [Code d’état HTTP 500 (Erreur de serveur interne)](http-500-internal-server-error.md)
+ [Code d’état HTTP 502 (Passerelle incorrecte)](http-502-bad-gateway.md)
+ [Code d’état HTTP 503 (Service non disponible)](http-503-service-unavailable.md)
+ [Code d’état HTTP 504 (Délai d’attente de passerelle expiré)](http-504-gateway-timeout.md)
# Code d’état HTTP 400 (Requête incorrecte)
CloudFront renvoie une requête incorrecte de 400 lorsque le client envoie des données non valides dans la demande, telles que du contenu manquant ou incorrect dans la charge utile ou les paramètres. Il peut également s’agir d’une erreur client générique.
## L’origine Amazon S3 renvoie une erreur 400
Si vous utilisez une origine Amazon S3 avec votre CloudFront distribution, celle-ci peut envoyer des réponses d'erreur avec le code d'état HTTP 400 Bad Request et un message similaire au suivant :
*L'en-tête d'autorisation est mal formé ; la région « ** » est incorrecte ; « » ** est attendue*
Par exemple :
*The authorization header is malformed; the region ’us-east-1’ is wrong; expecting ’us-west-2’*
Ce problème peut se produire dans le scénario suivant :
1. L'origine de votre CloudFront distribution est un compartiment Amazon S3.
1. Vous avez déplacé le compartiment S3 d'une AWS région à une autre. En d'autres termes, vous avez supprimé le compartiment S3, puis vous avez créé un nouveau compartiment portant le même nom de compartiment, mais dans une AWS région différente de celle où se trouvait le compartiment S3 d'origine.
Pour corriger cette erreur, mettez à jour votre CloudFront distribution afin qu'elle trouve le compartiment S3 dans la AWS région actuelle du compartiment.
**Pour mettre à jour votre CloudFront distribution**
1. Connectez-vous à la CloudFront console AWS Management Console et ouvrez-la à l'adresse[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).
1. Choisissez la distribution qui génère cette erreur.
1. Choisissez **Origins and Origin Groups (Origines et groupes d’origine)**.
1. Recherchez l’origine du compartiment S3 que vous avez déplacé. Activez la case à cocher en regard de cette origine, puis choisissez **Modifier**.
1. Choisissez **Oui, Modifier**. Vous n’avez pas besoin de modifier les paramètres avant de choisir **Oui, Modifier**.
Lorsque vous avez terminé ces étapes, CloudFront redéploie votre distribution. Lorsque la distribution est déployée, l’état du **Déploiement** s’affiche dans la colonne **Dernière modification**. Quelque temps après la fin du déploiement, vous devriez cesser de recevoir les réponses aux·erreurs `AuthorizationHeaderMalformed`.
## L’origine Application Load Balancer renvoie une erreur 400
Si vous utilisez une origine d'Application Load Balancer avec votre CloudFront distribution, les causes possibles d'une erreur 400 sont les suivantes :
+ Le client a envoyé une demande incorrecte qui ne respecte pas la spécification HTTP.
+ L’en-tête de la demande a dépassé 16 Ko par ligne de demande, 16 Ko par en-tête unique ou 64 Ko 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.
# Code d’état HTTP 401 (Accès non autorisé)
Un code d’état de réponse 401 Accès non autorisé indique que la demande du client n’a pas été traitée, car elle ne contient pas d’informations d’identification d’authentification valides pour la ressource demandée. Ce code d’état est envoyé avec un en-tête de réponse HTTP `WWW-Authenticate` qui indique comment le client peut redemander la ressource après avoir sollicité des informations d’identification d’authentification auprès de l’utilisateur. Pour plus d’informations, consultez [401 Accès non autorisé](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/401).
Dans CloudFront, si votre origine s'attend à ce qu'un `Authorization` en-tête authentifie les demandes, elle CloudFront doit le `Authorization` transmettre à l'origine pour éviter une erreur 401 Unauthorized. Lorsque CloudFront vous transférez une demande d'utilisateur à votre source, certains CloudFront en-têtes de visionnage sont supprimés par défaut, y compris l'`Authorization`en-tête. Pour vous assurer que votre origine reçoit toujours l’en-tête `Authorization` dans les demandes d’origine, vous disposez des options suivantes :
+ Ajoutez l’en-tête `Authorization` à la clé de cache à l’aide d’une stratégie de cache. Tous les en-têtes de la clé de cache sont automatiquement inclus dans les demandes d’origine. Pour plus d’informations, consultez [Contrôle de la clé de cache à l’aide d’une politique](controlling-the-cache-key.md).
+ Utilisez une stratégie de demande d’origine qui transfère tous les en-têtes d’utilisateurs à l’origine. Vous ne pouvez pas transférer l'`Authorization`en-tête individuellement dans une politique de demande d'origine, mais lorsque vous transférez tous les en-têtes du lecteur, vous l' CloudFrontincluez dans les `Authorization` demandes du lecteur. CloudFrontfournit la politique de gestion des demandes `AllViewer` d'origine pour ce cas d'utilisation. Pour de plus amples informations, veuillez consulter [Utilisation des stratégies de demande d’origine gérées](using-managed-origin-request-policies.md).
Pour plus d'informations, consultez [Comment puis-je configurer CloudFront pour transférer l'en-tête d'autorisation à l'origine ?](https://repost.aws/knowledge-center/cloudfront-authorization-header)
# Code d’état HTTP 403 (méthode non valide)
CloudFront renvoie une erreur 403 (méthode non valide) si vous essayez d'utiliser une méthode HTTP que vous n'avez pas spécifiée dans la CloudFront distribution. Vous pouvez spécifier l’une des options suivantes pour votre distribution :
+ CloudFront transferts uniquement `GET` et `HEAD` demandes.
+ CloudFront transferts uniquement `GET``HEAD`, et `OPTIONS` demandes.
+ CloudFront les `GET` transferts`HEAD`,`OPTIONS`,`PUT`,, `PATCH``POST`, et les `DELETE` demandes. (Si vous choisissez cette option, vous devrez peut-être restreindre l’accès à votre compartiment Amazon S3 ou à votre origine personnalisée pour éviter que les utilisateurs réalisent des opérations non autorisées.) Par exemple, vous ne souhaiterez pas toujours que les utilisateurs disposent des autorisations nécessaires pour supprimer des objets de votre origine.
# Code d’état HTTP 403 (Autorisation refusée)
Une erreur HTTP 403 signifie que le client n’est pas autorisé à accéder à la ressource demandée. Le client comprend la demande, mais ne peut pas autoriser l’accès de l’utilisateur. Les causes les plus fréquentes du CloudFront renvoi de ce code d'état sont les suivantes :
**Topics**
+ [Le CNAME alternatif est mal configuré](#alternate-cname-incorrectly-configured)
+ [AWS WAF est configuré lors CloudFront de la distribution ou à l'origine](#aws-waf-configured-on-distribution-origin)
+ [L’origine personnalisée renvoie une erreur 403](#custom-origin-returning-403)
+ [L’origine Amazon S3 renvoie une erreur 403](#s3-origin-403-error)
+ [Les restrictions géographiques renvoient une erreur 403](#geolocation-403)
+ [La configuration d’une URL signée ou d’un cookie signé renvoie une erreur 403](#signed-URLs-cookies-403)
+ [Les distributions empilées provoquent une erreur 403](#stacked-distributions-403)
## Le CNAME alternatif est mal configuré
Vérifiez que vous avez spécifié le bon CNAME pour votre distribution. Pour utiliser un autre CNAME au lieu de l' CloudFront URL par défaut :
1. Créez un enregistrement CNAME dans votre DNS pour faire pointer le CNAME vers l'URL de CloudFront distribution.
1. Ajoutez le CNAME dans votre configuration CloudFront de distribution.
Si vous créez l'enregistrement DNS mais n'ajoutez pas le CNAME dans votre configuration de CloudFront distribution, la demande renvoie une erreur 403. Pour plus d’informations sur la configuration d’un CNAME personnalisé, consultez [Utilisez la personnalisation URLs en ajoutant des noms de domaine alternatifs (CNAMEs)](CNAMEs.md).
## AWS WAF est configuré lors CloudFront de la distribution ou à l'origine
Lorsque AWS WAF se situe entre le client et CloudFront, CloudFront vous ne pouvez pas faire la distinction entre un code d'erreur 403 renvoyé par votre origine et un code d'erreur 403 renvoyé AWS WAF lorsqu'une demande est bloquée.
Pour trouver la source du code d'état 403, vérifiez votre règle de liste de contrôle d'accès AWS WAF Web (ACL) pour détecter une demande bloquée. Pour plus d’informations, consultez les rubriques suivantes :
+ [AWS WAF listes de contrôle d'accès Web (WebACLs)](https://docs.aws.amazon.com/waf/latest/developerguide/web-acl.html)
+ [Tester et ajuster vos protections AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/web-acl-testing.html)
## L’origine personnalisée renvoie une erreur 403
Si vous utilisez une origine personnalisée, une erreur 403 peut s’afficher si vous avez une configuration de pare-feu personnalisée à l’origine. Pour résoudre le problème, envoyez la demande directement à l’origine. Si vous pouvez reproduire l'erreur sans CloudFront, l'origine est à l'origine de l'erreur 403.
Si l’origine personnalisée provoque l’erreur, consultez les journaux d’origine pour identifier la cause potentielle de l’erreur. Pour plus d’informations, consultez les rubriques de dépannage suivantes :
+ [Comment résoudre les erreurs HTTP 403 depuis API Gateway ?](https://aws.amazon.com/premiumsupport/knowledge-center/api-gateway-troubleshoot-403-forbidden/ )
+ [Comment résoudre les erreurs HTTP 403 Interdit d’un Application Load Balancer ?](https://repost.aws/knowledge-center/alb-http-403-error)
## L’origine Amazon S3 renvoie une erreur 403
Vous pouvez recevoir une erreur 403 pour les raisons suivantes :
+ CloudFront n'a pas accès au compartiment Amazon S3. Cette situation peut se produire si l’identité d’accès d’origine (OAI) ou le contrôle d’accès d’origine (OAC) ne sont pas activés pour votre distribution et que le compartiment est privé.
+ Le chemin spécifié dans l’URL demandée n’est pas correct.
+ L’objet demandé n’existe pas.
+ L’en-tête de l’hôte a été transféré avec le point de terminaison de l’API REST. Pour plus d’informations, consultez [Spécification d’un compartiment d’en-tête hôte HTTP](https://docs.aws.amazon.com/AmazonS3/latest/userguide/VirtualHosting.html#VirtualHostingSpecifyBucket) dans le *Guide de l’utilisateur Amazon Simple Storage Service*.
+ Vous avez configuré des pages d’erreur personnalisées. Pour de plus amples informations, veuillez consulter [Comment CloudFront traite les erreurs lorsque vous avez configuré des pages d'erreur personnalisées](HTTPStatusCodes.md#HTTPStatusCodes-custom-error-pages).
## Les restrictions géographiques renvoient une erreur 403
Si vous avez activé les restrictions géographiques (également appelées géoblocage) pour empêcher les utilisateurs de zones géographiques spécifiques d'accéder au contenu que vous distribuez par le biais d'une CloudFront distribution, les utilisateurs bloqués reçoivent une erreur 403.
Pour de plus amples informations, veuillez consulter [Restriction de la distribution géographique de votre contenu](georestrictions.md).
## La configuration d’une URL signée ou d’un cookie signé renvoie une erreur 403
Si vous avez activé **Restreindre l'accès des spectateurs** pour configurer le comportement de votre distribution, les demandes qui n'utilisent pas de cookies signés ou signés URLs génèrent une erreur 403. Pour plus d’informations, consultez les rubriques suivantes :
+ [Diffusez du contenu privé avec des cookies signés URLs et signés](PrivateContent.md)
+ [Comment résoudre les problèmes liés à une URL signée ou à des cookies connectés ? CloudFront](https://aws.amazon.com/premiumsupport/knowledge-center/cloudfront-troubleshoot-signed-url-cookies/)
## Les distributions empilées provoquent une erreur 403
Si vous avez deux distributions ou plus dans une chaîne de demandes adressées au point de terminaison d'origine, CloudFront renvoie une erreur 403. Il n’est pas recommandé de mettre une distribution devant une autre distribution.
# Code d’état HTTP 404 (Introuvable)
CloudFront renvoie une erreur 404 (Introuvable) lorsque le client tente d'accéder à une ressource qui n'existe pas. Si vous recevez cette erreur avec votre CloudFront distribution, les causes les plus fréquentes sont les suivantes :
+ La ressource n’existe pas.
+ L’URL est incorrecte.
+ L’origine personnalisée renvoie une erreur 404.
+ Les pages d’erreur personnalisées renvoient une erreur 404. (N’importe quel code d’erreur peut être traduit en 404.) Pour de plus amples informations, veuillez consulter [Comment CloudFront traite les erreurs lorsque vous avez configuré des pages d'erreur personnalisées](HTTPStatusCodes.md#HTTPStatusCodes-custom-error-pages).
+ La page d’erreur personnalisée a été supprimée par erreur, ce qui entraîne un code 404, car la demande recherche cette page d’erreur personnalisée supprimée. Pour de plus amples informations, veuillez consulter [Comment CloudFront traite les erreurs si vous n'avez pas configuré de pages d'erreur personnalisées](HTTPStatusCodes.md#HTTPStatusCodes-no-custom-error-pages).
+ Chemin d’origine incorrect. Si le chemin d’origine est renseigné, sa valeur est ajoutée au chemin de chaque demande depuis le navigateur avant que la demande ne soit transmise à l’origine. Pour de plus amples informations, veuillez consulter [Chemin d’origine](DownloadDistValuesOrigin.md#DownloadDistValuesOriginPath).
# Code d’état HTTP 412 (échec de condition préalable)
CloudFront renvoie un code d'erreur 412 (échec de la précondition) lorsque l'accès à la ressource cible a été refusé. Dans certains cas, un serveur est configuré pour accepter les demandes uniquement lorsque certaines conditions sont remplies. Si l’une des conditions spécifiées n’est pas remplie, le serveur n’autorise pas le client à accéder à la ressource donnée. À la place, le serveur renvoie un code d’erreur 412.
Les causes courantes d'une erreur 412 CloudFront sont les suivantes :
+ Demandes conditionnelles sur des méthodes autres que `GET` ou `HEAD` lorsque la condition définie par les en-têtes `If-Unmodified-Since` ou `If-None-Match` n’est pas remplie. Dans ce cas, la demande, généralement un téléchargement ou une modification d’une ressource, ne peut pas être effectuée.
+ Une condition dans un ou plusieurs champs de demande de l'opération CloudFront [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)d'API est considérée comme fausse.
# Code d’état HTTP 500 (Erreur de serveur interne)
Un code d’état HTTP 500 (Erreur de serveur interne) indique que le serveur a rencontré une situation inattendue qui l’a empêché de traiter la demande. Voici quelques causes courantes de 500 erreurs sur Amazon CloudFront.
**Topics**
+ [Le serveur Origin renvoie une erreur 500 à CloudFront](#origin-server-500-error)
## Le serveur Origin renvoie une erreur 500 à CloudFront
Votre serveur d'origine renvoie peut-être une erreur 500 à CloudFront. Pour plus d’informations, consultez les rubriques de dépannage suivantes :
+ **Si Amazon S3 renvoie une erreur 500**, consultez [Comment résoudre une erreur HTTP 500 ou 503 provenant d’Amazon S3 ?](https://repost.aws/knowledge-center/http-5xx-errors-s3)
+ **Si API Gateway renvoie une erreur 500**, consultez [Comment résoudre les erreurs 5xx pour l’API REST d’API Gateway ?](https://repost.aws/knowledge-center/api-gateway-5xx-error).
+ **Si Elastic Load Balancing renvoie une erreur 500**, consultez [HTTP 500 : erreur de serveur interne](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-troubleshooting.html#http-500-issues) dans le *Guide de l’utilisateur des Application Load Balancers*.
Si la liste précédente ne résout pas l'erreur 500, le problème vient peut-être du fait qu'un CloudFront point de présence renvoie une erreur interne au serveur. Vous pouvez également contacter [Support](https://console.aws.amazon.com/support/home#/) pour obtenir de l’aide.
# 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.
**Topics**
+ [Echec de négociation SSL/TLS entre CloudFront et un serveur d'origine personnalisé](#ssl-negotitation-failure)
+ [L’origine ne répond pas avec les chiffrements/protocoles pris en charge](#origin-not-responding-with-supported-ciphers-protocols)
+ [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](#ssl-certificate-expired)
+ [L’origine ne répond pas sur des ports spécifiés dans les paramètres de l’origine](#origin-not-responding-on-specified-ports)
+ [Erreur de validation Lambda](#http-502-lambda-validation-error)
+ [CloudFront erreur de validation de fonction](#http-502-cloudfront-function-validation-error)
+ [Erreur DNS (`NonS3OriginDnsError`)](#http-502-dns-error)
+ [Erreur 502 pour une origine Application Load Balancer](#cloudfront-alb-502-error)
+ [Erreur 502 pour une origine API Gateway](#cloudfront-api-gateway-502-error)
## 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 SSL/TLS certificat 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'`Host`en-tête de la demande d'origine.
Si les noms de domaine ne correspondent pas, la SSL/TLS poignée de main échoue et CloudFront renvoie un code d'état HTTP 502 (Bad Gateway) et définit l'`X-Cache`en-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 :
+ Obtenez un nouveau SSL/TLS certificat qui inclut les noms de domaine applicables.
Si vous utilisez AWS Certificate Manager (ACM), consultez la section [Demande d'un certificat public](https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-request-public.html) 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 ». Généralement, vous spécifiez le nom de votre domaine, et l'outil renvoie diverses informations sur 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 CloudFront, vous pouvez utiliser OpenSSL pour essayer d'établir SSL/TLS une connexion avec votre serveur d'origine. Si OpenSSL n'est pas en mesure d'établir une connexion, il peut s'agir d'un problème avec la configuration SSL/TLS de votre serveur d'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 (*origin domain*remplacez-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'`-servername`option à la commande OpenSSL, comme dans l'exemple suivant (*CNAME*remplacez-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 des protocoles pris CloudFront en charge, consultez. [Protocoles et chiffrements pris en charge entre CloudFront et l'origine](secure-connections-supported-ciphers-cloudfront-to-origin.md) 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](https://www.ssllabs.com/ssltest). 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](secure-connections-supported-ciphers-cloudfront-to-origin.md).
## 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-Cache`en-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 plus d'informations sur l'installation d'un SSL/TLS certificat sur votre serveur d'origine personnalisé, consultez[Exigez le protocole HTTPS pour la communication entre CloudFront et votre origine personnalisée](using-https-cloudfront-to-custom-origin.md).
## 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 quelque raison que ce soit, 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](https://docs.aws.amazon.com/vpc/latest/userguide/aws-ip-ranges.html) 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](lambda-edge-testing-debugging.md).
## 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](update-function.md).
## 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 ?](https://aws.amazon.com/premiumsupport/knowledge-center/route-53-dns-website-unreachable/)
Pour continuer à résoudre ce problème, vérifiez que les [serveurs de noms faisant autorité](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/route-53-concepts.html#route-53-concepts-authoritative-name-server) 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](https://en.wikipedia.org/wiki/Dig_(command)) ou [nslookup](https://en.wikipedia.org/wiki/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)](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/route-53-concepts.html#route-53-concepts-domain-name-system-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 ?](https://repost.aws/knowledge-center/elb-alb-troubleshoot-502-errors).
## Erreur 502 pour une origine API Gateway
Si vous utilisez API Gateway et que vous recevez une erreur 502, consultez la section [Comment résoudre les erreurs HTTP 502 depuis API Gateway REST APIs avec l'intégration du proxy Lambda](https://repost.aws/knowledge-center/malformed-502-api-gateway) ? .
# Code d’état HTTP 503 (Service non disponible)
Un code de statut HTTP 503 (Service non disponible) indique généralement un problème de performance sur le serveur d’origine. Dans de rares cas, cela indique qu'il est CloudFront temporairement impossible de satisfaire une demande en raison de contraintes de ressources à un emplacement périphérique.
Si vous utilisez Lambda @Edge ou CloudFront Functions, le problème peut être dû à une erreur d'exécution ou à une erreur de dépassement de la limite Lambda @Edge.
**Topics**
+ [Le serveur d’origine n’a pas suffisamment de capacité pour prendre en charge le débit de requêtes](#http-503-service-unavailable-not-enough-origin-capacity)
+ [CloudFront a provoqué l'erreur en raison de contraintes de ressources à l'emplacement périphérique](#http-503-service-unavailable-limited-resources-at-edge-location)
+ [Lambda @Edge ou erreur d'exécution de CloudFront la fonction](#http-503-lambda-execution-error)
+ [Dépassement d’une limite Lambda@Edge](#http-503-lambda-limit-exceeded-error)
## Le serveur d’origine n’a pas suffisamment de capacité pour prendre en charge le débit de requêtes
Lorsqu'un serveur d'origine n'est pas disponible ou ne peut pas traiter les demandes entrantes, il renvoie un code d'état HTTP 503 (Service Unavailable). CloudFront transmet ensuite l'erreur à l'utilisateur. Pour résoudre ce problème, essayez les solutions suivantes :
+ **Si vous utilisez Amazon S3 comme serveur d’origine** :
+ Vous pouvez envoyer 3 500 PUT/COPY/POST/DELETE or 5,500 GET/HEAD demandes par seconde par préfixe Amazon S3 partitionné. Lorsque Amazon S3 renvoie une réponse 503 Ralentissement, cela indique généralement un taux de demandes trop élevé sur un préfixe Amazon S3 donné.
Étant donné que les taux de demandes s’appliquent par préfixe dans un compartiment S3, les objets doivent être répartis entre plusieurs préfixes. À mesure que le taux de demandes sur les préfixes augmente progressivement, Amazon S3 augmente verticalement afin de traiter les demandes de chaque préfixe séparément. Par conséquent, le taux global de demandes que le compartiment peut traiter est un multiple du nombre de préfixes.
+ Pour plus d’informations, consultez [Optimisation de la performance d’Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance.html) dans le *Guide de l’utilisateur Amazon Simple Storage Service*.
+ **Si vous utilisez Elastic Load Balancing comme serveur d’origine** :
+ Assurez-vous que vos instances dorsales peuvent répondre à la surveillance de l’état.
+ Assurez-vous que votre équilibreur de charge et vos instances dorsales peuvent gérer la charge.
Pour en savoir plus, consultez :
+ [Comment résoudre les erreurs 503 renvoyées lors de l’utilisation de Classic Load Balancer ?](https://repost.aws/knowledge-center/503-error-classic)
+ [Comment résoudre les erreurs 503 (service non disponible) depuis mon Application Load Balancer ?](https://repost.aws/knowledge-center/alb-troubleshoot-503-errors)
+ **Si vous utilisez une origine personnalisée** :
+ Examinez les journaux de l’application afin de vérifier que votre origine dispose de ressources suffisantes, telles que la mémoire, l’UC et l’espace disque.
+ Si vous utilisez Amazon EC2 comme système dorsal, assurez-vous que le type d’instance dispose des ressources appropriées pour traiter les demandes entrantes. Pour plus d’informations, consultez [Types d’instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html) dans le *Guide de l’utilisateur Amazon EC2*.
+ **Si vous utilisez API Gateway** :
+ Cette erreur est liée à l’intégration dorsale lorsque l’API API Gateway n’est pas en mesure de recevoir une réponse. Le serveur dorsal peut être :
+ Surchargé au-delà de sa capacité et incapable de traiter les nouvelles demandes des clients.
+ En maintenance temporaire.
+ Pour résoudre cette erreur, consultez les journaux de votre application API Gateway afin de déterminer s’il existe un problème de capacité du système dorsal, d’intégration ou autre.
## CloudFront a provoqué l'erreur en raison de contraintes de ressources à l'emplacement périphérique
Vous recevrez cette erreur dans les rares cas où vous ne CloudFront pouvez pas acheminer les demandes vers le meilleur emplacement périphérique disponible suivant et ne pouvez donc pas satisfaire une demande. Cette erreur est courante lorsque vous effectuez des tests de charge sur votre distribution CloudFront. Pour essayer d’éviter ceci, suivez les conseils de [Test de charge CloudFront](load-testing.md) pour éviter les erreurs 503 (dépassement de capacité).
Si cela se produit dans votre environnement de production, contactez [Support](https://console.aws.amazon.com/support/home#/).
## Lambda @Edge ou erreur d'exécution de CloudFront la fonction
Si vous utilisez Lambda @Edge ou CloudFront Functions, un code d'état HTTP 503 peut indiquer que votre fonction a renvoyé une erreur d'exécution.
Pour plus d’informations sur l’identification et la résolution des erreurs Lambda@Edge, consultez [Test et débogage des fonctions Lambda@Edge](lambda-edge-testing-debugging.md).
Pour plus d'informations sur le test CloudFront des fonctions, consultez[Fonctions de test](test-function.md).
## Dépassement d’une limite Lambda@Edge
Si vous utilisez Lambda@Edge, un code d’état HTTP 503 peut indiquer que Lambda a renvoyé une erreur. Cette erreur peut être due à l’une des raisons suivantes :
+ Le nombre d'exécutions de fonctions a dépassé l'un des quotas définis par Lambda pour limiter les exécutions dans un Région AWS (exécutions simultanées ou fréquence d'invocation).
+ La fonction a dépassé le quota d’expiration de la fonction Lambda.
Pour plus d’informations sur les quotas Lambda@Edge, consultez [Quotas sur Lambda@Edge](cloudfront-limits.md#limits-lambda-at-edge). Pour plus d’informations sur l’identification et la résolution des erreurs Lambda@Edge, consultez [Test et débogage des fonctions Lambda@Edge](lambda-edge-testing-debugging.md). Vous pouvez également consulter les [Quotas de service Lambda](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html) dans le *Guide du développeur AWS Lambda *.
# Code d’état HTTP 504 (Délai d’attente de passerelle expiré)
Un code d'état HTTP 504 (délai d'expiration de la passerelle) indique que lors du CloudFront transfert d'une demande à l'origine (parce que l'objet demandé ne se trouvait pas dans le cache périphérique), l'un des événements suivants s'est produit :
+ L'origine a renvoyé un code d'état HTTP 504 à CloudFront.
+ L'origine n'a pas répondu avant l'expiration de la demande.
CloudFront renverra un code d'état HTTP 504 si le trafic est bloqué vers l'origine par un pare-feu ou un groupe de sécurité, ou si l'origine n'est pas accessible sur Internet. Commencez par vérifier ces problèmes. Ensuite, si l'accès n'est pas le problème, explorez les retards de l'application et les délais d'attente du serveur pour mieux identifier et résoudre les problèmes.
**Topics**
+ [Configurez le pare-feu sur votre serveur d'origine pour autoriser CloudFront le trafic](#http-504-gateway-timeout-configure-firewall)
+ [Configurez les groupes de sécurité sur votre serveur d'origine pour autoriser CloudFront le trafic](#http-504-gateway-timeout-configure-security-groups)
+ [Rendez accessible votre serveur d’origine personnalisée sur Internet](#http-504-gateway-timeout-make-origin-accessible)
+ [Recherchez et corrigez des réponses retardées à partir des applications sur votre serveur d’origine](#http-504-gateway-timeout-slow-application)
## Configurez le pare-feu sur votre serveur d'origine pour autoriser CloudFront le trafic
Si le pare-feu de votre serveur d'origine bloque le CloudFront trafic et CloudFront renvoie un code d'état HTTP 504, il est donc conseillé de vous assurer que ce n'est pas le problème avant de vérifier s'il existe d'autres problèmes.
La méthode que vous utilisez pour déterminer s’il s’agit d’un problème avec votre pare-feu dépend du système que votre serveur d’origine utilise :
+ Si vous utilisez un IPTable pare-feu sur un serveur Linux, vous pouvez rechercher des outils et des informations qui vous aideront à travailler avec IPTables.
+ Si vous utilisez le pare-feu de Windows sur un serveur Windows, consultez [Ajouter ou modifier la règle de pare-feu](https://technet.microsoft.com/en-us/library/cc753558(v=ws.11).aspx) dans la documentation Microsoft.
Lorsque vous évaluez la configuration du pare-feu sur votre serveur d'origine, recherchez les pare-feux ou les règles de sécurité qui bloquent le trafic en provenance des emplacements CloudFront périphériques, en fonction de la plage d'adresses IP publiée. Pour de plus amples informations, veuillez consulter [Emplacements et plages d'adresses IP des serveurs CloudFront périphériques](LocationsOfEdgeServers.md).
Si la plage d'adresses CloudFront IP est autorisée à se connecter à votre serveur d'origine, veillez à mettre à jour les règles de sécurité de votre serveur afin d'intégrer les modifications. Vous pouvez vous abonner à une rubrique Amazon SNS et recevoir des notifications lorsque le fichier de plage d’adresses IP est mis à jour. Après avoir reçu la notification, vous pouvez utiliser le code pour extraire le fichier, l’analyser et effectuer des ajustements pour votre environnement local. Pour plus d'informations, consultez la section [S'abonner aux modifications d'adresse IP AWS publique via Amazon SNS](https://aws.amazon.com/blogs/aws/subscribe-to-aws-public-ip-address-changes-via-amazon-sns/) sur le blog d' AWS actualités.
## Configurez les groupes de sécurité sur votre serveur d'origine pour autoriser CloudFront le trafic
Si votre origine utilise Elastic Load Balancing, passez en revue les [groupes de sécurité ELB](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-groups.html) et assurez-vous qu'ils autorisent le trafic entrant en provenance de. CloudFront
Vous pouvez également l'utiliser AWS Lambda pour mettre à jour automatiquement vos groupes de sécurité afin d'autoriser le trafic entrant en provenance de CloudFront.
## Rendez accessible votre serveur d’origine personnalisée sur Internet
Si CloudFront vous ne parvenez pas à accéder à votre serveur d'origine personnalisé parce qu'il n'est pas accessible au public sur Internet, CloudFront renvoie une erreur HTTP 504.
CloudFront les emplacements périphériques se connectent aux serveurs d'origine via Internet. Si votre origine personnalisée se trouve sur un réseau privé, CloudFront vous ne pouvez pas y accéder. Pour cette raison, vous ne pouvez pas utiliser de serveurs privés, y compris les [équilibreurs de charge classiques internes](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-internal-load-balancers.html), comme serveurs d'origine avec CloudFront.
Pour vérifier que le trafic Internet peut se connecter à votre serveur d'origine, exécutez les commandes suivantes (où se *OriginDomainName* trouve le nom de domaine de votre serveur) :
Pour le trafic HTTPS :
+ NC-ZV 443 *OriginDomainName*
+ telnet 443 *OriginDomainName*
Pour le trafic HTTP :
+ NC-ZV 80 *OriginDomainName*
+ telnet 80 *OriginDomainName*
## Recherchez et corrigez des réponses retardées à partir des applications sur votre serveur d’origine
Les délais d’attente du serveur sont souvent le résultat d’une application qui met beaucoup de temps à répondre ou de la définition d’une valeur de délai d’attente trop faible.
Une solution rapide pour essayer d'éviter des erreurs HTTP 504 consiste à définir simplement une valeur de délai d'attente CloudFront plus élevée pour votre distribution. Cependant, nous vous recommandons de commencer par vous assurer que vous traitez tous les problèmes de performances et de latence liés à l’application et au serveur d’origine. Ensuite, vous pouvez définir une valeur de délai d’attente raisonnable qui vise à empêcher les erreurs HTTP 504 et qui offre une bonne réactivité aux utilisateurs.
Voici une vue d'ensemble des étapes que vous pouvez suivre pour rechercher des problèmes de performances et les corriger :
1. Mesurez la latence standard et à charge élevée (réactivité) de votre application web.
1. Ajoutez d’autres ressources, telles que l’UC ou la mémoire, si nécessaire. Prenez d’autres mesures pour résoudre les problèmes, telles que le réglage des requêtes de base de données pour prendre en charge les scénarios à charge élevée.
1. Si nécessaire, ajustez la valeur du délai d'expiration pour votre CloudFront distribution.
Vous trouverez ci-après des détails relatifs à chaque étape.
### Mesure de la latence standard et à charge élevée
Pour déterminer si un ou plusieurs serveurs d’application web dorsaux présentent une latence élevée, exécutez la commande curl Linux suivante sur chaque serveur :
```
curl -w "DNS Lookup Time: %{time_namelookup} \nConnect time: %{time_connect} \nTLS Setup: %{time_appconnect} \nRedirect Time: %{time_redirect} \nTime to first byte: %{time_starttransfer} \nTotal time: %{time_total} \n" -o /dev/null https://www.example.com/yourobject
```
**Note**
Si vous exécutez Windows sur vos serveurs, vous pouvez rechercher et télécharger curl pour Windows afin d’exécuter une commande similaire.
Lorsque vous mesurez et évaluez la latence d’une application qui s’exécute sur votre serveur, gardez à l’esprit les points suivants :
+ Les valeurs de latence sont relatives à chaque application. Toutefois, un délai jusqu’au premier octet en millisecondes plutôt qu’en secondes ou plus est raisonnable.
+ Si vous mesurez la latence de l'application sous une charge normale et qu'elle est satisfaisante, sachez que les utilisateurs peuvent tout de même connaître des dépassements de délais d'attente sous une charge élevée. Lorsqu’il y a une forte demande, les serveurs peuvent avoir des réponses différées ou aucune réponse du tout. Pour essayer d'éviter les problèmes de latence en cas de charge élevée, vérifiez les ressources de vos serveurs telles que l'UC, la mémoire et les lectures et écritures sur disque pour vous assurer que vos serveurs ont la capacité d'évoluer suffisamment pour traiter une charge élevée.
Vous pouvez exécuter la commande Linux suivante pour vérifier la mémoire utilisée par les processus Apache :
`watch -n 1 "echo -n 'Apache Processes: ' && ps -C apache2 --no-headers | wc -l && free -m"`
+ Une utilisation intensive de l'UC sur le serveur peut réduire considérablement les performances d'une application. Si vous utilisez une instance Amazon EC2 pour votre serveur principal, passez en revue les CloudWatch métriques du serveur afin de vérifier l'utilisation du processeur. Pour plus d'informations, consultez le [guide de CloudWatch l'utilisateur Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html). Ou, si vous utilisez votre propre serveur, reportez-vous à la documentation d’aide du serveur pour obtenir des instructions sur la manière de vérifier l’utilisation de l’UC.
+ Recherchez d'autres problèmes potentiels sous des charges élevées, telles que les requêtes de base de données qui s'exécutent lentement dans le cas d'un grand volume de demandes.
### Ajout de ressources et réglage des serveurs et des bases de données
Une fois que vous avez évalué la réactivité de vos applications et serveurs, assurez-vous d’avoir les ressources suffisantes en place pour gérer des situations à trafic standard et à charge élevée :
+ Si vous possédez votre propre serveur, assurez-vous qu’il a suffisamment d’UC, de mémoire et d’espace disque pour gérer les demandes des utilisateurs, en fonction de votre évaluation.
+ Si vous utilisez une instance Amazon EC2 comme serveur dorsal, assurez-vous que le type d’instance dispose des ressources appropriées pour traiter les demandes entrantes. Pour plus d’informations, consultez [Types d’instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html) dans le *Guide de l’utilisateur Amazon EC2*.
En outre, prenez en compte les étapes de réglage suivantes pour essayer d’éviter le dépassement des délais d’attente :
+ Si la valeur du délai jusqu’au premier octet qui est renvoyée par la commande curl semble élevée, prenez des mesures pour améliorer les performances de votre application. L’amélioration de la réactivité de l’application aidera à son tour à réduire les erreurs de dépassement de délai.
+ Réglez les requêtes de base de données pour vous assurer que de grands volumes de requêtes peuvent être gérés sans ralentir les performances.
+ Configurez des connexions [ keep-alive (persistantes)](https://www.w3.org/Protocols/HTTP/1.1/draft-ietf-http-v11-spec-01) sur votre serveur dorsal. Cette option permet d’éviter les latences qui se produisent lorsque les connexions doivent être rétablies pour des demandes ou des utilisateurs suivants.
+ **Si vous utilisez Elastic Load Balancing comme origine**, les causes possibles d’une erreur 504 sont les suivantes :
+ 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é.
+ La liste de contrôle d’accès (ACL) réseau pour le sous-réseau n’a pas autorisé le trafic depuis les cibles vers les nœuds d’équilibreur 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 Lambda n’a pas répondu avant l’expiration du délai de connexion.
Pour plus d’informations sur la réduction de la latence, consultez [Comment résoudre les problèmes de latence élevée sur mon ELB Classic Load Balancer ?](https://repost.aws/knowledge-center/elb-latency-troubleshooting)
+ **Si vous utilisez MediaTailor comme origine**, les causes possibles d'une erreur 504 sont les suivantes :
+ Si un membre URLs de la famille est mal manipulé, les joueurs MediaTailor peuvent être malformés URLs .
+ S'il s' MediaPackage agit de l'origine du manifeste MediaPackage 404 MediaTailor, les erreurs de manifeste peuvent MediaTailor entraîner le renvoi d'une erreur 504.
+ La demande adressée au serveur MediaTailor d'origine prend plus de 2 secondes pour être traitée.
+ **Si vous utilisez Amazon API Gateway comme origine**, les causes possibles d’une erreur 504 sont les suivantes :
+ Une demande d’intégration dépasse le délai maximal d’intégration défini pour votre API REST API Gateway. Pour plus d’informations, consultez [Comment résoudre les erreurs de délai dépassé API HTTP 504 avec API Gateway ?](https://repost.aws/knowledge-center/api-gateway-504-errors)
### Si nécessaire, ajustez la valeur du CloudFront délai d'attente
Si vous avez évalué et traité le problème de la lenteur de la performance de l’application, de la capacité du serveur d’origine et d’autres problèmes, mais que les utilisateurs connaissent encore des erreurs HTTP 504, vous devez envisager de modifier le temps spécifié dans votre distribution comme délai d’attente de réponse de l’origine. Pour de plus amples informations, veuillez consulter [Délai de réponse](DownloadDistValuesOrigin.md#DownloadDistValuesOriginResponseTimeout).