L’erreur 504 Gateway Timeout est l’une des erreurs HTTP 5xx les plus courantes auxquelles sont confrontés les propriétaires et les visiteurs de sites web. Pour de nombreux blogs WordPress et plateformes eCommerce, il est essentiel de savoir comment réparer des erreurs de serveur comme celle-ci pour empêcher leurs visiteurs, qui l’ont atteinte, de partir vers des sites concurrents.

Comme l’erreur 504 Gateway Timeout ne vous dit pas pourquoi elle s’est produite, il est difficile d’identifier la cause du dépassement du délai du serveur. Cet article vous aidera à la comprendre en profondeur, à apprendre comment en diagnostiquer la cause, puis à la corriger.

Après avoir essayé les différentes solutions mentionnées dans cet article, votre site devrait être opérationnel en un rien de temps.

Cela vous semble intéressant ? Plongeons dans le vif du sujet !

L'erreur 504 Gateway Timeout est l'une des erreurs HTTP 5xx les plus courantes auxquelles sont confrontés les propriétaires et les visiteurs de sites web. 🤔 Apprenez à la corriger rapidement grâce à ce guide. ⬇️Click to Tweet

Qu’est-ce que l’erreur 504 Gateway Timeout ?

Chaque fois que vous visitez un site web dans votre navigateur, celui-ci envoie une requête au serveur web où le site est hébergé. Le serveur traite la requête et répond avec les ressources demandées.

Comment fonctionnent les requêtes et les réponses HTTP

Comment fonctionnent les requêtes et les réponses HTTP

La réponse du serveur comprend un des nombreux codes d’état HTTP pour indiquer l’état de la réponse au navigateur. Mais tous ces codes d’état HTTP ne sont pas des erreurs. Par exemple, un code d’état 200 OK signifie que le serveur a traité la requête avec succès et que « Tout est OK ».

La classe 5xx des codes d’état HTTP indique que quelque chose ne va pas avec le serveur, que le serveur en est conscient et qu’il ne peut pas exécuter la requête du client. Par conséquent, ils sont également appelés codes d’état 5xx d’erreur serveur.

Officiellement, cinq codes d’état sont spécifiés sous la classe 5xx (500, 501, 502, 503, 504). Vous pouvez également trouver de nombreux codes non officiels (506, 507, 509, 520, etc.).

L’Internet Engineering Task Force (IETF) définit l’erreur 504 Gateway Timeout comme suit :

Le code d’état 504 (Gateway Timeout) indique que le serveur, bien qu’agissant comme une passerelle ou un proxy, n’a pas reçu de réponse en temps utile de la part d’un serveur en amont auquel il devait accéder afin de compléter la requête.

Pour simplifier davantage, cette erreur se produit lorsque deux serveurs sont impliqués dans le traitement d’une requête, et que le premier serveur (généralement le serveur principal) attend une réponse du second serveur (serveur en amont).

L’erreur 504 Gateway Timeout se manifeste sous diverses formes. Voici quelques façons dont elle se manifeste habituellement :

L'erreur HTTP 504 dans le navigateur Chrome

L’erreur HTTP 504 dans le navigateur Chrome

L’erreur 504 Gateway Timeout est similaire à l’erreur 502 Bad Gateway, qui indique que le premier serveur a reçu une réponse non valide du second serveur (serveur en amont).

Le code d’état « 504 GATEWAY TIMEOUT » dans Chrome DevTools

Le code d’état « 504 GATEWAY TIMEOUT » dans Chrome DevTools

Variations de l’erreur 504 Gateway Timeout

Le navigateur affiche toute erreur 504 Gateway Timeout à l’intérieur de celui-ci, comme toute autre erreur. Comme il existe une variété de systèmes d’exploitation, de serveurs web, de navigateurs et d’agents utilisateurs, elle peut s’afficher de multiples façons.

Vous trouverez ci-dessous quelques variantes courantes de messages d’erreur 504 que vous pourriez rencontrer :

Toutes les réponses d’erreur ci-dessus, bien que formulées différemment, pointent vers la même erreur 504 Gateway Timeout.

Les serveurs et les sites web peuvent personnaliser la façon dont ils affichent l’erreur 504 Gateway Timeout aux utilisateurs. Certains d’entre eux peuvent être cool ! C’est une excellente tactique pour apaiser la déception de leurs visiteurs.

La page d'erreur HTTP 504 personnalisée de GitHub

La page d’erreur HTTP 504 personnalisée de GitHub

Impact de l’erreur 504 Gateway Timeout sur le SEO

Toutes les erreurs 5xx empêchent le chargement d’une page web, ce qui les rend préjudiciables à l’expérience de l’utilisateur. C’est pourquoi les moteurs de recherche comme Google prennent ces erreurs au sérieux. Si l’erreur persiste pendant une longue période, elle peut même conduire à la désindexation de la page web des résultats du moteur de recherche.

Par exemple, lorsque les robots Google tombent sur une erreur 503 Service Unavailable, ils comprennent qu’il s’agit d’un problème temporaire car il est surtout utilisé pour activer le mode de maintenance du site. Ainsi, ils essaieront plus tard d’explorer à nouveau la page.

