Vous cliquez sur Publier, puis l’écran attend, attend encore et finit par afficher une erreur 408. WordPress erreur 408 signifie que le serveur n’a pas reçu à temps la suite de la requête envoyée par votre navigateur ou par un proxy. La solution consiste à identifier le maillon qui expire, puis à aligner les délais du navigateur, du proxy, du serveur web et de PHP. Commencez par retester sans extension, vérifiez les journaux et comparez une page légère avec l’action qui échoue.

Que signifie exactement une erreur 408 dans WordPress

Le code HTTP 408 correspond à Request Timeout. Le serveur a ouvert une connexion, mais il n’a pas reçu une requête complète dans le délai prévu. Ce n’est donc pas exactement la même panne qu’une erreur 504. Avec une 504, un serveur passerelle attend la réponse d’un autre serveur qui tarde. Avec une 408, le serveur qui reçoit la connexion considère que le client n’envoie pas assez vite les données.

Dans WordPress, la frontière est parfois moins nette. Un pare feu, un CDN, un reverse proxy ou un hébergeur peut transformer un délai interne en réponse 408. Un import volumineux, une requête REST lente, un éditeur bloqué ou une connexion mobile instable sont des déclencheurs courants. Le code visible ne suffit donc pas. Il faut lire la chaîne complète.

Le standard HTTP ne fixe pas un délai universel. Chaque composant applique sa propre politique. Un proxy peut expirer après 60 secondes, PHP après 120 secondes et le navigateur après un délai différent. Modifier un seul réglage sans mesurer risque de déplacer l’erreur vers un autre code.

Les symptômes qui permettent de localiser le délai

Notez l’action exacte et le moment où elle échoue. Une erreur au chargement de la page d’accueil pointe plutôt vers le réseau, le serveur web ou le DNS. Une erreur uniquement pendant l’envoi d’une image vise souvent la taille du corps de requête, PHP ou la connexion montante. Une erreur uniquement dans l’éditeur peut venir d’un appel REST, d’admin-ajax.php ou d’un plugin qui exécute une tâche longue.

Comparez aussi les environnements. Si la page fonctionne en Wi Fi mais pas en 4G, testez la connexion et le VPN. Si elle fonctionne connecté mais pas déconnecté, cherchez un plugin ou une règle de cache. Si elle échoue uniquement derrière Cloudflare, examinez le proxy avant de modifier WordPress.

# Observer les en-têtes et le temps de réponse curl -sS -o /dev/null -D -    -w "nHTTP %{http_code}nTTFB %{time_starttransfer}snTotal %{time_total}sn"    https://exemple.com/wp-json/  # Comparer une page légère et l’endpoint qui échoue curl -sS -o /dev/null -w "%{http_code} %{time_total}sn" https://exemple.com/ curl -sS -o /dev/null -w "%{http_code} %{time_total}sn" https://exemple.com/wp-json/wp/v2/posts

Vérifier le navigateur, le réseau et le CDN

Avant de toucher au serveur, ouvrez une fenêtre privée et désactivez temporairement les extensions qui filtrent les requêtes. Reproduisez l’action dans un autre navigateur, puis depuis un autre réseau. Dans les outils de développement, l’onglet Réseau indique la requête qui reste en attente. Relevez son URL, sa méthode, sa taille et son code de réponse.

Un VPN, un antivirus web ou un réseau d’entreprise peut interrompre une requête longue. Les imports de médias sont particulièrement sensibles, car le navigateur doit envoyer un flux continu. Une mise en veille de l’ordinateur ou un changement de réseau suffit à laisser le serveur avec une requête incomplète.

Si le site utilise un CDN, consultez ses événements et ses journaux. Vérifiez que le DNS pointe vers la bonne origine, que le mode proxy est attendu et que la règle de délai s’applique au bon chemin. Ne désactivez pas durablement la protection. Faites un test ciblé sur une URL publique et remettez la configuration initiale après le diagnostic.

Contrôler PHP et les limites WordPress

