Erreur 408 Request Timeout : pourquoi et comment la régler

Erreur 408 Request Timeout : ce que c’est et pourquoi elle apparaît

Une erreur 408 Request Timeout signifie que le serveur a fermé la connexion parce qu’il n’a pas reçu une requête complète dans le délai qu’il acceptait d’attendre source : RFC 9110, 2022. Elle vient d’une connexion lente, d’un upload volumineux ou d’un timeout serveur trop court.

Un timeout est un délai maximal accordé à une étape (réception de l’en-tête, réception du corps, attente entre deux paquets). Passé ce délai, le serveur abandonne. Le 408 appartient à la famille 4xx, celle des « erreurs client », mais cela ne désigne pas forcément le visiteur comme fautif : un réglage serveur trop strict suffit à la provoquer.

Le 408 se distingue de trois erreurs voisines :

• 504 Gateway Timeout : c’est le serveur en amont qui répond trop lentement (voir l’erreur 504 sur WordPress).
• 413 : le fichier dépasse la taille autorisée et il est rejeté immédiatement, avant tout délai (voir l’erreur 413).
• 524 Cloudflare : Cloudflare attend trop longtemps votre serveur d’origine (voir l’erreur 524).

Bonne nouvelle : le 408 se règle presque toujours avec une ou deux directives, une fois la phase en cause identifiée.

Pourquoi le 408 se déclenche

Le serveur attend trois choses du client : la poignée de main TLS, l’en-tête de la requête, puis le corps. Si l’une de ces étapes traîne, il coupe. Les causes courantes :

• Connexion lente ou instable : 4G saturée, Wi-Fi faible, VPN, réseau d’entreprise filtré.
• Upload volumineux : une vidéo ou un PDF lourd envoyé en formulaire, avec un débit montant faible.
• Timeouts serveur trop agressifs : des délais courts copiés d’un guide de durcissement, sans tenir compte des vrais usages.
• Connexions inactives : MDN indique que le 408 sert aussi à fermer une connexion inutilisée, et que certains serveurs l’envoient même sans requête préalable source : MDN Web Docs.
• Plusieurs couches en chaîne : CDN, proxy, load balancer et serveur web ont chacun leur délai, et le plus court l’emporte.

Le keep-alive est le mécanisme qui maintient une connexion TCP ouverte pour envoyer plusieurs requêtes à la suite, sans la rouvrir à chaque fois. Chrome et Firefox ouvrent aussi des connexions à l’avance (pré-connexion) qui restent parfois inutilisées, d’où des 408 sans aucun problème réel source : MDN Web Docs.

1. Vérifier si le 408 est réel ou inoffensif

Avant de modifier quoi que ce soit, regardez les logs d’accès. Chemins usuels : /var/log/nginx/access.log pour nginx, /var/log/apache2/access.log pour Apache (ou le dossier de logs de votre panel d’hébergement).

grep ' 408 ' /var/log/nginx/access.log | tail -n 50

Lisez les lignes :

• Ligne de requête vide ("-") et 0 octet envoyé : le plus souvent une connexion inactive ou une pré-connexion de navigateur. Aucun visiteur n’est bloqué. Excluez ces 408 de votre monitoring pour éviter les fausses alertes.
• Requête réelle (POST, PUT) avec une URL précise : un visiteur a perdu quelque chose. Notez l’URL, l’heure et la taille envoyée.

Si les 408 se concentrent sur une URL d’upload, passez aux étapes 3 et 6. S’ils touchent toutes les pages, regardez les étapes 2, 4 et 5.

2. Écarter la connexion du visiteur

Un test simple départage réseau et serveur. Reproduisez l’envoi avec un débit volontairement limité :

curl -v --limit-rate 50k -F "file=@gros-fichier.zip" https://votresite.fr/upload

Si le 408 apparaît à ce débit mais pas à pleine vitesse, le serveur est trop impatient pour les connexions lentes. Testez ensuite depuis un autre réseau (4G à la place du Wi-Fi, sans VPN). Si l’erreur disparaît, la cause est côté réseau du visiteur, et la correction se fait par le découpage de l’envoi (étape 6).

Prenons un cas typique (fictif) : un formulaire de candidature accepte un CV de 15 Mo. Un candidat l’envoie depuis un train, avec un débit montant faible. L’envoi dépasse le délai de lecture du corps, le serveur répond 408. Rien n’est cassé, mais les délais sont calibrés pour une connexion fixe.