Une erreur 504 Gateway Timeout n’est pas nécessairement temporaire car elle peut être due à de multiples raisons. Si votre site est en panne pendant quelques minutes seulement, et si les robots essaient de le parcourir plusieurs fois par minute, ils essaieront de servir la page à partir de leur cache. Ils ne le remarqueront même pas.

Mais si votre site est en panne pendant plus de 6 heures, Google considérera l’erreur 504 comme un problème grave à l’échelle du site que vous devez corriger dès que possible. Cela peut avoir un impact négatif sur votre référencement.

Affichage des erreurs d'exploration dans la console de recherche Google

Affichage des erreurs d’exploration dans la console de recherche Google

La Google Search Console est l’un des meilleurs outils de SEO pour surveiller les erreurs HTTP 5xx de votre site web.

Causes de l’erreur 504 Gateway Timeout

Comme l’erreur 504 est due à un délai d’attente entre les serveurs, le problème ne vient probablement pas de l’appareil du client ou de sa connexion Internet. Cela inclut également votre appareil et votre connexion.

Une erreur 504 Gateway Timeout indique que le serveur web attend trop longtemps une réponse d’un autre serveur et « dépasse le délai ». Les raisons de ce dépassement de délai peuvent être multiples : l’autre serveur ne fonctionne pas correctement, il est surchargé ou il est en panne.

L’autre serveur ne doit pas toujours être un serveur externe (par exemple, CDN, passerelle API). Il peut également s’agir d’une entité de type serveur au sein du serveur web principal (par exemple, un serveur de proxy inverse, un serveur de base de données).

Comment corriger l’erreur 504 Gateway Timeout

Sans connaître les détails exacts du site WordPress tels que la configuration de son serveur, son plan d’hébergement, les extensions tierces et le trafic qu’il attire, vous pouvez trouver frustrant et accablant de corriger une erreur 504 Gateway Timeout.

Comme de nombreuses variables sont impliquées, je vous recommande de commencer par corriger les problèmes côté client, qui sont assez rares, puis de passer à la correction des problèmes côté serveur, qui sont généralement les coupables avec des erreurs 504.

Essayez de recharger la page web

L’une des premières choses que vous pouvez essayer lorsque vous rencontrez une erreur 504 Gateway Timeout est d’attendre quelques minutes et d’essayer de recharger la page.

Vous pouvez appuyer sur le raccourci clavier F5 pour actualiser/recharger la page web dans la plupart des navigateurs. Pour supprimer le cache du navigateur avant de recharger la page, vous pouvez appuyer à la place sur la combinaison de touches CTRL+F5.

Actualiser une page web dans le navigateur Chrome

Actualiser une page web dans le navigateur Chrome

Pendant que vous y êtes, vous pouvez aussi essayer de charger le site dans un autre navigateur pour éliminer ce problème. Comme la plupart des erreurs 504 sont dues à des serveurs temporairement surchargés, cette solution devrait vous permettre de retrouver votre site.

Si le fait d’attendre et de recharger le site ne résout pas le problème de l’erreur 504, vous pouvez vérifier si le site est en panne pour tout le monde ou seulement pour vous. Les deux grands outils en ligne permettant de vérifier si un site est en panne pour tout le monde ou seulement pour vous sont Down for Everyone or Just Me et Is It Down Right Now?

Test de Kinsta.com sur Down for Everyone or Just Me

Test de Kinsta.com sur Down for Everyone or Just Me

Redémarrez vos périphériques réseau

Parfois, des problèmes avec vos périphériques réseau comme le modem ou le routeur peuvent entraîner une erreur 504 Gateway Timeout. Le redémarrage de ces appareils peut vous aider à résoudre le problème.

Bien que vous puissiez éteindre tous ces appareils de réseau dans n’importe quel ordre, l’ordre dans lequel vous les remettez en marche est important. En général, vous allumez ces appareils de l’extérieur vers l’intérieur, en suivant l’ordre de connexion du fournisseur de services internet à votre appareil client principal.

Vérifiez les réglages de votre proxy

Un serveur proxy se trouve entre votre appareil et l’internet. Il est principalement utilisé pour améliorer la protection de la vie privée en ligne en cachant des informations privées (par exemple l’emplacement de l’appareil) aux sites web et aux serveurs web (par exemple en utilisant un VPN).

Bien qu’il soit rare que les serveurs proxy provoquent une erreur 504, des réglages incorrects de serveur proxy peuvent parfois en être la cause. Vous pouvez désactiver le serveur proxy et essayer de recharger la page web pour voir si cela corrige l’erreur.

Modification des réglages du « Proxy » dans Windows 10

Modification des réglages du « Proxy » dans Windows 10

La plupart des clients n’utilisent pas de service de proxy, vous pouvez donc sauter cette étape si vous êtes sûr de ne pas utiliser de serveur proxy. Cependant, vous pouvez l’avoir configuré sans même vous en rendre compte. Je vous suggère de vérifier les réglages de proxy de votre appareil et de votre navigateur pour éliminer cette cause.