Une requête lente n’est pas toujours une requête trop grosse. WordPress peut attendre un plugin, une API externe, une base de données ou une tâche cron. Dans le journal PHP, recherchez les dépassements de délai, les erreurs de mémoire et les appels sortants. Dans WordPress, activez le débogage sur un environnement de test ou pendant une fenêtre contrôlée, sans afficher les erreurs aux visiteurs.

# wp-config.php, uniquement pour un diagnostic contrôlé # Placez ces constantes avant la ligne de fin du fichier  define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false );  # Après reproduction, consultez wp-content/debug.log # Puis désactivez l’affichage et archivez le journal avec précaution

Pour un import, comparez la taille du fichier aux valeurs de upload_max_filesize et post_max_size. Pour une action administrative, regardez aussi la mémoire disponible et le délai maximal d’exécution. Augmenter max_execution_time ne réparera pas un client qui cesse d’envoyer sa requête, mais peut éviter qu’un traitement serveur légitime expire trop tôt.

Si l’action appelle une API externe, testez cette API séparément. Un service tiers lent peut faire croire à une panne WordPress. Remplacez temporairement l’appel par une réponse simulée en préproduction ou désactivez le plugin responsable. La bonne correction consiste alors à ajouter une temporisation raisonnable, une nouvelle tentative bornée et une file de traitement, pas à rendre toutes les requêtes infinies.

Inspecter Apache, Nginx et les journaux serveur

Les journaux d’accès indiquent si le serveur a reçu une requête complète. Les journaux d’erreurs précisent souvent le module ou le délai concerné. Cherchez l’heure exacte, l’adresse IP, l’URL et la méthode. Comparez ces éléments avec le journal PHP et le journal du CDN. Trois horloges désynchronisées rendent l’enquête inutilement difficile.

Sur Apache, RequestReadTimeout contrôle notamment le temps accordé à la réception des en-têtes et du corps. Sur Nginx, les directives client_header_timeout et client_body_timeout concernent le temps entre deux opérations de lecture du client. Elles ne doivent pas être augmentées sans limite, car elles permettent à un attaquant de garder des connexions ouvertes.

# Exemple Nginx à adapter à votre serveur server {     client_header_timeout 30s;     client_body_timeout 60s;     client_max_body_size 32m;      location ~ .php$ {         fastcgi_read_timeout 120s;     } }  # Vérifiez la configuration avant rechargement nginx -t # Puis rechargez avec la méthode de votre distribution

Sur un hébergement mutualisé, vous ne contrôlez pas toujours ces directives. N’ajoutez pas une directive Nginx dans un fichier .htaccess Apache. Demandez à l’hébergeur le délai appliqué et fournissez l’heure, l’URL et l’identifiant de requête si le serveur en affiche un.

Corriger un appel REST ou admin-ajax.php trop lent

L’éditeur WordPress dépend de l’API REST pour enregistrer certaines données et prévisualiser le contenu. Des extensions utilisent aussi admin-ajax.php pour des recherches, des statistiques ou des constructeurs visuels. Dans l’onglet Réseau, filtrez par wp-json et admin-ajax. Une seule requête lente peut bloquer l’interface alors que le reste du site fonctionne.

Testez les extensions avec le mode dépannage de Health Check ou sur une copie. Désactivez d’abord les plugins qui interrogent une API externe, construisent des index ou ajoutent des métriques à chaque sauvegarde. Vérifiez aussi les règles de sécurité qui inspectent le corps JSON. Un WAF trop strict peut ralentir ou interrompre certaines requêtes légitimes.

Pour une opération longue, préférez un traitement asynchrone. L’interface reçoit rapidement un identifiant de tâche, puis WordPress traite le travail en arrière plan. Cette architecture améliore l’expérience et réduit la dépendance aux délais de plusieurs couches réseau.

Éviter de confondre erreur 408, 413, 429 et 504

