Erreur 504 gateway timeout et résolution

Vous cliquez sur une page. Le navigateur charge, charge… puis abandonne. Et là, au lieu du contenu attendu, vous tombez sur un message d’erreur : 504 gateway timeout.

Ce code http a un talent particulier : il arrive souvent au pire moment (page de paiement, formulaire, back-office), pile quand vos utilisateurs sont prêts à agir.

Résultat : une page web qui ne répond pas, un site web qui perd des conversions, et un problème qui ressemble à “une simple lenteur”… jusqu’au jour où ça devient une panne.

Ici, on va faire simple et utile : comprendre l’erreur 504 gateway timeout, identifier les causes courantes, puis voir comment résoudre l’erreur sans jouer à “modifier vos paramètres” au hasard. Et si vous n’avez pas envie de passer votre soirée dans les journaux du serveur, n'hésitez pas à faire appel à SiteBug !

Erreur 504 : c’est quoi exactement ?

Une erreur 504 gateway timeout signifie qu’une passerelle (gateway) ou un serveur proxy n’a pas reçu la réponse attendue du serveur dans le temps imparti.

En clair : une requête http arrive, elle est transmise à un système en amont (votre serveur web, votre application PHP, parfois un autre service), mais la réponse n’arrive pas assez vite. La passerelle coupe l’attente et renvoie un message d’erreur.

C’est important, parce que ce “délai” ne dépend pas uniquement de votre site. Il dépend aussi de la configuration de la chaîne entre l’utilisateur et votre serveur : CDN, proxy, pare-feu, DNS, hébergement, communication réseau… Tout ce petit monde a ses propres timeouts. Et quand l’un d’eux dit “stop”, vous voyez apparaître le fameux http 504.

Pourquoi l’erreur 504 fait si mal, même si “ça revient tout seul” ?

Parce que pour les utilisateurs, ce n’est pas un incident technique. C’est un site qui ne marche pas. Et quand un site ne marche pas, on ne discute pas : on part. 

Dans un cas e-commerce, la page de panier ou de paiement qui renvoie une erreur http 504 fait perdre du chiffre d’affaires immédiatement. Dans un cas B2B, un formulaire qui mouline finit en abandon. Dans un back-office, une action qui échoue peut bloquer la gestion.

Côté SEO, une erreur 504 répétée peut aussi devenir un signal de qualité dégradée : pages qui répondent mal, temps de réponse instable, ressources indisponibles. Ce n’est pas “la sanction instantanée”, mais c’est un risque, surtout si l’incident dure ou revient régulièrement.

Pour replacer la 504 dans la famille des erreurs 5XX, vous pouvez lire le guide concernant la cause et les impacts que peuvent avoir les erreurs de type 5XX.

Les causes courantes d’une erreur 504 gateway timeout

Une erreur 504 se produit quand “quelque chose” prend trop de temps. La vraie question est : quoi, exactement ? La plupart du temps, la cause est dans l’un de ces blocs : serveur, application, proxy/CDN, réseau/DNS, ou pare-feu. Parfois c’est un seul problème. Souvent, c’est une combinaison.

1) Serveur saturé : quand les ressources ne suivent plus

Le scénario classique : votre serveur web manque de ressources. CPU à fond, RAM trop juste, disque qui rame, limites d’hébergement atteintes… Le temps de réponse augmente. La passerelle attend. Puis le délai est dépassé. 504.

Cela arrive plus souvent qu’on ne le croit sur des hébergements mutualisés, ou quand un site grossit sans ajustement. Et cela peut être aggravé par un trafic inhabituel : campagne marketing, pic de visiteurs, bots agressifs, ou attaque DDoS. Dans ce cas, vous pouvez voir une attente qui s’allonge, puis une cascade d’erreurs 5XX.

2) Application lente : PHP, scripts, base de données, appels externes

Ici, le serveur n’est pas forcément “mort”. Il travaille, mais trop lentement. Sur WordPress, un plugin, un thème, ou un conflit peut déclencher un traitement lourd. Sur un site sur mesure en PHP, un script peut bloquer une requête trop longtemps. Et si la base de données répond lentement (requêtes non optimisées, index manquants, tables lourdes), la page web dépasse vite le délai.