Problèmes de DNS

Une erreur 504 Gateway Timeout peut également être causée par des problèmes de DNS du côté serveur ou du côté client (ou des deux).

La raison la plus probable d’un problème de DNS côté serveur est que le FQDN (nom de domaine pleinement qualifié) ne se résout pas à l’adresse IP correcte ou le serveur DNS ne répond pas. Cela se produit généralement lorsque vous venez de migrer votre site WordPress vers un nouveau serveur ou hébergeur. Il est donc important d’attendre que les enregistrements DNS du domaine se propagent complètement, ce qui peut prendre jusqu’à 24 heures.

Vous pouvez utiliser des outils gratuits comme whatsmydns.net DNS Checker ou DNSMap pour voir si votre DNS est propagé dans le monde entier.

Vérification de la propagation du DNS pour votre domaine sur whatsmydns.net

Vérification de la propagation du DNS pour votre domaine sur whatsmydns.net

Pour résoudre les problèmes de DNS côté client, vous pouvez essayer de vider votre cache DNS local. C’est comme si vous vidiez le cache de votre navigateur, sauf qu’ici, vous videz le cache DNS du système d’exploitation.

Si vous utilisez Windows, vous pouvez vider le cache DNS en ouvrant l’invite de commande et en saisissant la directive suivante :

ipconfig /flushdns
Vider le cache DNS à l'aide de l'invite de commande sous Windows

Vider le cache DNS à l’aide de l’invite de commande sous Windows

Vous devriez voir un message « Successfully flushed the DNS resolver Cache. » si cela a fonctionné.

Pour les dernières versions de macOS, vous pouvez ouvrir le terminal et saisir la commande suivante :

sudo killall -HUP mDNSResponder

Vous ne verrez aucune notification dans macOS lorsque le processus se terminera, mais vous pouvez changer cela en ajoutant la commande avec votre message personnalisé.

sudo killall -HUP mDNSResponder; Le cache DNS a bien été vidé

Si vous utilisez d’anciennes versions de macOS, la commande que vous devez saisir varie en fonction de la version de macOS que vous utilisez. Pour plus de détails, vous pouvez vous référer à la section macOS dans le tutoriel approfondi de Kinsta sur les DNS.

Si vous utilisez le système d’exploitation Linux, alors le processus est assez similaire à celui de macOS car Linux utilise aussi le terminal comme interface de ligne de commande. Comme il existe de nombreuses distributions de Linux, la commande exacte que vous devez exécuter peut varier d’une distribution à l’autre. Vous pouvez consulter le guide de Kinsta pour plus d’informations.

Enfin, vous pouvez modifier temporairement vos serveurs DNS côté client. Par défaut, votre FAI vous attribue automatiquement les serveurs DNS. Mais vous pouvez les transformer temporairement en IP DNS publiques.

Parmi les plus fiables, vous pouvez essayer Google Public DNS, Cloudflare 1.1.1.1, Quad9 DNS et Cisco OpenDNS.

Réglages personnalisés des serveurs DNS sous Windows 10

Réglages personnalisés des serveurs DNS sous Windows 10

Désactivez temporairement le CDN de votre site

Parfois, le problème peut également concerner votre réseau de diffusion de contenu (CDN). Si le serveur d’origine d’un site n’est pas joignable, la plupart des CDN tenteront de servir la page web complète depuis leur cache.

Mais la plupart des CDN n’activent pas cette fonctionnalité par défaut car il est complexe de mettre en cache les ressources dynamiques sur la plupart des sites (par exemple le tableau de bord de l’administration de WordPress).

Définir la règle de la page « Tout mette en cache » dans Cloudflare

Définir la règle de la page « Tout mette en cache » dans Cloudflare

Un moyen simple de résoudre ce problème est de désactiver temporairement votre CDN. Par exemple, si vous utilisez l’extension gratuite CDN Enabler WordPress pour lier les ressources de votre site aux URL du CDN, vous pouvez alors désactiver l’extension et tester le rechargement de votre site.

Il en va de même pour l’utilisation de toute autre extension que vous pourriez utiliser pour vous connecter à votre CDN (par exemple WP Rocket, Breeze, W3 Total Cache).

Si vous ne pouvez pas accéder au tableau de bord de l’administration de votre site, vous pouvez désactiver l’extension via SFTP en renommant le nom du répertoire de l’extension.

Désactiver toutes les extensions via SFTP en renommant le nom du dossier des extensions

Désactiver toutes les extensions via SFTP en renommant le nom du dossier des extensions

Les CDN comme Cloudflare ou Sucuri, qui fournissent des services de proxy complets, disposent de pare-feu supplémentaires entre leurs serveurs de périphérie et votre serveur d’origine. Par conséquent, vous pouvez rencontrer des erreurs HTTP 5xx plus fréquemment lors de leur utilisation. La plupart d’entre elles mettent en cache les erreurs 5xx renvoyées par votre serveur d’origine, il est donc facile de les dépanner.

