Erreur 400 Bad Request : signification et solutions

Qu'est-ce que l'erreur 400 Bad Request ?

400 Bad Request est un code de statut HTTP qui signifie que le serveur a reçu votre requête mais refuse de la traiter parce que quelque chose dans la requête elle-même semble incorrect. La norme HTTP la définit comme l'incapacité ou le refus du serveur de traiter une requête « en raison de quelque chose perçu comme une erreur du client (par ex. une syntaxe de requête mal formée, un cadrage de message de requête invalide ou un routage de requête trompeur) » (RFC 9110 §15.5.1).

Contrairement à une erreur 500, qui signifie que le serveur a planté, une erreur 400 désigne la requête : l'URL, les en-têtes, les cookies ou les données envoyés par votre navigateur ou votre application. Pour tous les autres visiteurs, le site fonctionne généralement très bien.

C'est une bonne nouvelle pour les visiteurs, car la solution se trouve souvent de votre côté et prend une minute : un lien mal saisi ou abîmé, ou des cookies devenus trop volumineux pour le serveur.

À quoi ressemble une erreur 400

Le message dépend du logiciel serveur, et le texte complémentaire est souvent le meilleur indice de la cause :

Quelles sont les causes d'une erreur 400 Bad Request ?

• Une URL mal formée. Un signe % égaré, une espace, un caractère qui aurait dû être encodé, ou un lien tronqué ou collé deux fois.
• Des cookies corrompus ou trop volumineux. Les sites qui déposent de nombreux cookies (connexions, tests A/B, statistiques) peuvent faire dépasser à l'en-tête Cookie la limite du serveur. Un cookie endommagé lors d'une mise à jour peut aussi être rejeté.
• Des en-têtes de requête trop volumineux. En plus des cookies, les longs jetons d'authentification ou les en-têtes ajoutés par des extensions et des proxys s'additionnent.
• Des données invalides envoyées à une API. Champs obligatoires manquants, JSON mal formé ou mauvais en-tête Content-Type.
• Du HTTP envoyé à un port HTTPS. Fréquent derrière les répartiteurs de charge et les reverse proxies.
• Un fichier trop volumineux. Beaucoup de serveurs répondent 413 Content Too Large, mais certaines applications et frameworks renvoient 400 à la place.

Solution 1 : vérifiez l'URL

Examinez attentivement la barre d'adresse. Problèmes à repérer :

