Votre site WordPress charge longtemps, puis le navigateur affiche une erreur 504 au moment où vous attendiez la page d’accueil ou l’administration. Ce code signifie que la passerelle n’a pas reçu la réponse du serveur amont dans le délai prévu. Pour corriger une WordPress erreur 504, identifiez d’abord le composant qui attend, consultez les journaux, puis ajustez le délai uniquement après avoir corrigé la requête lente, PHP, la base de données ou le proxy concerné.
Une erreur 504 n’est donc pas une panne WordPress unique. Elle peut venir de PHP-FPM, de MySQL, de Nginx, d’Apache, d’un CDN ou d’une API externe. La bonne méthode consiste à séparer le symptôme visible de la cause réelle.
Que signifie exactement une WordPress erreur 504
Le statut HTTP 504 Gateway Timeout indique qu’un serveur jouant le rôle de passerelle ou de proxy n’a pas obtenu à temps une réponse valide d’un serveur en amont. Le serveur frontal fonctionne encore, mais il ne peut pas terminer la requête. La définition officielle figure dans la documentation MDN du statut 504 et dans la spécification HTTP RFC 9110.
Dans WordPress, le chemin ressemble souvent à ceci : navigateur, CDN éventuel, Nginx ou Apache, PHP-FPM, WordPress, extension, puis MySQL ou une API distante. Chaque maillon peut avoir son propre délai. Une page publique lente et une requête AJAX qui expire ne se diagnostiquent pas de la même manière.
Le diagnostic rapide avant de modifier la configuration
Commencez par noter l’URL, l’heure, le navigateur, le compte concerné et l’action qui déclenche l’erreur. Testez ensuite une page publique légère, la page de connexion et une URL qui ne lance pas de traitement complexe. Si tout le site répond sauf l’administration, cherchez une extension ou une tâche d’import. Si toutes les pages expirent, examinez l’hébergement, PHP-FPM, la base et le proxy.
curl -I https://example.com/
curl -sS -o /dev/null -w 'code=%{http_code} total=%{time_total}n' https://example.com/wp-admin/
Le premier test montre les en-têtes et le second mesure le temps total. Faites-le depuis votre poste puis depuis un autre réseau si possible. Une réponse 504 partout suggère un problème côté serveur. Une réponse correcte depuis un autre réseau peut révéler un CDN, un pare-feu ou une règle réseau.
Lire les journaux WordPress et serveur
Activez le journal WordPress sans afficher les erreurs aux visiteurs. La documentation officielle du débogage WordPress recommande de séparer WP_DEBUG_LOG et WP_DEBUG_DISPLAY. Utilisez cette configuration temporaire dans wp-config.php, avant la ligne de fin indiquée par WordPress.
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
Reproduisez une seule fois l’erreur, puis lisez wp-content/debug.log. Cherchez les mots allowed memory size, Maximum execution time, cURL error, database error, fatal error ou une trace d’extension. Désactivez le mode debug après le test si vous ne surveillez pas le fichier, car un journal qui grossit sans contrôle peut aggraver la situation.
tail -n 100 wp-content/debug.log
grep -Ei 'fatal|timeout|curl|database|memory' wp-content/debug.log | tail -n 50
Les journaux du serveur sont souvent plus précis. Selon l’hébergement, consultez error.log d’Apache, le journal Nginx, le journal PHP-FPM et les événements MySQL. Un message upstream timed out or PHP worker pool exhausted oriente vers le proxy ou PHP. Une trace SQL très lente oriente vers la base ou une extension.
Écarter une extension ou un thème lent
Une extension peut lancer une requête distante, recalculer une grande liste ou monopoliser un processus PHP. Si wp-admin reste accessible par moments, désactivez temporairement les extensions non essentielles, une par une. Pour un site bloqué, utilisez WP-CLI ou renommez le dossier de l’extension uniquement après avoir vérifié que vous disposez d’un accès de secours.
wp plugin list --status=active
wp plugin deactivate nom-extension --skip-plugins --skip-themes
wp plugin activate nom-extension --skip-plugins --skip-themes
Le thème peut aussi déclencher le délai via une requête dans une boucle, un appel HTTP ou un traitement exécuté sur chaque page. Testez un thème officiel depuis un environnement de préproduction. Ne désactivez pas au hasard un plugin de cache en production sans sauvegarde de sa configuration. Notre guide sur l’erreur 500 WordPress explique la même démarche de séparation entre PHP, extension et serveur.
Vérifier PHP-FPM et les limites d’exécution
PHP-FPM utilise un pool de processus. Si tous les workers sont occupés, les nouvelles requêtes attendent jusqu’à l’expiration du proxy. Un hébergement peut aussi tuer un script trop long avant que WordPress ne termine. Contrôlez la version PHP, la mémoire disponible, le nombre de workers et les journaux FPM depuis votre panneau d’hébergement.
php -v
php -i | grep -E 'memory_limit|max_execution_time|max_input_time'
wp eval 'echo PHP_VERSION . PHP_EOL; echo WP_MEMORY_LIMIT . PHP_EOL;'
Augmenter memory_limit ne répare pas une requête SQL inefficace. De même, augmenter max_execution_time ne crée pas de worker supplémentaire. La documentation PHP-FPM sur request_terminate_timeout montre qu’un processus peut être arrêté après une durée définie. Ajustez les limites avec l’hébergeur et mesurez avant et après.
Analyser la base de données et les requêtes lentes
Les imports, recherches sans index, métadonnées volumineuses et tâches cron sont des causes fréquentes. Un article avec une grande quantité de métadonnées peut rendre l’administration lente sans que la page publique soit touchée. Vérifiez les tâches planifiées, les tables qui grossissent et les requêtes lentes avec un outil de staging ou un plugin de profilage utilisé temporairement.
wp cron event list --fields=hook,next_run, recurrence
wp db size
wp db check
Ne lancez pas une réparation ou une optimisation lourde pendant une période de trafic sans sauvegarde vérifiée. Pour les gros traitements, découpez l’opération en lots et exécutez-la en ligne de commande ou en tâche planifiée. Si vous préparez une mise à jour, suivez aussi notre méthode de sauvegarde WordPress avant mise à jour.
Contrôler Nginx, Apache et les délais du proxy
Un proxy abandonne lorsqu’il attend trop longtemps l’amont. Nginx documente proxy_read_timeout comme le délai entre deux lectures successives de la réponse proxifiée. Apache possède ses propres réglages, dont TimeOut. Les valeurs exactes dépendent de l’architecture de votre hébergeur.
# Exemple Nginx à adapter au serveur
location ~ .php$ {
fastcgi_read_timeout 60s;
}
# Exemple proxy, uniquement si vous contrôlez ce proxy
proxy_read_timeout 60s;
Ne copiez pas ces directives dans un fichier .htaccess. Elles ne sont pas toutes acceptées par Apache et une erreur de syntaxe peut provoquer une erreur 500. Sur un hébergement mutualisé, demandez à l’assistance de vérifier le délai amont, le pool PHP et les limites imposées. Un délai plus long ne fait que laisser le visiteur attendre davantage si la cause reste lente.
Vérifier CDN, DNS et services externes
Un CDN peut générer sa propre page 504 alors que l’origine fonctionne. Comparez le résultat avec l’URL d’origine autorisée, sans contourner une règle de sécurité en production. Vérifiez les en-têtes Server, Via, CF-Ray ou équivalents, puis consultez la page d’état du fournisseur. Cloudflare décrit ses erreurs 504 et les différences entre délai de l’origine et problème de réseau.
Si l’erreur survient après le clic sur un bouton, identifiez l’appel distant. Une extension qui interroge une API lente peut bloquer la requête WordPress. Ajoutez un délai raisonnable, une mise en cache de la réponse et une gestion d’échec. Un service externe ne doit pas empêcher l’accès à l’administration.
curl -sS -D - -o /tmp/reponse-api.json --max-time 20 https://api.example.com/health
cat /tmp/reponse-api.json
Corriger sans masquer la cause
La correction durable suit généralement cet ordre : réduire ou découper la requête, corriger l’extension ou la requête SQL, libérer les workers PHP, vérifier la base et seulement ensuite ajuster le délai du proxy. Purgez ensuite le cache de page et le cache d’objet si le résultat d’erreur a été mémorisé. Notre guide sur l’erreur 503 WordPress complète le diagnostic lorsque le serveur refuse les requêtes par surcharge ou indisponibilité.
Après correction, répétez le scénario au moins trois fois avec un cache froid et un cache chaud. Mesurez le temps avant le timeout et surveillez les journaux pendant quelques minutes. Contrôlez aussi une page publique, wp-admin, l’éditeur, les formulaires et les tâches cron. Une correction qui rend la page visible mais laisse PHP saturé n’est pas terminée.
Plan d’action en dix minutes
- Notez l’URL et l’heure exacte.
- Testez une page publique légère et wp-admin.
- Reproduisez une seule fois avec curl.
- Lisez debug.log et les journaux serveur.
- Identifiez le proxy qui renvoie 504.
- Contrôlez les workers PHP-FPM.
- Testez les extensions et le thème en staging.
- Vérifiez cron, MySQL et les appels externes.
- Corrigez la cause avant d’augmenter un timeout.
- Purgez les caches et vérifiez plusieurs scénarios.
FAQ sur la WordPress erreur 504
Une erreur 504 vient-elle toujours de l’hébergeur ?
Non. Elle peut venir d’une extension, d’une requête SQL, de PHP-FPM, d’un reverse proxy, d’un CDN ou d’une API externe. Les journaux permettent de localiser le maillon qui attend.
Faut-il augmenter le timeout PHP pour corriger une erreur 504 ?
Pas en premier. Augmenter le délai peut masquer une requête lente et saturer les workers. Corrigez la cause, puis augmentez le délai seulement si le traitement est légitime et maîtrisé.
Pourquoi le site public fonctionne alors que wp-admin affiche 504 ?
L’administration exécute souvent des requêtes plus lourdes, des imports, des appels AJAX ou des tâches cron. Une extension de back office ou une table volumineuse peut donc toucher wp-admin en priorité.
Une erreur 504 peut-elle venir d’un plugin de cache ?
Oui, indirectement. Le cache peut lancer une régénération coûteuse, retenir une réponse d’erreur ou dialoguer avec un service externe. Désactivez-le temporairement en staging et comparez les temps.
Comment éviter le retour de l’erreur 504 ?
Surveillez les journaux, les temps PHP, le pool de workers, les tâches cron et les requêtes lentes. Ajoutez une surveillance HTTP et testez les mises à jour sur une copie du site avant la production.
Documenter l’incident pour ne pas le subir deux fois
Conservez une courte fiche après chaque incident. Notez le déclencheur, la durée, le code renvoyé, le composant responsable, la commande utilisée et la correction appliquée. Cette trace évite de modifier les mêmes paramètres au hasard lors du prochain incident. Elle aide aussi l’hébergeur à répondre vite, car un horaire précis et un extrait de journal valent mieux qu’une simple capture d’écran.
Ajoutez enfin un contrôle synthétique qui ouvre une page publique et une page fonctionnelle légère. Une alerte après plusieurs échecs consécutifs est préférable à une alerte sur un seul délai exceptionnel. Le but n’est pas de supprimer toute latence, mais de repérer assez tôt la saturation d’un worker, la croissance d’une table ou la panne d’une dépendance externe.
Commentaires (0)
Laisser un commentaire
Les commentaires sont modérés. Questions WordPress, cybersécurité ou dev web bienvenues.