Le plan gratuit de Cloudflare est susceptible de générer une erreur 5xx. Malheureusement, comme il s’agit d’un service de proxy complet, il n’y a pas de moyen rapide de le désactiver. Mais avant de blâmer Cloudflare pour cela, sachez que Cloudflare affiche deux variations de l’erreur 504 Gateway Timeout.

504 Gateway Timeout Cloudflare (variation 1)

Cloudflare vous affichera un écran d’erreur personnalisé de 504 Gateway Timeout lorsque le serveur d’origine de votre site répond avec une réponse HTTP 504 standard.

L'écran personnalisé d’erreur 504 de Cloudflare

L’écran personnalisé d’erreur 504 de Cloudflare

Ici, le problème se situe au niveau de votre serveur web et non de Cloudflare. Vous pouvez essayer de le résoudre avec les autres solutions mentionnées ci-dessous ou contacter le support de votre hébergeur pour obtenir une aide technique.

504 Gateway Timeout Cloudflare (variation 2)

Si Cloudflare provoque l’erreur 504 Gateway Timeout, l’écran d’erreur mentionnera « Cloudflare », qui est actuellement le nom de serveur standard pour toutes les ressources Cloudflare. Habituellement, l’écran d’erreur apparaîtra comme ci-dessous :

Écran d'erreur 504 Gateway Timeout causée par Cloudflare

Écran d’erreur 504 Gateway Timeout causée par Cloudflare

Comme Cloudflare lui-même ne réagit pas, vous ne verrez pas d’écran d’erreur de Cloudflare ici.

Il est fort probable que Cloudflare soit déjà conscient du problème et travaille déjà à sa résolution. Vous pouvez le confirmer en consultant la page web sur l’état du système Cloudflare. Vous pouvez également contacter le support Cloudflare pour une résolution plus rapide du problème.

Vérifiez l'état du système Cloudflare sur cloudflarestatus.com

Vérifiez l’état du système Cloudflare sur cloudflarestatus.com

504 Gateway Timeout Cloudflare en raison d’importants téléversements

La taille de vos téléversements sur votre site peut également être une raison de l’arrêt du serveur. Cloudflare limite la taille des fichiers téléversés (par requête HTTP POST) à seulement 100 Mo, que ce soit pour les plans Free ou Pro.

Limites de « taille maximale de téléversement » de Cloudflare pour différents plans

Limites de « taille maximale de téléversement » de Cloudflare pour différents plans

Le problème peut être du côté de votre hébergeur ou de Cloudflare. Vous pouvez en trouver la cause exacte en contournant Cloudflare avec votre fichier hosts DNS et en essayant à nouveau votre téléversement.

Si vous utilisez Cloudflare avec WordPress, je vous recommande d’utiliser leur extension gratuite et d’exclure les URLs critiques de la mise en cache (comme le tableau de bord de l’administration de WordPress). Vous pouvez vous référer à l’article détaillé de Kinsta sur la façon de configurer les réglages de Cloudflare pour WordPress.

Lecture suggérée : Comment mettre en place l’APO Cloudflare pour WordPress.

Problèmes de serveur (vérifiez auprès de votre hébergeur)

Les problèmes de serveur sont l’une des raisons les plus courantes pour lesquelles on est confronté à une erreur 504 Gateway Timeout. Comme la plupart des sites WordPress sont hébergés sur des serveurs web Nginx ou Apache, cela signifie que Nginx ou Apache attend une réponse de quelque chose et que le délai d’attente est dépassé.

De nombreux clients viennent chez Kinsta précisément pour ce problème auquel ils sont confrontés chez d’autres hébergeurs WordPress. Voici comment se déroule la conversation :

Nous recevons environ 100.000 visiteurs par mois avec plus de 200.000 vues. Actuellement, nous sommes hébergés par ____ et nous avons constamment des erreurs 504 dues à la surcharge du serveur. Je n’aime pas la façon dont ____ a géré le problème, et on nous a également informés que nous devrons bientôt passer à leurs plans dédiés, ce qui n’est pas nécessaire selon moi.

Les sites à fort trafic et les sites eCommerce sont plus susceptibles d’obtenir des erreurs 504 en raison de la surcharge des serveurs, car ils génèrent beaucoup de requêtes non cachables. Cependant, ce problème peut surgir sur n’importe quel site, y compris les simples blogs. De nombreux hébergeurs vous demanderont de passer à un plan de haut niveau pour résoudre le problème, ce qui, dans la plupart des cas, est inutile.

Kinsta utilise des hôtes gérés par LXD et des conteneurs de logiciels LXC orchestrés pour chaque site. Ainsi, chaque site WordPress est hébergé dans son propre conteneur isolé avec accès à tous les logiciels nécessaires à son fonctionnement (Linux, Nginx, PHP, MySQL). Les ressources sont 100 % privées et ne sont partagées avec aucun autre site, même pas avec vos sites.

