Erreur 504 Gateway Timeout : que faire ?Le serveur a attendu trop longtemps : trouver ce qui traîne, puis réparer.

1. Notez ce qui déclenche l'erreur : quelle page ou quelle action, et au bout de combien de temps.
2. Ne relancez pas à l'aveugle une importation ou une commande : vérifiez d'abord ce qui a été fait.
3. Lisez le journal des erreurs de l'hébergeur, à l'heure de la panne.
4. Trouvez ce qui est lent avec Query Monitor : requête à la base, extension ou service extérieur.
5. Découpez les importations, et programmez sauvegardes et tâches lourdes la nuit.
6. Allégez le serveur : cache de pages, robots bloqués, base nettoyée.
7. Relevez les délais en dernier, avec l'hébergeur, ou passez à une offre plus puissante.

Dans ce guide

• Les messages de l'erreur 504
• Les causes, de la plus fréquente à la plus rare
• La marche à suivre, dans l'ordre
• Qui perd patience le premier : 504, 524 ou erreur de PHP
• Ce que nous ferions à votre place
• Questions fréquentes

« Gateway » veut dire passerelle : le serveur qui reçoit la visite et la transmet à celui qui fabrique la page, PHP le plus souvent. « Timeout » veut dire délai dépassé. Une 504 dit donc que la passerelle a attendu, puis a renoncé.

• « 504 Gateway Time-out » sur une page sobre, avec le mot nginx en bas : le serveur nginx, qui sert de passerelle chez de nombreux hébergeurs, a attendu PHP trop longtemps.
• « Gateway Timeout », suivi de « The gateway did not receive a timely response from the upstream server or application » : la page d'Apache, quand il relaie la demande à un autre serveur.
• « Cette page ne fonctionne pas » avec HTTP ERROR 504 : la façon dont Chrome et Edge l'affichent quand le serveur n'envoie aucune page avec l'erreur.
• Une page aux couleurs de Cloudflare, code 504, avec votre navigateur et Cloudflare en état de marche et l'hôte en erreur : la 504 vient du serveur de l'hébergeur, Cloudflare ne fait que la montrer. Une page blanche, sans la marque Cloudflare, vient au contraire de Cloudflare lui-même : c'est rare.
• « A timeout occurred », code 524, sur une page de Cloudflare : la cousine de la 504. Cloudflare a bien joint le serveur, mais n'a reçu aucune réponse en 125 secondes.
• Dans l'administration : une importation, une sauvegarde, un export ou un enregistrement qui tourne longtemps, puis s'arrête sur l'une de ces pages.

502 ou 504 ? La 502 dit que la passerelle a reçu une réponse invalide, ou une connexion coupée : PHP s'est arrêté, a planté, ou a été coupé par l'hébergeur parce qu'il dépassait le temps permis. La 504 dit qu'elle n'a rien reçu à temps : PHP travaille encore, mais trop lentement. La première fait chercher un service arrêté (voyez notre guide de l'erreur 502 Bad Gateway), la seconde une page ou une tâche trop longue. Et si le site ne tombe en 504 que chez vous, mais s'ouvre ailleurs, par exemple sur un téléphone en 4G, regardez plutôt votre VPN, le proxy du réseau de l'entreprise ou l'antivirus.