3. Régler les délais côté nginx

Sur nginx, deux directives gouvernent la plupart des 408 :

• client_header_timeout : délai de lecture de l’en-tête. Si le client ne l’envoie pas en entier dans ce délai, la requête se termine par un 408 source : documentation nginx, 2026.
• client_body_timeout : délai entre deux lectures successives du corps. Valeur par défaut : 60 s source : GetPageSpeed.

Pour un upload, limitez le changement à l’URL concernée plutôt qu’à tout le site :

location /upload {
    client_body_timeout 120s;
    proxy_read_timeout 120s;
}

Il faut souvent augmenter les deux : client_body_timeout concerne la réception depuis le client, proxy_read_timeout l’attente de l’application derrière nginx source : GetPageSpeed. Testez puis rechargez :

nginx -t && systemctl reload nginx

Côté keep-alive, keepalive_timeout vaut 75 s par défaut source : GetPageSpeed. keepalive_requests fixe le nombre de requêtes par connexion, et nginx déconseille une valeur trop élevée à cause de la mémoire consommée source : documentation nginx, 2026.

4. Régler les délais côté Apache

Sur Apache, le module mod_reqtimeout renvoie un 408 quand le client ne termine pas une étape à temps. La directive RequestReadTimeout règle la poignée de main TLS, l’en-tête et le corps. Valeur par défaut : handshake=0 header=20-40,MinRate=500 body=20,MinRate=500 source : Apache HTTP Server 2.4, 2026.

MinRate rend le délai extensible : 1 seconde de plus par tranche d’octets reçus. Un client lent mais qui progresse n’est donc pas coupé, alors qu’un client qui n’envoie plus rien l’est. C’est préférable à un délai fixe très long, qui expose aux attaques de type Slowloris, où un attaquant garde des connexions ouvertes en envoyant des données au compte-gouttes.

Exemple de départ, plus tolérant sur le corps :

RequestReadTimeout header=20-40,MinRate=500 body=30,MinRate=500

La documentation recommande de configurer à la fois les délais d’en-tête et de corps, sans les fixer trop bas si la configuration est partagée entre vhosts http et https source : Apache HTTP Server 2.4, 2026. Sur Debian ou Ubuntu, vérifiez que le module est actif (a2enmod reqtimeout), validez avec apachectl configtest, puis rechargez Apache. KeepAliveTimeout vaut 5 s par défaut source : Copahost : gardez cette valeur courte.

Sur un hébergement mutualisé, ces fichiers ne sont pas modifiables : demandez à l’hébergeur d’ajuster le délai de lecture du corps pour l’URL concernée.

Récapitulatif des directives

5. Aligner les couches intermédiaires

Si votre site passe par un CDN, un proxy ou un load balancer, chaque couche a son propre délai, et le plus court l’emporte. Allonger client_body_timeout sur le serveur ne sert à rien si la couche devant coupe à 30 s. Listez chaque maillon, relevez son délai dans sa documentation, puis alignez-les pour qu’aucun ne soit plus court que ce que l’upload exige. Si l’erreur observée est plutôt une 524, la logique est la même, détaillée dans l’article sur l’erreur 524.

6. Découper ou reprendre les gros envois

Allonger les délais n’est pas toujours la bonne réponse. Pour des fichiers lourds, prévoyez côté application un envoi en morceaux avec reprise. La RFC 9110 prévoit que le client peut répéter sa requête, sur une nouvelle connexion si l’ancienne n’est plus utilisable source : RFC 9110, 2022. Un formulaire qui réessaie automatiquement fait disparaître la plupart des 408 vus par les visiteurs.

Sur WordPress, vérifiez aussi les limites PHP liées aux envois : elles produisent plutôt des 413, expliquées dans le guide des directives PHP.

Tableau cause → solution

FAQ

Quand passer la main à un pro

Passez la main si vous n’avez pas d’accès aux fichiers de configuration (mutualisé), si les 408 persistent après alignement des délais, ou si plusieurs couches (CDN, proxy, application) interagissent sans que vous sachiez laquelle coupe. Une erreur réseau plus générale se diagnostique avec ERR_CONNECTION_TIMED_OUT.

Ces réglages relèvent du suivi courant d’un serveur : une maintenance par abonnement inclut la lecture des logs et l’ajustement des délais avant que les visiteurs ne les remarquent.