La plupart des hébergeurs WordPress proposant des plans d’hébergement partagé n’ont pas cette capacité. Par conséquent, un site à fort trafic hébergé sur le même serveur que le vôtre peut également provoquer une erreur 504.

En plus d’isoler chaque site dans son conteneur, Kinsta a également conçu son infrastructure pour gérer facilement des milliers de connexions simultanées. Kinsta héberge même les bases de données MySQL sur localhost, et non sur un serveur distant. Cela signifie qu’il n’y a pas de latence entre les machines, ce qui permet d’accélérer les requêtes et de réduire les risques de dépassement de délais.

De nombreux clients qui migrent vers Kinsta constatent une diminution considérable des temps de chargement globaux.

Une augmentation de 212,5% des performances après le passage sur C2.

Une augmentation de 212,5 % des performances après le passage sur C2.

Un serveur surchargé n’est pas la seule cause d’un dépassement de délai. Il peut y avoir de nombreuses autres raisons à l’erreur 504 :

Infrastructure de serveur lente

Le serveur que vous utilisez pour héberger votre site WordPress peut ne pas avoir suffisamment de ressources pour supporter la charge. C’est comme jouer à un jeu vidéo moderne à forte intensité graphique sur un PC vieux de dix ans.

Le serveur raccroche juste en essayant de servir le site web. La seule solution à ce problème est de passer à un serveur doté d’une meilleure infrastructure. Pour cette raison, même le plan d’hébergement WordPress le plus basique de Kinsta peut gérer un site statique avec un trafic moyen.

Besoin de plus de workers PHP

Les workers PHP sont utilisés pour exécuter le code sur votre site WordPress. Un site eCommerce qui reçoit 50.000 visiteurs par mois a besoin de beaucoup plus de ressources qu’un simple blog avec le même volume de trafic. Si tous les workers PHP du serveur sont occupés, ils forment une file d’attente.

Lorsque la file d’attente devient trop importante, le serveur ne tient pas compte des anciennes requêtes, ce qui peut entraîner une erreur 504 Gateway Timeout. Vous pouvez demander à votre hébergeur d’augmenter le nombre de workers PHP. Cela permettra à votre site d’exécuter plusieurs requêtes simultanément.

Problèmes de pare-feu

Le pare-feu de votre serveur peut présenter des erreurs ou une configuration incorrecte. Peut-être que certaines de ses règles empêchent le serveur d’établir correctement une connexion. Pour savoir si votre pare-feu est coupable, vous pouvez consulter les journaux d’erreurs de votre serveur.

Problèmes de connectivité de réseau

Les problèmes de connectivité entre le serveur proxy et le serveur web peuvent entraîner des délais dans la réponse aux requêtes HTTP. Si vous utilisez un équilibreur de charge, il pourrait également y avoir des problèmes de connectivité réseau.

Délais HTTP

Des délais HTTP peuvent se produire lorsqu’une connexion entre le serveur web et le client est maintenue ouverte trop longtemps. Dans le cas des sites WordPress, cela se produit généralement lors de l’exécution d’importations WordPress. Une façon de résoudre ce problème est de passer à une connexion internet plus rapide.

Vous pouvez également utiliser un outil prenant en charge WP-CLI pour exécuter les scripts directement sur le serveur, en contournant entièrement la connexion HTTP. Par exemple, vous pouvez utiliser la commande wp import WP-CLI pour lancer l’extension WordPress Importer directement via l’interface de ligne de commande.

Important : les erreurs 504 Gateway Timeout ressemblent aux erreurs 503 Service Unavailable ou 502 Bad Gateway. Mais elles sont toutes différentes. Si vous rencontrez une erreur 504 chez Kinsta, ouvrez un ticket de support pour que votre problème soit résolu immédiatement.

Pour surveiller vous-même les temps d’arrêt de votre site, vous pouvez utiliser un outil comme updown.io. Il vérifiera périodiquement l’état de votre site (ou toute autre URL) en lui envoyant une requête HTTP. Vous pouvez régler la fréquence de vérification de 15 secondes à 1 heure. Si votre site web ne répond pas correctement, il vous en informera par un e-mail ou un SMS.

Surveillez facilement votre site web avec updown.io

Surveillez facilement votre site web avec updown.io

Vous obtiendrez une quantité généreuse de crédits gratuits avec chaque compte de updown.io, mais si vous recherchez des alternatives moins coûteuses, vous pouvez consulter WebGazer ou UptimeRobot. Ces deux outils vous aideront à surveiller le temps de fonctionnement de votre site toutes les 5 minutes, gratuitement. C’est suffisant pour la plupart des propriétaires de sites web.

Tableau de bord de l'outil de surveillance de site web WebGazer

Tableau de bord de l’outil de surveillance de site web WebGazer

La surveillance de votre site web vous donnera une idée de la fréquence de ses interruptions. Cela est particulièrement utile si vous utilisez un fournisseur d’hébergement partagé. La plupart des hébergeurs WordPress infogérés s’en chargent automatiquement pour vous, c’est pourquoi il est toujours recommandé de les préférer.

