Code d’état HTTP 504 (Délai d’attente de passerelle expiré) - Amazon CloudFront
Configuration du pare-feu sur votre serveur d’origine pour autoriser le trafic CloudFrontConfiguration des groupes de sécurité sur votre serveur d’origine pour autoriser le trafic CloudFrontRendez accessible votre serveur d’origine personnalisée sur InternetRecherchez et corrigez des réponses retardées à partir des applications sur votre serveur d’origine

Code d’état HTTP 504 (Délai d’attente de passerelle expiré)

Un code d’état HTTP 504 (Délai de passerelle expiré) indique que quand CloudFront a transmis une demande à l’origine (car l’objet demandé n’était 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.

Une origine renverra un code de statut HTTP 504 si le trafic CloudFront est bloqué à 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.

Configuration du pare-feu sur votre serveur d’origine pour autoriser le trafic CloudFront

Si le pare-feu sur votre serveur d'origine bloque le trafic CloudFront, CloudFront renvoie un code d'état HTTP 504. Par conséquent, il est judicieux de s'assurer que ce n'est pas le problème avant de rechercher 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 pare-feu IPTables 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 dans la documentation Microsoft.

Lorsque vous évaluez la configuration du pare-feu sur votre serveur d’origine, recherchez les pare-feu ou les règles de sécurité qui bloquent le trafic provenant d’emplacements périphériques CloudFront, en fonction de la plage d’adresses IP publiées. Pour plus d’informations, consultez Emplacements et plages d'adresses IP des serveurs périphériques CloudFront..

Si la plage d'adresses IP CloudFront est autorisée à se connecter à votre serveur d'origine, veillez à mettre à jour les règles de sécurité de votre serveur pour incorporer 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 S’abonner aux modifications d’adresses IP publiques AWS via Amazon SNS sur le Blog des actualités AWS.

Configuration des groupes de sécurité sur votre serveur d’origine pour autoriser le trafic CloudFront

Si votre origine utilise Elastic Load Balancing, passez en revue les groupes de sécurité ELB et assurez-vous que les groupes de sécurité autorisent le trafic entrant à partir de CloudFront.

Vous pouvez également utiliser AWS Lambda pour mettre à jour automatiquement vos groupes de sécurité afin d’autoriser le trafic entrant à partir de CloudFront.

Rendez accessible votre serveur d’origine personnalisée sur Internet

Si CloudFront ne peut pas accéder à votre serveur d'origine personnalisée, car il n'est pas disponible publiquement sur Internet, CloudFront renvoie une erreur HTTP 504.

Les emplacements périphériques CloudFront se connectent aux serveurs d’origine via Internet. Si votre origine personnalisée figure sur un réseau privé, CloudFront ne peut pas l'atteindre. Pour cette raison, vous ne pouvez pas utiliser des serveurs privés, y compris les équilibreurs Classic Load Balancer internes, en tant que 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 pour votre serveur) :

Pour le trafic HTTPS :

  • nc -zv OriginDomainName 443

  • telnet OriginDomainName 443

Pour le trafic HTTP :

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

  2. 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.

  3. Si nécessaire, ajustez la valeur de délai d’attente pour votre distribution CloudFront.

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 dorsal, passez en revue les métriques CloudWatch pour le serveur afin de vérifier l’utilisation de l’UC. Pour plus d’informations, consultez le Guide de l’utilisateur Amazon CloudWatch. 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 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) 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 ?

  • Si vous utilisez MediaTailor comme origine, les causes possibles d’une erreur 504 sont les suivantes :

    • Si les URL relatives sont mal gérées, MediaTailor peut recevoir des URL mal formées de la part des lecteurs.

    • Si MediaPackage est l’origine du manifeste pour MediaTailor, les erreurs 404 de manifeste renvoyées par MediaPackage peuvent amener MediaTailor à retourner une erreur 504.

    • La demande vers le serveur d’origine MediaTailor dépasse un temps d’exécution de plus de 2 secondes.

  • Si vous utilisez Amazon API Gateway comme origine, les causes possibles d’une erreur 504 sont les suivantes :

Réglage de la valeur de délai d’attente de CloudFront, le cas échéant

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 plus d’informations, consultez Délai de réponse.