Autre cas très fréquent : l’appel à un service externe. Par exemple un paiement, un CRM, une API d’envoi d’e-mails, un outil tiers. Si ce service met du temps, votre serveur attend. La passerelle, elle, ne vous attend pas indéfiniment.

3) Proxy, CDN, passerelle : un timeout trop court (ou incohérent)

Un serveur proxy et un CDN sont souvent là pour accélérer, sécuriser et absorber le trafic. Mais ils introduisent aussi une couche de configuration. 

Si le timeout proxy est trop bas, une page un peu lente peut se transformer en panne visible. Vous pouvez alors avoir un site “globalement ok”, mais des erreurs 504 sur certains cas précis : recherche, filtres, génération de fichier, export, publication, sauvegarde.

Et parfois, la configuration est incohérente : le proxy attend 30 secondes, PHP autorise 60 secondes, la base de données met 45 secondes. Résultat : le proxy coupe à 30, même si le serveur aurait fini à 45. Vous avez un 504, alors qu’en interne “ça aurait pu passer”.

4) Réseau, DNS, communication : le problème n’est pas sur votre code

Une erreur 504 peut aussi venir d’un problème de réseau entre systèmes : latence, instabilité, route dégradée, incident chez le fournisseur d’accès, DNS lent, souci côté hébergeur. Dans ces cas-là, les symptômes sont souvent intermittents : certains utilisateurs sont touchés, d’autres non ; certaines heures sont pires ; le problème “revient” puis “disparaît”.

C’est typiquement le genre de situation où corriger cette l’erreur 504 demande des preuves : heures exactes, message d’erreur, logs, IP, et parfois l’aide du fournisseur ou de l’hébergeur.

5) Pare-feu et sécurité : protection qui ralentit trop

Un pare-feu (ou WAF) peut ajouter une inspection qui ralentit certaines requêtes, ou bloquer partiellement des flux. Parfois, ce n’est pas un blocage net, mais un ralentissement : la communication se dégrade, le délai est dépassé, et le proxy renvoie un http 504. Cela peut être accentué par des règles anti-bots, des limitations géographiques, ou une protection DDoS trop agressive.

Diagnostic : comment trouver la vraie cause, sans y passer la nuit

La méthode la plus fiable consiste à répondre à une question simple : qui renvoie le 504, et qu’est-ce qui attend quoi ?

D’abord, observez le message d’erreur. Est-ce une page “marquée” CDN ? Est-ce un écran de l’hébergeur ? Est-ce le serveur proxy ? Ou un message brut de votre serveur web ? Ce détail vous dit où se situe la passerelle.

Ensuite, identifiez le cas. Est-ce toujours la même page ? Toujours la même action ? Toujours après un temps similaire ? Un délai constant (30 secondes, 60 secondes) ressemble souvent à un timeout de configuration. Un délai très variable ressemble plus à une saturation de ressources ou à un réseau instable.

Puis, passez aux journaux. Oui, c’est moins glamour, mais c’est là que le problème se dévoile. Vérifiez les journaux côté serveur web, côté PHP, et si possible côté proxy/CDN. Cherchez des indices : requêtes qui prennent trop de temps, erreurs de communication, files d’attente, saturation.

Si vous voyez des requêtes lentes récurrentes, vous tenez une piste solide. Si vous voyez des timeouts côté proxy, vous tenez une autre piste.

Enfin, testez intelligemment. Un test depuis un autre réseau, ou un outil externe, permet de confirmer que ce n’est pas “juste votre navigateur”. 

Et si vous avez un CDN, testez temporairement sans (si c’est possible) pour isoler l’origine. Idem si vous êtes derrière un serveur proxy interne : l’idée est de réduire le périmètre jusqu’à trouver l’étage fautif.

Vous m’envoyez le contexte, je vérifie les journaux, la configuration, les paramètres du serveur, et je vous donne une solution applicable, avec la cause réelle (pas une rustine).

Résoudre l’erreur 504 : les solutions qui fonctionnent vraiment

Résoudre l’erreur 504, c’est jouer sur deux leviers. Le premier est technique : réduire le temps nécessaire pour produire une réponse. Le second est structurel : aligner les timeouts et la configuration des systèmes intermédiaires.

1) Revenir à un serveur stable : ressources, hébergement, gestion