Pour une explication détaillée, consultez l’article de Kinsta sur l’importance de l’hébergement infogéré de WordPress.

Spam, Bots, ou attaques DDoS

Les attaquants malveillants peuvent faire s’écrouler votre serveur web en envoyant trop de requêtes ou en envoyant des requêtes gourmandes en ressources. Si votre site est spammé par des bots ou subit une attaque DDoS, cela peut submerger votre serveur et entraîner des erreurs 504 Gateway Timeout pour de nombreux utilisateurs authentiques.

Vous pouvez examiner le trafic de votre serveur et les analyses pour voir si vous pouvez repérer des modèles irréguliers dans le trafic du site. Si vous utilisez Kinsta pour héberger votre site, vous pouvez facilement consulter ces données en vous rendant sur votre tableau de bord MyKinsta Analytics.

Tableau de bord MyKinsta Analytics

Tableau de bord MyKinsta Analytics

Commencez votre enquête en examinant les IP des principaux clients. Cela vous donnera une idée de qui génère le plus grand nombre de requêtes, et d’où elles proviennent. Si votre serveur utilise soudainement une énorme bande passante ou attire beaucoup de trafic, ce rapport vous sera très utile.

Voir les « IP des meilleurs clients » dans le tableau de bord de MyKinsta

Voir les « IP des meilleurs clients » dans le tableau de bord de MyKinsta

Ensuite, vous pouvez consulter le rapport d’analyse du cache. Vous pouvez y voir combien de requêtes contournent ou manquent le cache, ou sont servies depuis le cache. Pour des raisons de performances et de stabilité, vous souhaitez mettre en cache le plus grand nombre de requêtes possible, mais il n’est pas toujours possible d’y parvenir.

Par exemple, les sites WooCommerce génèrent de nombreuses requêtes non cachables pour des fonctionnalités telles que le panier d’achat et le processus de paiement.

L'écran « Analyse du cache » dans MyKinsta

L’écran « Analyse du cache » dans MyKinsta

Enfin, vous pouvez utiliser une extension WordPress de sécurité pour renforcer la sécurité de votre site web en repérant et en bloquant les trafics/IP inquiétants. Vous pouvez également demander à votre hébergeur de bloquer certaines IP.

Selon la durée et l’ampleur de l’attaque, il pourrait s’agir d’un processus sans fin de mise sur liste de blocage des IP, car de nombreux attaquants changent leurs IP et leurs adresses proxy après avoir été bloqués.

Note : Kinsta ne permet pas à ses clients d’installer des extensions WordPress de sécurité car elles peuvent avoir un effet énorme sur les performances du site, en particulier sur ses capacités d’analyse. Comme Kinsta utilise des équilibreurs de charge avec Google Cloud Platform, le blocage des IP ne fonctionnerait pas toujours comme prévu.

Vous pouvez utiliser des solutions de sécurité dédiées telles que Cloudflare ou Sucuri pour protéger vos sites contre les attaques DDoS et les robots de spam. Pour en savoir plus, vous pouvez consulter les articles de Kinsta sur la façon d’installer Cloudflare sur votre site WordPress et sur la façon dont Sucuri a contribué à stopper une attaque DDoS.

Base de données WordPress corrompue

Parfois, une erreur 504 Gateway Timeout peut être due à une base de données corrompue, en particulier sur les sites WordPress. Généralement, cela est dû à des tables ou des fichiers de base de données corrompus. Parfois, elle peut également être causée par un problème de sécurité grave, comme le piratage de votre site ou de votre base de données.

La réparation d’une base de données WordPress corrompue dépend du problème. Des extensions comme WP-DBManager permettent de diagnostiquer facilement les problèmes de base de données et de les réparer. Je vous recommande de lire la présentation détaillée de Kinsta sur la réparation des problèmes de base de données WordPress pour commencer.

Vérifiez les extensions et les thèmes de votre site

Dans la plupart des cas, les extensions et les thèmes tiers ne provoquent pas d’erreurs 504. Mais il y a une petite chance qu’ils provoquent des dépassements de délai du serveur, généralement en mettant en file d’attente un grand nombre de requêtes non mises en cache générées par l’extension ou le thème. Comme cela mobilise une grande partie des workers PHP de votre serveur, cela peut provoquer des erreurs 504.

Un bon exemple de ce problème est WooCommerce, qui est une extension installée pour ajouter une fonctionnalité eCommerce aux sites WordPress.

La façon la plus simple de résoudre ce problème est de désactiver toutes vos extensions. N’oubliez pas que vous ne perdrez aucune donnée si vous désactivez simplement une extension.

Si vous pouvez accéder à votre tableau de bord d’administration, vous pouvez aller à l’écran Extensions, sélectionner Désactiver dans le menu des actions groupées, cocher toutes les extensions, puis cliquer sur le bouton Appliquer. Cela désactivera toutes vos extensions.

Désactivation de toutes les extensions WordPress via le tableau de bord d'administration de WP

Désactivation de toutes les extensions WordPress via le tableau de bord d’administration de WP