1. Une action trop longue, lancée depuis le navigateur. Une importation de produits ou d'articles, un export de commandes, une sauvegarde faite par une extension, la régénération des miniatures, des statistiques de boutique sur plusieurs années, une lettre d'information envoyée depuis le site. Le serveur attend la fin du travail pour répondre, et le délai expire avant. Signe : l'erreur arrive toujours sur la même action, et au bout du même temps.
2. Une requête trop lente dans la base de données. Une table devenue énorme (les journaux d'une extension de sécurité, de redirection ou d'envoi d'e-mails, les actions planifiées de WooCommerce et leurs traces), des milliers de révisions d'articles, des réglages trop lourds chargés à chaque page, ou une recherche, un filtre de boutique, sur des milliers de produits. Signe : certaines pages seulement, toujours les mêmes, comme la recherche, une catégorie avec filtres ou la liste des commandes.
3. Un service extérieur qui ne répond pas. Une extension qui interroge un autre site pendant que la page se fabrique : avis clients, flux Instagram, taux de change, transporteur, vérification de licence, outil d'envoi de lettres d'information. WordPress limite ces appels à 5 secondes par défaut, mais une extension peut allonger ce délai, et plusieurs appels s'additionnent. Signe : le site ralentit d'un coup sans que rien n'ait changé chez vous, puis revient seul quand le service répond de nouveau.
4. Le serveur saturé. L'offre d'hébergement limite le nombre de pages calculées en même temps. Quand tous les processus de PHP sont occupés, par un pic de visites, des robots ou des rafales de tentatives de connexion, les demandes suivantes attendent leur tour jusqu'à dépasser le délai. Signe : toutes les pages, aux heures chargées, souvent avec des erreurs 503 ou 508.
5. Des tâches planifiées qui s'accumulent. Par défaut, WordPress lance ses tâches planifiées au passage des visiteurs : elles occupent le serveur en même temps qu'eux. Des milliers d'actions de WooCommerce en retard, une sauvegarde ou un envoi programmés en pleine journée, et le serveur n'a plus de temps pour vos pages.
6. Un délai trop court ou une panne chez l'hébergeur : un serveur de bases de données partagé qui ralentit, un disque saturé, un délai de passerelle réglé plus court que d'habitude.
7. Plus rarement, une intrusion : un site détourné qui envoie du spam ou sert des pages que vous n'avez pas créées occupe le serveur sans que vous le voyiez. Des fichiers ou des pages inconnus, c'est une intrusion repérée : suivez notre guide du site WordPress piraté.

1. Notez ce qui déclenche l'erreur, et au bout de combien de temps

Toujours la même page, ou la même action ? Toutes les pages, mais seulement par moments ? Chronométrez : une erreur qui tombe au bout d'une minute pile correspond au délai par défaut de nginx ou d'Apache, une 524 de Cloudflare arrive après un peu plus de deux minutes (voir le tableau des délais, plus bas). Une seule action dans l'administration mène aux étapes 4 et 5 ; certaines pages seulement, toujours les mêmes, aux étapes 3 et 7 ; toutes les pages aux heures chargées, à l'étape 6. Et avant de relancer une importation, un envoi ou un paiement, vérifiez ce qui a été fait : le serveur a cessé d'attendre, mais PHP a pu finir son travail derrière. Relancer à l'aveugle, c'est risquer des produits ou des commandes en double.

2. Lisez les journaux, à l'heure de l'erreur

Sous cPanel, ouvrez Métriques, puis Erreurs ; sous Plesk, Journaux. Une ligne qui contient upstream timed out confirme que nginx a abandonné en attendant PHP, et donne l'adresse demandée. Derrière Apache, la ligne équivalente contient The timeout specified has expired, souvent suivi de Error dispatching request. Une ligne Maximum execution time dit au contraire que c'est PHP qui a coupé : c'est alors une erreur 500, traitée dans notre guide de l'erreur 500 WordPress. Le journal de WordPress complète celui du serveur. Avec le gestionnaire de fichiers de l'hébergeur ou par FTP, téléchargez d'abord une copie de wp-config.php, le fichier placé à la racine du site, puis ouvrez-le et remplacez la ligne qui contient 'WP_DEBUG', false par ces trois lignes (si elle n'existe pas, ajoutez-les au-dessus de la ligne qui demande de ne plus rien modifier) : WordPress écrira ses erreurs dans wp-content/debug.log sans les montrer aux visiteurs.

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

Une fois l'enquête finie, remettez WP_DEBUG à false et supprimez wp-content/debug.log. Sur une boutique WooCommerce, regardez aussi WooCommerce, puis État, puis Journaux ; sur PrestaShop, le dossier var/logs. Enfin, chez les hébergeurs qui limitent les ressources de chaque compte, la page « Utilisation des ressources » de cPanel montre si les limites ont été atteintes à cette heure-là.

3. Trouvez ce qui est lent avec Query Monitor

Sur WordPress, installez l'extension gratuite Query Monitor, depuis le menu Extensions : elle n'est visible que des administrateurs. Ouvrez la page lente, ou une variante plus légère si elle tombe à chaque fois (moins de produits par page, une période plus courte). La barre d'administration affiche alors le temps de calcul de la page et le nombre de requêtes. Le panneau de Query Monitor signale les requêtes lentes à la base de données, les classe par extension ou par thème responsable, et liste les appels à des services extérieurs, avec leur durée et leurs échecs. Vous savez qui ralentit le site : mettez à jour, réglez ou remplacez cette extension. Désactivez Query Monitor une fois l'enquête finie.

4. Découpez les importations et les exports

Coupez un gros fichier d'importation en plusieurs fichiers de quelques centaines de lignes, avec la même première ligne d'en-têtes dans chacun, et importez-les l'un après l'autre. Les images coûtent souvent le plus : importez d'abord les produits, puis les images, ou régénérez les miniatures plus tard. Dans PrestaShop, l'importation (Paramètres avancés, puis Importer) propose justement de ne pas régénérer les miniatures pendant l'importation. Pour un export ou des statistiques, choisissez une période plus courte. Pour les sauvegardes, préférez celles de l'hébergeur, qui ne passent pas par les pages du site, ou programmez celles de l'extension la nuit.

5. Mettez les tâches planifiées à leur place

Plutôt que d'attendre le passage des visiteurs, confiez les tâches planifiées de WordPress à l'horloge du serveur. Dans wp-config.php (gardez-en d'abord une copie, comme à l'étape 2), ajoutez au-dessus de la ligne qui demande de ne plus rien modifier :

define('DISABLE_WP_CRON', true);

Puis créez chez l'hébergeur (sous cPanel, « Tâches Cron » ; sous Plesk, les tâches planifiées) une tâche qui tourne toutes les quinze minutes, avec cette commande, où votresite.fr est l'adresse de votre site :

wget -q --delete-after https://votresite.fr/wp-cron.php

Ne sautez pas cette seconde étape : sans elle, plus rien ne tourne, ni publications programmées, ni e-mails programmés, ni sauvegardes de l'extension. Le lendemain, ouvrez Outils, puis Santé du site : aucune tâche planifiée ne doit y être signalée en échec ou en retard. Sinon, la tâche Cron ne tourne pas comme prévu : vérifiez-la avec l'hébergeur. Sur une boutique, ouvrez aussi la liste des actions planifiées, dans WooCommerce, puis État : des milliers d'actions en attente ou en échec désignent l'extension qui les crée. Programmez enfin sauvegardes, importations et envois la nuit.

6. Allégez le serveur : cache de pages et robots

Une page servie depuis un cache n'est pas recalculée : ni requêtes à la base, ni appels extérieurs, elle part en une fraction de seconde. Une extension de cache de pages bien réglée soulage donc beaucoup le serveur ; vérifiez seulement que le panier, la commande et le compte client sont exclus du cache. Regardez aussi le journal des visites (« Visiteurs » ou « Accès bruts » sous cPanel) : si une même adresse IP ou un même robot demande des centaines de pages, la page de connexion ou la recherche, bloquez-le au pare-feu de l'hébergeur, par une extension de sécurité ou chez Cloudflare.

7. Nettoyez la base de données

Faites d'abord une sauvegarde. Dans phpMyAdmin, ouvrez la base du site et triez les tables par taille : sur un petit site, une table de plusieurs centaines de mégaoctets trahit des journaux jamais vidés, souvent ceux d'une extension, ou wp_actionscheduler_logs sur une boutique WooCommerce (le préfixe peut différer). Videz-les depuis les réglages de l'extension qui les écrit plutôt qu'à la main, et réglez une durée de conservation. Limitez les révisions d'articles avec define('WP_POST_REVISIONS', 10); dans wp-config.php. Puis ouvrez Outils, puis Santé du site : WordPress y signale notamment des réglages trop lourds chargés à chaque page (au-delà de 800 Ko environ) et des tâches planifiées en retard.

8. Les délais : en dernier, et avec l'hébergeur

Si une tâche légitime a vraiment besoin de plus de temps, relevez max_execution_time dans les réglages de PHP de votre espace (sous cPanel, les options de « Sélectionner une version de PHP » ou l'éditeur INI de MultiPHP ; sous Plesk, les réglages de PHP du domaine), par exemple à 120 ou 300 secondes. Mais le délai de la passerelle, nginx ou Apache, se règle chez l'hébergeur : demandez-le-lui, avec l'adresse de la page, l'action en cause et l'heure des erreurs. Derrière Cloudflare, le délai de 125 secondes ne se change qu'avec l'offre Enterprise : au-delà, la tâche doit être découpée, ou lancée en arrière-plan par une tâche planifiée quand l'extension le propose. Cloudflare suggère aussi un sous-domaine qui ne passe pas par lui, mais ce sous-domaine dévoile l'adresse de votre serveur : demandez conseil avant. Et si le serveur sature chaque semaine malgré tout cela, ce n'est plus une panne : le site a besoin d'une offre d'hébergement plus puissante.

Entre le visiteur et la page, la demande traverse plusieurs maillons, et chacun a son propre délai d'attente. Voici les valeurs d'origine, telles que les logiciels sont livrés :

Chaque hébergeur règle les siens, souvent plus longs pour PHP. Deux conséquences. Relever le délai de PHP ne change rien si nginx abandonne avant : c'est pourquoi tant de 504 résistent à un max_execution_time relevé. Et sur un hébergement mutualisé, seuls les réglages de PHP sont à votre portée ; ceux de nginx ou d'Apache relèvent de l'hébergeur.

• Erreur 502 Bad Gateway. Le serveur placé devant le site reçoit une réponse invalide : PHP arrêté, planté ou débordé.
• Erreur 503 WordPress. Site bloqué en maintenance après une mise à jour, ou serveur saturé.
• Erreur 520, 521 ou 522 de Cloudflare. Le serveur qui héberge le site refuse la connexion, tarde trop ou répond de façon inattendue.
• Erreur de connexion à la base de données WordPress. Le site ne joint plus la base où sont rangés vos contenus : identifiants, serveur, tables.

Toutes les erreurs, classées par message : Erreurs de site, trouver la cause et réparer. Des signes d'intrusion (redirections, pages inconnues, fichiers que vous n'avez pas mis) : suivez plutôt notre guide site WordPress piraté, que faire dans la première heure.

Rédigé par l'équipe Boost de WS Agency, qui maintient et protège des sites WordPress, PrestaShop et Joomla. Publié le 30 octobre 2026. Manipulations vérifiées le 30 octobre 2026 ; elles valent pour WordPress 6 et 7, PHP 8.1 à 8.5, et PrestaShop 8 et 9 quand ils sont cités. Documentations de Cloudflare, nginx, Apache, PHP, WordPress et Google consultées le 30 octobre 2026.

• MDN, 504 Gateway Timeout (définition, différence avec la 502, cas du réseau du visiteur).
• Cloudflare, erreur 502 ou 504 (page aux couleurs de Cloudflare : l'erreur vient du serveur d'origine) et erreur 524 (125 secondes par défaut, jusqu'à 6 000 secondes avec l'offre Enterprise).
• nginx, fastcgi_read_timeout et proxy_read_timeout (60 secondes entre deux lectures) ; Apache, directive Timeout (60 secondes, reprise par ProxyTimeout) et code source de mod_proxy_fcgi (délai dépassé : erreur 504, « Error dispatching request »).
• PHP, max_execution_time (trente secondes par défaut), set_time_limit (le temps passé à attendre la base de données n'est pas compté, sauf sous Windows) et configuration de PHP-FPM (request_terminate_timeout, désactivé par défaut).
• WordPress, confier les tâches planifiées au serveur (DISABLE_WP_CRON), délai des appels extérieurs (5 secondes par défaut) et Query Monitor, extension gratuite.
• Google Search Central, erreurs HTTP et réseau (traitement des codes 5xx).

Une erreur, une information à compléter, un droit de réponse ? Écrivez à contact@wsagency.fr : nous corrigeons, et nous indiquons ici ce qui a changé et quand.