Si votre serveur web est à bout, tout le reste est secondaire. Dans ce cas, on commence par vérifier l’état des ressources, l’impact du trafic, et la capacité réelle de l’hébergement. Un hébergeur peut imposer des limites ; un serveur peut manquer de marge ; un pic de trafic peut tout faire basculer.

La priorité est de réduire la charge inutile (bots, attaques, requêtes répétitives), d’améliorer la gestion des processus, et d’assurer que le serveur peut répondre vite, même sous contrainte.

Quand on corrige ce point, on voit souvent deux améliorations immédiates : les utilisateurs retrouvent un site utilisable, et les erreurs http 504 se raréfient parce que la réponse revient dans les temps.

2) Accélérer l’application : la meilleure “solution” long terme

Si une page met 40 secondes à répondre, augmenter le timeout peut la faire passer… mais vous gardez un problème. L’objectif est que la page réponde en quelques secondes, pas qu’elle finisse “un jour”.

On s’attaque donc à ce qui ralentit : requêtes de base de données, scripts lourds, appels externes, fonctionnalités qui se déclenchent au mauvais endroit. Par exemple, si vous générez un fichier dans une requête utilisateur, vous pouvez basculer ce traitement en tâche asynchrone.

Si un plugin provoque un conflit, on corrige ou on remplace. Si un thème déclenche trop de requêtes, on optimise. Si un service externe est lent, on ajoute un mécanisme de timeout propre côté application, ou on repense le flux.

En général, c’est là que le diagnostic rapporte le plus : une seule requête lente peut être responsable de la majorité des 504.

3) Ajuster les timeouts : nécessaire, mais seulement après compréhension

Oui, il arrive qu’il faille ajuster les paramètres. Mais pas en mode roulette. On aligne le timeout du serveur proxy, le délai côté passerelle, et le comportement du serveur web / PHP. Sinon, vous avez des incohérences : le serveur travaille, mais l’intermédiaire coupe.

L’approche saine consiste à : (1) réduire la lenteur réelle, (2) régler les timeouts à un niveau cohérent avec vos pages “lourdes”, (3) surveiller si cela crée des files d’attente.

Parce que si vous augmentez trop, vous risquez de transformer des lenteurs en engorgement : plus d’attente, plus de connexions ouvertes, plus de ressources consommées. Et là, vous passez du 504 au 503, puis à la panne complète.

Pour comprendre l’autre grande erreur 5XX liée à la surcharge, je vous conseille aussi : https://sitebug.fr/blog/erreur-503-service-unavailable

4) Corriger la couche réseau : DNS, CDN, pare-feu, communication

Quand la cause est réseau, il faut être méthodique. On vérifie la cohérence DNS, la stabilité, les temps de résolution, et la configuration CDN ↔ serveur d’origine. On regarde aussi le pare-feu : règles trop strictes, inspection trop lourde, blocages partiels. 

Et si l’incident dépend d’un fournisseur d’accès ou de l’hébergeur, on remonte un dossier avec des éléments concrets : périodes impactées, messages, logs, et symptômes.

C’est aussi le moment où les “problèmes liés” apparaissent : un petit souci DNS peut ressembler à un 504 ; une route réseau dégradée peut provoquer des timeouts ; un CDN mal réglé peut couper trop tôt. Là encore, le bon réflexe reste le même : identifier où la requête se perd, puis corriger au bon étage.

Le cas typique : “ça marche… sauf quand ça compte”

Beaucoup de sites ont un comportement trompeur : la page d’accueil fonctionne, les pages de contenu aussi, mais dès qu’on fait une action critique (recherche interne, filtres, paiement, génération d’un fichier, publication, import), la réponse devient trop lente. 

Et c’est précisément dans ces cas que vos utilisateurs sont les plus impatients, parce qu’ils ont un objectif. Le problème n’est donc pas seulement technique, il est business : la partie qui rapporte est celle qui tombe.

Dans ce genre de cas, la solution est rarement “une seule ligne magique”. C’est plutôt une correction ciblée : optimisation de la requête, réglage de configuration, parfois ajustement de l’hébergement, et validation par tests.

Je traite l’erreur 504 gateway timeout comme un problème de production : diagnostic, correction, vérification, puis stabilisation.