• Un % qui n'est pas suivi de deux caractères hexadécimaux (%20 est correct, %2 ou %zz ne l'est pas).
• Des espaces, { }, |, \ ou d'autres caractères inhabituels, surtout dans les liens copiés depuis un e-mail, un PDF ou une messagerie.
• Un lien collé deux fois (https://example.com/https://example.com/...) ou coupé en cours de route.
• Une URL très longue avec des paramètres de suivi. Supprimez tout à partir du ? et réessayez.

Si vous avez suivi un lien depuis un autre site, allez plutôt sur la page d'accueil du site et naviguez jusqu'à la page depuis celle-ci.

Solution 2 : effacez les cookies de ce seul site

C'est la solution pour les messages qui parlent de cookies ou d'en-têtes « too large » ou « too long », et elle vaut la peine d'être essayée pour toute erreur 400 sur un site que vous avez déjà visité. Inutile d'effacer les cookies de tous les sites, seulement ceux de celui-ci :

• Chrome : cliquez sur Afficher des informations à propos du site à gauche de la barre d'adresse → Cookies et données des sites → Gérer les données des sites sur l'appareil → supprimez les données du site, puis rechargez la page.
• Edge : Paramètres et plus → Paramètres → Confidentialité, recherche et services → Cookies → Afficher tous les cookies et les données du site → recherchez le site → supprimez-le.
• Firefox : cliquez sur le cadenas → Effacer les cookies et les données de site…
• Safari (Mac) : Safari → Réglages → Confidentialité → Gérer les données de sites web… → recherchez le site → Supprimer.
• iPhone : Réglages → Apps → Safari → Avancé → Données de sites web → balayez le site vers la gauche pour le supprimer.

Solution 3 : essayez la navigation privée, puis videz le cache

Ouvrez la page dans une fenêtre de navigation privée (Ctrl + Maj + N dans Chrome et Edge, Ctrl + Maj + P dans Firefox, Cmd + Maj + N dans Safari). Les fenêtres privées démarrent sans cookies, sans fichiers en cache et généralement sans extensions : si la page y fonctionne, la solution 2, la solution 4 ou la suppression des fichiers en cache (Ctrl + Maj + Suppr → Images et fichiers en cache) réglera le problème durablement.

Si la navigation privée échoue aussi, vos cookies, votre cache et vos extensions ne sont pas en cause : vérifiez de nouveau l'URL, désactivez tout VPN ou proxy et, en dernier recours, videz votre cache DNS. Le DNS est rarement la cause d'une erreur 400, mais après un changement de serveur d'un site, une adresse obsolète peut vous envoyer vers un serveur qui rejette votre requête.

Solution 4 : désactivez les extensions et vérifiez la taille des fichiers

Les extensions qui modifient les requêtes, comme les outils de confidentialité, les éditeurs d'en-têtes, les chercheurs de codes promo et certains bloqueurs de publicités, peuvent ajouter ou modifier des en-têtes d'une manière que le serveur rejette. Désactivez-les toutes, rechargez la page, puis réactivez-les une par une pour trouver la coupable.

Si l'erreur apparaît lors d'un envoi de fichier, essayez un fichier plus petit. Compressez les images ou découpez les gros fichiers. Cela vous indique si le serveur rejette la taille, même s'il la signale par une erreur 400 au lieu d'une 413.

Pour les propriétaires de sites : trouver la cause des erreurs 400

Si des utilisateurs signalent des erreurs 400 sur votre site, partez du message exact qu'ils voient et de vos logs serveur. nginx journalise la raison au niveau info ; Apache journalise les en-têtes trop volumineux au niveau info, mais les URL et en-têtes mal formés seulement au niveau debug. Relevez donc temporairement le niveau du log d'erreurs si vous ne la voyez pas (error_log … info; dans nginx, LogLevel debug dans Apache). Le log d'accès indique quelles URL renvoient 400. Le Vérificateur d'en-têtes HTTP de DNS Robot affiche le code de statut, le logiciel serveur et chaque cookie posé lors d'une première visite, avec sa taille ; les cookies ajoutés plus tard par des scripts, comme ceux d'analytique, n'apparaissent que dans les DevTools de votre navigateur (Application → Cookies).

# Quelles requêtes reçoivent un 400 ? (format de log nginx combined)
sudo awk '$9 == 400 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

# Les raisons journalisées par nginx (nécessite error_log ... info;)
sudo grep -i "client sent\|too large\|bad request" /var/log/nginx/error.log | tail -20

« Request Header Or Cookie Too Large »

nginx lit les en-têtes de requête dans des tampons définis par large_client_header_buffers, par défaut 4 tampons de 8 Ko. Un champ d'en-tête qui ne tient pas dans un tampon, généralement l'en-tête Cookie, déclenche cette erreur 400, tout comme des en-têtes qui exigent plus que les 4 tampons réunis (environ 32 Ko) ; une ligne de requête (l'URL) trop longue donne en revanche une erreur 414 (nginx). La limite équivalente d'Apache est LimitRequestFieldSize, 8 190 octets par défaut (Apache).

Nous l'avons testé sur nginx.org lui-même (nginx 1.31.3) le 27 octobre 2026 : une requête avec un cookie de 7 000 octets a reçu la page normale, et une requête avec un cookie de 9 000 octets a reçu exactement ceci :

<html>
<head><title>400 Request Header Or Cookie Too Large</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<center>Request Header Or Cookie Too Large</center>
<hr><center>nginx/1.31.3</center>
</body>
</html>

La bonne solution consiste à envoyer moins : supprimez les cookies dont vous n'avez plus besoin, gardez des cookies de session légers et limitez les cookies aux chemins et sous-domaines qui les utilisent. Si vous avez vraiment besoin d'en-têtes plus volumineux, par exemple pour de gros jetons d'authentification unique (SSO), relevez la limite :

# nginx : bloc http ou serveur par défaut (les autres blocs server peuvent être ignorés)
large_client_header_buffers 4 16k;

# Équivalent Apache : configuration principale ou premier hôte virtuel déclaré
# LimitRequestFieldSize 16380

« The plain HTTP request was sent to HTTPS port »

nginx renvoie cette erreur 400 quand quelque chose envoie du HTTP en clair à un port sur lequel nginx attend du TLS, généralement le 443 ; curl http://nginx.org:443/ affiche la page. Les causes typiques sont un répartiteur de charge ou un proxy qui transfère du trafic http:// vers le port 443, un lien du type http://example.com:443 ou, sur nginx antérieur à 1.25.1, une ligne ssl on; dans un bloc server qui écoute aussi sur le port 80 (la 1.25.1 a supprimé la directive et un nginx plus récent refuse de démarrer avec ; utilisez listen 443 ssl;).

Vérifiez que chaque ligne listen correspond à ce qui arrive dessus : listen 443 ssl; pour le HTTPS et listen 80; pour le HTTP en clair, avec une redirection du 80 vers le 443. Assurez-vous aussi que le proxy placé devant parle HTTPS au port 443 (ou HTTP au port 80).

Erreurs 400 renvoyées par les API

Les API utilisent le code 400 pour les requêtes qui échouent à la validation. Si vous appelez une API, lisez le corps de la réponse, car la plupart des API indiquent quel champ est incorrect. Vérifiez ensuite que vous envoyez un JSON valide, le bon en-tête Content-Type: application/json et tous les paramètres obligatoires.

Si vous développez une API, renvoyez un corps qui nomme le problème (par exemple {"error": "email is required"}), et envisagez 422 Unprocessable Content pour les requêtes bien formées mais sémantiquement invalides, en réservant 400 aux requêtes impossibles à analyser.

400 vs 401, 403, 404, 413, 429 et 431

Nos guides sur les codes voisins : 403 Forbidden, 401 Unauthorized et 429 Too Many Requests. Pour les redirections qui tournent en boucle au lieu d'échouer, consultez ERR_TOO_MANY_REDIRECTS, et le Vérificateur de redirections affiche chaque étape.