HTTPCode d'état 504 (Gateway Timeout)

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 de statut 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.

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 y a 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 avecIPTables.

• Si vous utilisez le pare-feu de Windows sur un serveur Windows, consultez Ajouter ou modifier la règle de pare-feu 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.

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 SNS rubrique Amazon 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 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 ELB sécurité 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, 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ù OriginDomainName est le nom de domaine de votre serveur) :

Pour HTTPS le trafic :

• nc -zv OriginDomainName 443

• telnet OriginDomainName 443

Pour HTTP le trafic :

• nc -zv OriginDomainName 80

• telnet OriginDomainName 80

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 éviter les erreurs HTTP 504 consiste simplement à définir une valeur de CloudFront délai d'attente 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. Vous pouvez ensuite définir une valeur de délai d'attente raisonnable qui permet d'éviter les erreurs HTTP 504 et 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.

2. Ajoutez des ressources supplémentaires, telles que CPU de 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.

3. 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 backend 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 éviter les problèmes de latence de charge élevée, vérifiez les ressources de votre serveurCPU, telles que la mémoire et les lectures et écritures sur disque, pour vous assurer que vos serveurs ont la capacité de s'adapter à 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 CPU utilisation élevée du serveur peut réduire considérablement les performances d'une application. Si vous utilisez une EC2 instance Amazon pour votre serveur principal, passez en revue les CloudWatch métriques du serveur pour vérifier son CPU utilisation. Pour plus d'informations, consultez le guide de CloudWatch l'utilisateur Amazon. Ou si vous utilisez votre propre serveur, reportez-vous à la documentation d'aide du serveur pour savoir comment vérifier son CPU utilisation.

• 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 avez votre propre serveur, assurez-vous qu'il dispose de suffisamment CPU de mémoire et d'espace disque pour traiter les demandes des visiteurs, en fonction de votre évaluation.

• Si vous utilisez une EC2 instance Amazon comme serveur principal, assurez-vous que le type d'instance dispose des ressources appropriées pour répondre aux demandes entrantes. Pour plus d'informations, consultez la section Types d'instances dans le guide de EC2 l'utilisateur Amazon.

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) sur votre serveur backend. 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 ne parvient pas à établir de connexion avec la cible avant l'expiration du délai de connexion (10 secondes).

  • L'équilibreur de charge établit une connexion avec la cible, mais celle-ci ne répond pas avant l'expiration du délai d'inactivité.

  • La liste de contrôle d'accès réseau (ACL) du sous-réseau n'autorise pas le trafic entre les cibles et les nœuds d'équilibrage de charge sur les ports éphémères (1024-65535).

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

  • La cible est une fonction Lambda et Lambda ne répond pas 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 ?

• 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ésURLs.

  • 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 prend plus de temps que le paramètre de délai d'intégration REST API maximal de votre API passerelle. Pour plus d'informations, consultez Comment puis-je résoudre les erreurs de temporisation API HTTP 504 avec Gateway ? API

Si nécessaire, ajustez la valeur du CloudFront délai d'attente

Si vous avez évalué et résolu le ralentissement des performances des applications, de la capacité du serveur d'origine ou d'autres problèmes, mais que les utilisateurs rencontrent toujours des erreurs HTTP 504, vous devriez envisager de modifier le délai d'expiration de réponse indiqué dans votre distribution. Pour de plus amples informations, veuillez consulter Délai de réponse (origines personnalisées uniquement).