Les codes voisins orientent vers des corrections différentes. Une erreur 413 indique que le corps de la requête est trop volumineux. Une erreur 429 signale une limitation de fréquence. Une erreur 504 indique qu’un proxy n’a pas reçu à temps la réponse de l’origine. Une erreur 408 indique d’abord une requête cliente reçue trop lentement ou incomplètement.

Cette distinction est utile dans un diagnostic en série. Si le fichier est rejeté immédiatement avec 413, augmenter le délai ne sert à rien. Si le serveur répond 429 après plusieurs essais, ralentissez le client et respectez Retry-After. Si le proxy répond 504 après une durée presque constante, mesurez le traitement PHP et la base de données. Si le délai varie avec le réseau et la taille du flux, commencez par la connexion et la réception du corps.

Nos guides sur l’erreur 413 WordPress, l’erreur 429 WordPress et l’erreur 504 WordPress détaillent ces cas sans mélanger leurs causes.

Procédure de résolution en dix minutes

Commencez par noter l’heure et l’URL qui échoue. Reproduisez depuis une fenêtre privée. Mesurez la réponse avec curl. Comparez une page légère avec l’endpoint concerné. Consultez le journal du CDN, puis le journal web et enfin le journal PHP. Si le problème disparaît avec les extensions désactivées, réactivez-les une par une. Si seule une taille de fichier déclenche la panne, vérifiez les limites de réception avant le code WordPress.

Après la correction, testez une publication, un import, une connexion et l’API REST. Purgez le cache seulement après avoir confirmé que le serveur répond correctement. Conservez la configuration précédente et documentez le délai modifié. Une hausse excessive peut masquer la panne, consommer des processus PHP et augmenter la surface d’attaque.

# Contrôles post-correction curl -sS -o /dev/null -w "home %{http_code} %{time_total}sn" https://exemple.com/ curl -sS -o /dev/null -w "rest %{http_code} %{time_total}sn" https://exemple.com/wp-json/  # Vérifier les en-têtes de cache et le serveur curl -sSI https://exemple.com/wp-json/ | sed -n '1,25p'

Questions fréquentes sur WordPress erreur 408

Une erreur 408 vient-elle toujours de mon hébergeur ? Non. Le navigateur, le réseau, un VPN, un CDN, un proxy ou un plugin peuvent interrompre l’envoi. Les journaux et un test depuis un autre réseau permettent de séparer ces causes.

Comment corriger une erreur 408 pendant un import d’image ? Vérifiez la stabilité de la connexion, les limites PHP, la taille maximale autorisée et les délais de réception du serveur. Importez ensuite un fichier plus petit pour confirmer le diagnostic.

Faut-il augmenter le timeout PHP ? Seulement si le journal montre que le traitement serveur expire. Une erreur de réception client se corrige avec les délais du serveur web ou du proxy, et non avec max_execution_time.

Une erreur 408 peut-elle venir d’un plugin WordPress ? Oui. Un plugin peut ralentir une sauvegarde, appeler un service externe ou ajouter une inspection WAF. Testez en mode dépannage et mesurez la requête fautive.

Quelle différence avec une erreur 504 ? La 408 concerne d’abord une requête cliente reçue trop lentement. La 504 concerne un serveur intermédiaire qui attend une réponse trop lente d’un serveur amont.

Sources et références

Si le refus porte sur une demande mal formée, notre guide sur WordPress erreur 400 aide à distinguer cookies, URL, REST API et pare feu.

Un statut 422 ne se traite pas comme un délai dépassé. Notre guide WordPress erreur 422 détaille la validation des champs et des payloads REST.

N
· Développeur WordPress & fullstack · Expert IA

Natsou développe sur WordPress depuis plus de 10 ans. Développeur fullstack et expert en intelligence artificielle, il conçoit, débogue et sécurise des sites en production et automatise les workflows d'agence. Sur WP Admin Lab, il partage des procédures testées en conditions réelles : diagnostics reproductibles, correctifs vérifiés et retours de terrain, sans jargon inutile.

mastodon