Erreur 504 Gateway Timeout : de quoi parle-t-on ?
Sur le web d'aujourd'hui, un visiteur ne s'adresse presque jamais directement au serveur qui fabrique la page qu'il demande. Entre les deux s'intercalent des intermédiaires :
- un CDN qui met en cache et protège
- un reverse proxy comme Nginx qui répartit le trafic
- parfois un équilibreur de charge qui distribue les requêtes entre plusieurs serveurs
- l'application et les services dont la page dépend, avec son interpréteur PHP et sa base de données.
Lorsqu'un utilisateur effectue une recherche, chaque maillon reçoit la demande, la transmet au suivant et sert ainsi de passerelle. Et chacun n'accepte d'attendre le maillon d'après que pendant un temps limité. Ce découpage fait la robustesse d'internet, mais il multiplie aussi les points de rupture.
L'erreur 504 Gateway Timeout naît précisément de cette attente. Ce code HTTP signale qu’un serveur intermédiaire, qui joue le rôle de passerelle ou de proxy, a bien transmis la requête au serveur en amont, mais n’a pas reçu de réponse à temps.
Quelles différences avec les erreurs 502 et 503 ?
Les codes 5xx, que tout site finit par rencontrer un jour, désignent tous des erreurs côté serveur, mais ils ne racontent pas la même histoire.
- L'erreur 502 Bad Gateway signale que la passerelle a bien reçu quelque chose, mais quelque chose d'invalide : le serveur en amont a planté, renvoyé des données corrompues ou fermé la connexion brutalement.
- L'erreur 503 Service Unavailable décrit un service temporairement indisponible, souvent de manière assumée (maintenance, surcharge gérée)
- L'erreur 504, elle, traduit une absence de réponse dans le délai imparti.
Les causes d'une erreur 504
Une erreur 504 est un symptôme, jamais une cause. Derrière le même message se cachent des problèmes de natures très différentes, qui appellent des solutions différentes. Cinq familles concentrent l'essentiel des incidents.
Une erreur 504 est un symptôme, jamais une cause. Derrière le même message se cachent des problèmes de natures très différentes, qui appellent des solutions différentes. Cinq familles concentrent l'essentiel des incidents.
Un serveur en amont surchargé
C'est le scénario le plus courant. Un pic de trafic (lancement de campagne, passage télé, soldes, article viral) fait affluer plus de requêtes que le serveur ne peut en traiter. Les processus PHP sont tous occupés, les nouvelles requêtes s'empilent dans une file d'attente, et la passerelle finit par abandonner. La surcharge ne vient d'ailleurs pas toujours de visiteurs réels : des spam bots, des scrapers agressifs ou une attaque par déni de service peuvent épuiser les ressources d'un hébergement modeste en quelques minutes.
Des requêtes trop longues à exécuter
Le serveur peut être parfaitement disponible et pourtant trop lent sur certaines URL. Une requête SQL non indexée sur une table de plusieurs millions de lignes, un script d'import, un export de catalogue, un appel à une API tierce qui ne répond plus : il suffit qu'une seule opération dépasse le délai fixé par le proxy pour déclencher l'erreur. Ces cas sont plus sournois, car le site fonctionne normalement pour la majorité des utilisateurs et ne casse que sur des fonctionnalités précises.
Des problèmes DNS
Le DNS traduit un nom de domaine en adresse IP. Si cette traduction échoue ou renvoie une mauvaise adresse, la passerelle tente de joindre un serveur qui ne répondra jamais. Les problèmes DNS surviennent typiquement après une migration d'hébergement, quand les enregistrements pointent encore vers l'ancienne IP, pendant la propagation d'une modification DNS, ou lorsque le serveur DNS sollicité par le proxy est lui-même lent ou injoignable.
Un réseau, un pare-feu ou un CDN qui bloque
Entre deux serveurs, la communication peut être coupée sans bruit. Un pare-feu qui filtre les IP du CDN, une règle de sécurité excessivement stricte qui bloque les requêtes de la passerelle, un routage réseau défaillant chez l'hébergeur web : la connexion ne s'établit pas, rien ne revient, et le délai expire. Ces erreurs apparaissent souvent après un changement de règles de pare-feu ou l'activation de nouveaux services de protection. Ce sont aussi les problèmes les plus difficiles à diagnostiquer, car les logs applicatifs n'en gardent souvent pas trace.
Un proxy mal configuré
Enfin, la configuration du serveur proxy elle-même peut être en cause. Un délai d'attente trop court au regard de ce que fait réellement l'application, une adresse de backend erronée, un équilibreur qui envoie le trafic vers des serveurs hors service : autant de paramètres qui transforment un traitement simplement long en erreur 504.
Erreur 504 et SEO : quel impact sur Google ?
Une erreur ponctuelle, corrigée en quelques minutes, n'a pratiquement aucun effet sur le référencement d'un site. Le problème commence quand les erreurs 504 se répètent ou s'installent.
Dans ce cas, les conséquences sont multiples :
- URL stratégiques moins souvent explorées
- Nouveaux contenus indexés plus lentement
- Positions fragilisées sur les requêtes les plus concurrentielles.
S'y ajoute un effet moins visible : un visiteur venu des moteurs de recherche qui tombe sur une page d'erreur repart aussitôt, et c'est autant d'acquisition perdue.
Comment corriger une erreur 504 Gateway Timeout ?
Résoudre une erreur 504 suppose de remonter la chaîne, du navigateur jusqu'au moteur, en éliminant les hypothèses une par une. L'ordre compte : commencer par les vérifications rapides évite de toucher à la configuration d'un serveur pour un problème qui venait d'ailleurs.
Étape 1 - Écarter un problème côté visiteur
Avant tout, il faut vérifier que l'erreur n'est pas locale.
- Recharger la page après quelques instants
- Tester depuis un autre navigateur, un autre réseau (une connexion mobile, par exemple) ou un outil de vérification en ligne qui interroge le site depuis plusieurs pays.
Si le site répond normalement ailleurs, la piste d'un réseau d'entreprise filtré, d'un VPN ou d'un cache DNS local devient sérieuse : vider le cache DNS de la machine, ou changer temporairement de résolveur, suffit alors à résoudre le problème. Dans la grande majorité des cas, pourtant, l'erreur touche tous les utilisateurs : le problème se trouve côté serveur.
Étape 2 - Lire les logs du serveur
Les logs sont la source de vérité sur les causes d'un incident. Vérifier les logs : c'est l'étape qui permet de résoudre le plus d'incidents sans tâtonner.
Étape 3 - Vérifier la configuration DNS
Si les erreurs ont commencé après une migration ou un changement de prestataire, le DNS est le premier suspect. Il faut vérifier que les enregistrements A et AAAA du domaine pointent bien vers l'IP actuelle, que le CDN connaît la bonne IP du serveur, et que la propagation DNS est terminée. Une simple correction d'enregistrement suffit alors souvent à résoudre l'incident, le temps que la propagation s'achève.
Étape 4 - Contrôler le CDN et le pare-feu
Mettre temporairement le CDN en pause, ou basculer en mode « DNS only », permet de savoir si l'erreur vient de ce réseau de diffusion ou du serveur lui-même. Si le site répond correctement sans lui, il faut vérifier que les plages d'IP sont bien autorisées par le pare-feu du serveur, et qu'aucune règle de sécurité (WAF, fail2ban, système anti-DDoS de l'hébergement) ne bloque ses requêtes.
Étape 5 - Ajuster les délais du proxy
Lorsque certains traitements longs sont légitimes (exports, génération de rapports, imports de catalogue), le délai d'attente du proxy peut expirer avant la réponse de l'application. Sur Nginx, les directives proxy_read_timeout et fastcgi_read_timeout fixent ce délai, de 60 secondes par défaut ; Apache dispose d'une directive équivalente. La directive max_execution_time, enfin, plafonne la durée d'exécution d'un script. Augmenter ces valeurs reste un contournement, pas un correctif : allonger l'attente masque le problème sans le traiter, et immobilise des ressources serveur plus longtemps.
Étape 6 - Optimiser l'application et les requêtes SQL
Pour corriger durablement les problèmes de lenteur, tout se joue presque toujours côté application, dans le code.
- Indexer les colonnes interrogées par les requêtes lentes
- Mettre en cache les résultats coûteux
- Déplacer les traitements lourds dans des tâches asynchrones plutôt que de les exécuter pendant le chargement demandé par l'utilisateur
- Limiter les appels à des services tiers ou leur imposer leur propre délai
Chaque milliseconde gagnée améliore les performances web et réduit le risque de dépasser le seuil du proxy. Un outil d'APM (New Relic, Datadog, Blackfire) aide à repérer les fonctions qui consomment trop de temps.
Étape 7 - Dimensionner l'hébergement
Si les erreurs surviennent uniquement lors des pics de trafic du site, le problème relève de la surcharge. Dans ce cas, plusieurs actions sont recommandées :
- Augmenter le nombre de workers
- Ajouter des ressources supplémentaires
- Passer d'un hébergement mutualisé à un serveur dédié, à plusieurs serveurs derrière un équilibreur ou à des services cloud capables de monter en charge automatiquement
À savoir : la réponse dépend du budget et de la prévisibilité du trafic. Sur un hébergement mutualisé, contacter le support de l'hébergeur reste souvent le moyen le plus rapide de savoir si les ressources du compte sont plafonnées, et de corriger le tir rapidement.
Erreur 504 sur WordPress : les correctifs spécifiques
WordPress propulse une part considérable du web, et ses spécificités en font un terrain fréquent d'erreurs 504. Le CMS repose sur PHP et MySQL, s'enrichit d'extensions de qualité très variable, et tourne souvent sur des hébergements mutualisés aux capacités limitées. Les problèmes viennent rarement du cœur du CMS lui-même : ils naissent de son écosystème. Pour résoudre une erreur 504 sur WordPress, quatre pistes méritent d'être explorées dans l'ordre.
1. Isoler l'extension ou le thème fautif
Une extension mal codée, une mise à jour qui introduit une requête lente, un thème qui charge du contenu externe à chaque affichage de page : sur un site WordPress, c'est la première hypothèse à tester. La méthode classique consiste à désactiver toutes les extensions, puis à les réactiver une à une jusqu'à voir réapparaître l'erreur.
2. Surveiller WP-Cron et l'API Heartbeat
Deux mécanismes de WordPress génèrent des requêtes en arrière-plan.
- WP-Cron, qui exécute les tâches planifiées au fil des visites, ce qui peut déclencher des traitements lourds au mauvais moment. Le remplacer par une vraie tâche cron système soulage souvent le serveur.
- L'API Heartbeat, qui envoie des requêtes régulières depuis l'administration. Plusieurs onglets ouverts par plusieurs rédacteurs suffisent à multiplier les appels au fichier admin-ajax.
3. Moderniser l'environnement serveur
Passer le serveur à une version récente de PHP, augmenter la mémoire allouée, optimiser et nettoyer la base de données : ces opérations simples permettent de réduire sensiblement les temps de traitement. Activer le journal de débogage de WordPress (WP_DEBUG_LOG) permet enfin de consigner les erreurs dans un fichier dédié.
4. Ajouter du cache
Une extension de cache de page, un cache objet comme Redis ou Memcached et un CDN permettent de réduire drastiquement le nombre de requêtes qui atteignent réellement l'application. Sur un site WordPress à fort trafic, c'est souvent la mesure qui permet de résoudre durablement les erreurs 504 Gateway Timeout lors des pics.
