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

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

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

  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 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 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 EC2 instance Amazon 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. Ou si vous utilisez votre propre serveur, reportez-vous à la documentation d'aide du serveur pour savoir comment vérifier l'utilisation du processeur.

  • 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 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, voir 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é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 :

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 (origines personnalisées et VPC uniquement).