Si vous ne pouvez pas accéder à votre zone d’administration, vous pouvez alors désactiver les extensions via SFTP en utilisant la méthode décrite précédemment. Il suffit de renommer le nom du répertoire principal des extensions pour désactiver toutes les extensions.

Une fois que vous avez désactivé toutes les extensions, vérifiez si votre site se charge correctement. Si cela fonctionne, vous devez alors activer chaque extension une par une, en testant le site après avoir activé chaque extension.

Enfin, assurez-vous que vos extensions, vos thèmes et le noyau de WordPress sont à jour. Assurez-vous également que votre serveur fonctionne avec la version recommandée de PHP.

Si vous pensez que cela vous dépasse, vous pouvez toujours demander de l’aide à votre hébergeur. Kinsta utilise New Relic et d’autres techniques de dépannage pour aider les clients à réduire le nombre d’extensions, requêtes ou scripts susceptibles de causer l’erreur.

Dans le pire des cas, comme une requête inefficace ou un mauvais code dans une extension ou un thème, vous pouvez faire appel à un développeur WordPress pour régler le problème.

Vérifier les journaux d’erreurs

La lecture des journaux d’erreurs peut être très utile lors du dépannage et du débogage des erreurs 504 sur votre site WordPress. Cela peut vous aider à réduire rapidement le nombre de problèmes sur votre site, en particulier s’ils résultent d’une extension exigeante sur votre site.

Si vous êtes un client de Kinsta, vous pouvez facilement voir les erreurs dans la visionneuse de journaux de votre tableau de bord MyKinsta.

Vérification des journaux d'erreurs dans le tableau de bord MyKinsta

Vérification des journaux d’erreurs dans le tableau de bord MyKinsta

Si votre hébergeur ne dispose pas d’un outil de journalisation, vous pouvez activer le mode de débogage de WordPress en ajoutant le code suivant à votre fichier wp-config.php :

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

La constante WP_DEBUG active ou désactive le mode de débogage de WordPress. Elle a deux constantes optionnelles qui peuvent étendre ses fonctionnalités. La constante WP_DEBUG_LOG indique que toutes les erreurs doivent être enregistrées dans un fichier debug.log dans le répertoire /wp-content/. Si vous ne voyez pas ce fichier, vous pouvez toujours en créer un.

La constante WP_DEBUG_DISPLAY contrôle si les journaux de débogage apparaissent dans la page HTML. Si vous réglez cette constante sur false, toutes les erreurs seront masquées, mais vous pourrez les vérifier plus tard, car vous avez également défini WP_DEBUG_LOG comme true.

Important : si vous avez activé WP_DEBUG dans l’environnement Kinsta, il acheminera toutes les erreurs vers le fichier debug.log et non vers le fichier error.log du tableau de bord MyKinsta.

Vous pouvez également télécharger les fichiers bruts du journal d’erreurs de WordPress via SFTP. En général, vous pouvez trouver les journaux d’erreurs dans le répertoire racine de votre serveur dans un dossier nommé « logs »

Accès au répertoire des journaux d'erreurs de WordPress via SFTP

Accès au répertoire des journaux d’erreurs de WordPress via SFTP

Les utilisateurs de Kinsta peuvent également activer le mode de débogage de WordPress à partir de leur tableau de bord MyKinsta. Pour ce faire, naviguez vers Sites > Outils > Débogage de WordPress et cliquez sur le bouton Activer. Cela vous permettra de voir les erreurs et les notices de PHP sans avoir à activer le mode de débogage via SSH ou SFTP.

Enfin, vous pouvez consulter les fichiers journaux du serveur. Selon le serveur que vous utilisez pour héberger votre site WordPress, ils se trouvent généralement à ces endroits :

Vous pouvez vous référer à la documentation relative à la journalisation d’Apache ou de Nginx pour plus d’informations.

Configurer correctement les réglages Apache ou Nginx

Vous pouvez modifier les fichiers de configuration de votre serveur afin d’augmenter les limites de ressources pour des directives spécifiques. Cela peut vous aider à résoudre l’erreur 504 Gateway Timeout.

Pour les serveurs web Apache

Tout d’abord, ajoutez le code suivant dans votre httpd.conf :

TimeOut 600

Ce réglage définit le temps d’attente du serveur pour certaines requêtes avant de les marquer comme un problème de dépassement de délai du réseau. Sa valeur par défaut est de 60 secondes (version Apache 2.4).

Vous ne pouvez ajouter cette directive que dans votre fichier httpd.conf, et non dans votre fichier .htaccess. Comme la plupart des fournisseurs d’hébergement partagé ne vous permettent pas de modifier le fichier httpd.conf, vous pouvez essayer à la place d’augmenter la valeur de la directive LimitRequestBody dans votre fichier .htaccess.

Ajoutez ensuite la ligne suivante à votre fichier php.ini :

max_execution_time 300

La valeur par défaut de la directive max_execution_time de PHP est de 30 secondes. En l’augmentant, les scripts PHP de votre site pourront s’exécuter plus longtemps.

Pour les serveurs web Nginx

Si vous utilisez vos sites WordPress sur Nginx + FastCGI Process Manager (PHP-FPM) ou si vous utilisez Nginx comme proxy inverse pour Apache, vous pouvez modifier les réglages du serveur pour éviter les erreurs 504 Gateway Timeout.

Erreur 504 Gateway Timeout sur Nginx + FastCGI (PHP-FPM)

Tout d’abord, vous devez modifier le fichier de configuration de PHP-FPM. Vous le trouverez à l’emplacement /etc/php7.4/fpm/pool.d/www.conf sur votre serveur Nginx (le chemin exact peut varier en fonction de la version de PHP). Vous pouvez également exécuter la commande suivante dans votre terminal pour modifier le fichier de configuration du pool PHP-FPM :

sudo nano /etc/php/7.2/fpm/pool.d/www.conf

Ensuite, définissez la directive suivante :

request_terminate_timeout = 300

Ensuite, vous devez modifier votre fichier php.ini. Vous pouvez le trouver à l’adresse /etc/php.ini. Ouvrez le fichier et ajoutez/modifiez la valeur de la directive max_execution_time à 300 secondes.

max_execution_time = 300

Enfin, ajoutez le code suivant au bloc de localisation de votre fichier nginx.conf :

location ~ .php$ {
...
fastcgi_read_timeout 300;
}

Rechargez Nginx et PHP-FPM pour que les changements prennent effet.

sudo service nginx reload
sudo service php7.4-fpm reload

Le code exact pour recharger PHP-FPM varie en fonction de la version de PHP installée sur votre serveur. Testez votre site pour voir si cela a réglé le problème.

Erreur 504 Gateway Timeout sur le proxy Nginx

Si vous utilisez Nginx comme serveur proxy inverse pour Apache, vous pouvez le rendre plus souple en ce qui concerne les délais d’attente du serveur en ajoutant les directives suivantes à votre fichier nginx.conf :

proxy_connect_timeout 600;
proxy_send_timeout 600;
proxy_read_timeout 600;
send_timeout 600;

N’oubliez pas de recharger Nginx après avoir effectué vos modifications.

sudo service nginx reload

Autres erreurs HTTP comme 504 Gateway Timeout

Comme mentionné précédemment dans l’article, il existe de nombreuses autres erreurs HTTP 5xx qui sont exactement comme l’erreur 504 Gateway Timeout. C’est parce qu’elles se produisent toutes du côté du serveur. Ces erreurs sont les suivantes :

D’autres erreurs HTTP causées par des problèmes côté client, comme l’erreur 404 Non Trouvé, sont également comme l’erreur 504. Vous pouvez vous référer au guide détaille de Kinsta et à la liste des codes d’état HTTP pour plus d’informations.

Lorsque vous ne savez pas ce qui a causé une erreur 504 Gateway Timeout, comment la corriger à temps pour empêcher les visiteurs durement gagnés de partir sur des sites concurrents ? 🤷‍♂️ Tous les détails sont dans cet article. ⬆️Click to Tweet

Résumé

Votre site WordPress peut être affecté par l’erreur 504 Gateway Timeout pour de multiples raisons. Dans cet article, vous avez appris à toutes les résoudre. Généralement, ces erreurs sont dues à des problèmes de serveur, auquel cas vous pouvez contacter votre hébergeur et obtenir une solution rapide.

Cependant, vous devez également comprendre que cette erreur peut être causée par des extensions, des thèmes, des services tiers, des requêtes de base de données inefficaces ou une combinaison de deux ou plus de ces éléments. Si vous utilisez au maximum les ressources de votre serveur (par exemple, les workers PHP), il est recommandé d’optimiser votre site pour en améliorer les performances.

Si vous constatez que votre site web est toujours en panne, il se peut très bien que vous deviez mettre à niveau votre plan d’hébergement ou le nombre de workers PHP. Je vous recommande de n’envisager cette option qu’après avoir épuisé toutes les autres solutions décrites dans cet article.

Des simples sites statiques aux sites complexes de eCommerce et d’adhésion, les plans d’hébergement évolutifs de Kinsta sont conçus pour s’adapter à tous les types de sites web. Pour en savoir plus sur notre hébergement cloud évolutif, consultez cet article !

Avons-nous manqué quelque chose ? Si vous avez encore des difficultés à corriger l’erreur 504 Gateway Timeout sur votre site WordPress, laissez un commentaire ci-dessous.


Économisez du temps et de l’argent et optimisez les performances de votre site avec :

  • Aide instantanée des experts en hébergement WordPress, 24/7.
  • Intégration de Cloudflare Enterprise.
  • Une audience mondiale avec 28 centres de données dans le monde entier.
  • Optimisation avec notre surveillance intégrée de performance d’applications (APM).

Tout cela et bien plus encore, dans un seul plan sans contrat à long terme, avec des migrations assistées et une garantie de remboursement de 30 jours. Pour trouver le plan qui vous convient, Découvrez nos plans ou contactez nous.