Erreur 431 sur WordPress : réduire les en-têtes et retrouver l’accès

Reconnaître un refus lié aux en-têtes de la requête

WordPress affiche « 431 Request Header Fields Too Large », parfois uniquement dans votre navigateur habituel. Le serveur refuse alors des en-têtes de requête trop volumineux, pris ensemble ou pour un champ particulier. Ces informations accompagnent la demande : cookies, authentification ou données ajoutées par un intermédiaire. Le poids d’une image envoyée n’est pas le même objet.

Le résultat recherché est un accès fonctionnel avec des en-têtes de taille maîtrisée, puis la suppression de ce qui les fait grossir. Effacer les cookies peut débloquer une session ; cela ne corrige pas automatiquement le composant qui les accumule. Le guide commence donc par comparer les requêtes et les sessions avant d’envisager une configuration serveur.

Les premiers contrôles se font sans extension ni accès à l’hébergement. Pour corriger un composant WordPress, prévoyez une copie et un compte autorisé. Pour les limites du serveur, l’accès d’administration du service est nécessaire. Sur WordPress.com ou une offre gérée, ce dernier réglage appartient au prestataire. Dans un multisite, des cookies peuvent couvrir plusieurs sous-sites : vérifiez la portée avant une suppression.

Préserver le travail et comprendre l’effet d’un nettoyage

Avant de supprimer des cookies, enregistrez vos brouillons et terminez les opérations en cours qui peuvent l’être sans reproduire le refus. Gardez un relevé privé du panier, des préférences ou de la sélection utile. Des informations de session peuvent disparaître après nettoyage ; la copie d’une URL ne permet pas nécessairement de les récupérer.

Assurez-vous de connaître le moyen de vous reconnecter et de disposer du second facteur si le compte en utilise un. Ne conservez pas les valeurs des cookies d’authentification dans un document partagé pour tenter de restaurer la session ensuite. Ces valeurs peuvent donner accès au compte. Le retour attendu après nettoyage consiste à recréer une session normale par la connexion du site.

Pour les essais de composants et de configuration serveur, gardez une sauvegarde adaptée et notez l’état initial. Travaillez sur une copie dont les envois et les effets commerciaux sont neutralisés. Une visite de lecture suffit au premier diagnostic : il n’est pas nécessaire de répéter un paiement, une suppression ou un import pour faire réapparaître une erreur d’en-tête.

Identifier la requête qui reçoit réellement le statut 431

Dans les outils de développement de Chrome, ouvrez Réseau ou Network avant une consultation simple qui échoue. Activez Preserve log si une redirection suit et gardez le filtre All pour voir aussi bien les documents que les appels Fetch/XHR. La ligne refusée peut être une requête en arrière-plan alors que l’adresse principale semble courte. Relevez son heure et le nom de l’écran sans partager les valeurs d’authentification.

Le statut donne le cadre du diagnostic. Un code 414 concerne l’adresse trop longue ; un code 413 concerne le contenu envoyé. Certains serveurs utilisent aussi 400 pour un champ trop gros : le message exact et les journaux permettront alors de confirmer la limite. La présence du mot cookie sur une page ne suffit pas à conclure.

1. Sélectionnez la ligne qui reçoit 431 et ouvrez Headers ou En-têtes.
2. Relevez l’adresse, la méthode et le statut de cette requête précise.
3. Regardez les noms des Request Headers, notamment Cookie, sans recopier leur valeur dans un ticket public.
4. Notez si le refus suit une première réponse réussie ou apparaît dès la première demande.

Comparer une session neuve avant de modifier la session habituelle

Ouvrez la même page publique dans un profil de navigateur neuf ou une fenêtre privée qui ne possède pas déjà les cookies du site. Fermez d’abord les autres fenêtres privées si elles contiennent une session du même site : les fenêtres d’une session privée peuvent partager ses cookies. Gardez le même nom de domaine et le même chemin. Ce contrôle laisse votre session habituelle intacte et permet d’examiner le rôle de son historique local.

Une réussite dans cette fenêtre est un indice en faveur des données de session, sans preuve définitive. Les extensions du navigateur, les cookies tiers et les règles de connexion peuvent aussi différer. Si le problème touche uniquement l’administration, une page publique réussie ne valide pas encore la requête connectée. Reconnectez-vous seulement si le parcours est normal et autorisé, puis comparez le même écran sans opération sensible.

Si une session neuve reçoit immédiatement le même 431, ne videz pas toutes les données de votre ordinateur. Examinez les autres en-têtes et les intermédiaires. Si elle fonctionne puis échoue après une suite précise de visites, notez cette suite et le nombre d’étapes approximatif. Vous disposez d’un scénario pour retrouver le générateur des données, plus utile qu’un nettoyage répété sans observation.

Retirer un cookie identifié plutôt que toutes les données

Cette première correction convient lorsqu’un cookie de préférence ou d’historique clairement identifié occupe une place excessive. Dans Chrome, Application, Storage, Cookies affiche pour chaque origine le nom, le domaine, le chemin et la taille. Le domaine et le chemin expliquent à quelles requêtes le cookie peut participer. La colonne Size renseigne sur sa taille, mais ne mesure pas à elle seule tous les en-têtes de la requête.

N’effacez pas au hasard un cookie de connexion ou une valeur dont le rôle est inconnu. La suppression ciblée ne garantit pas la récupération de la préférence ; prévoyez de la recréer depuis l’interface normale. Si vous ne pouvez pas identifier un candidat avec confiance, passez au nettoyage du seul site après préservation du travail. Si la page de refus ne permet pas à DevTools de présenter les cookies de l’origine utile, utilisez les réglages du seul site décrits à la section suivante ; ne cherchez pas à contourner le refus en fabriquant une requête authentifiée.

1. Ouvrez Application, puis Storage, Cookies et l’origine concernée.
2. Examinez les noms et tailles ; gardez les valeurs privées.
3. Sélectionnez uniquement le cookie identifié, puis Delete selected ou Supprimer la sélection.
4. Rechargez une consultation simple et vérifiez si le 431 disparaît.
5. Recréez la préférence utile depuis le site, puis contrôlez qu’elle ne fait pas immédiatement revenir le refus.

Réinitialiser les données du seul site si le ciblage est impossible

Si la session neuve fonctionne mais qu’aucun cookie précis n’est identifiable, une réinitialisation limitée au site peut débloquer l’accès. Elle convient après enregistrement du travail et vérification de votre moyen de connexion. Elle peut déconnecter le compte et retirer des préférences ou un état de panier ; il n’existe pas de bouton général permettant de rétablir ces données locales à l’identique.

Dans Chrome sur ordinateur, utilisez le parcours ci-dessous. Vérifiez le domaine recherché avant de confirmer. Des données partagées à l’échelle d’un domaine parent peuvent concerner plusieurs sous-domaines. N’élargissez pas le nettoyage à tous les sites du navigateur pour traiter une seule installation WordPress.

1. Ouvrez le menu de Chrome, puis Paramètres.
2. Allez dans Confidentialité et sécurité, puis Cookies tiers.
3. Choisissez Voir toutes les données et autorisations des sites et recherchez le domaine concerné.
4. À droite de l’entrée exacte, choisissez Supprimer puis confirmez Supprimer après vérification de la portée affichée.
5. Ouvrez à nouveau le site, reconnectez-vous normalement si nécessaire et vérifiez la même requête.
6. Si l’erreur revient après quelques actions, notez ce parcours et poursuivez vers la cause des cookies.

Rechercher pourquoi les cookies se remettent à grossir

Une session nettoyée qui échoue de nouveau après plusieurs visites demande une correction du générateur. Sur la copie, observez le parcours qui fait apparaître de nouvelles entrées ou allonge une valeur. Il peut s’agir d’un historique, d’une liste de préférences ou d’un identifiant créé pour chaque interaction. Ne déduisez pas son propriétaire du seul début de son nom ; comparez avec le comportement documenté du composant.

La portée compte autant que le nombre. Des cookies peuvent être envoyés à plusieurs sous-domaines lorsque leur domaine l’autorise, ou à de nombreux chemins. Un sous-site peut donc subir des données créées ailleurs dans le même domaine. Les cookies concernés par un chemin d’administration peuvent aussi différer de ceux d’une simple page publique.

Gardez les noms, les domaines, les chemins et l’évolution des tailles dans un relevé privé. Une correction peut réduire le volume stocké ou mieux limiter sa portée, mais elle doit être faite par le composant qui connaît ces informations. Ne réécrivez pas toutes les valeurs dans le navigateur pour simuler une réparation. Le résultat attendu est un parcours normal qui cesse d’accumuler des données sans limite.

Comparer le composant sur copie avec une extension facultative

Sans nouvel outil, ouvrez Extensions, Extensions installées sur la copie et désactivez uniquement le suspect. Reprenez le même parcours avec une session d’essai neuve, puis réactivez-le pour confirmer la comparaison. Les cookies déjà présents peuvent continuer à être envoyés après sa désactivation : leur présence ancienne ne prouve pas que le composant désactivé fonctionne encore.

Troubleshooting, de Marius L. J., peut aider à comparer le chargement des composants dans votre session. La version relevée est 1.0.2, avec WordPress 5.8 et PHP 7.1 au minimum, testé jusqu’à WordPress 7.1.4 ; ce ne sont pas des recommandations de versions anciennes. Il ne crée pas une base séparée et ne relève pas une limite serveur. Il ne peut pas agir sur une requête rejetée avant PHP : retrouvez d’abord l’accès avec une session utilisable. Les extensions Must Use restent chargées et un cache peut fausser la comparaison.

1. Si l’aide est nécessaire et compatible, installez le composant officiel depuis Extensions, Ajouter une extension.
2. Ouvrez Outils, Santé du site, Troubleshooting, puis Enable Troubleshooting Mode.
3. Depuis le widget du Tableau de bord ou le menu de diagnostic dans la barre d’administration, réactivez les composants nécessaires un par un et comparez la création des cookies sur le parcours témoin.
4. Terminez avec Disable Troubleshooting Mode dans le widget ou la barre d’administration, puis confirmez le résultat sur la copie en contexte normal.

Examiner les autres en-têtes lorsqu’une session vide échoue

Cookie n’est pas le seul champ susceptible d’être trop volumineux. Une authentification d’entreprise, un jeton d’intégration ou un intermédiaire peut ajouter une information importante. Si une session sans historique reçoit le même refus, relevez les noms des champs présents et faites comparer le contexte qui réussit avec celui qui échoue.

Distinguez les en-têtes envoyés par le navigateur de ceux ajoutés plus loin par un proxy. Le navigateur ne montre pas nécessairement toutes les transformations du trajet vers l’origine. Une répétition peut aussi être introduite entre deux services, sans apparaître comme plusieurs cookies dans Application. Le responsable doit rapprocher les deux côtés du trajet pour confirmer ce mécanisme.

Ne raccourcissez pas manuellement un jeton Authorization et ne retirez pas un en-tête de contrôle pour obtenir une réponse. La requête pourrait alors utiliser une autre identité ou perdre une protection nécessaire. Si un composant génère un jeton excessif, corrigez son mécanisme documenté. Si une chaîne d’intermédiaires duplique des champs, corrigez cette chaîne avec son état initial conservé. Une hausse de plafond ne fait que retarder une croissance qui continue.

Identifier la couche qui applique réellement le plafond

Avant de toucher au serveur, faites rapprocher le domaine, l’heure et la requête avec les journaux du CDN, du proxy et de l’origine. Une page portant un logo serveur n’établit pas à elle seule quel service a rejeté les en-têtes. L’adresse peut traverser plusieurs couches avec des limites différentes.

Si le refus est enregistré sur le premier proxy et que l’origine ne reçoit pas la requête, une modification de PHP ou du dernier serveur n’aura aucun effet sur ce rejet. Si l’origine reçoit des champs enrichis par le proxy, il faut mesurer leur taille à cet endroit. Évitez un essai qui contourne une protection en exposant publiquement l’adresse directe d’origine.

Le parcours de configuration convient à une requête légitime dont les en-têtes sont bornés et nécessaires. Conservez le fichier actif, la valeur initiale et le mécanisme qui génère éventuellement cette configuration. Ne modifiez qu’une couche à la fois. Sur un hébergement géré, le responsable doit utiliser le réglage durable prévu par son panneau plutôt qu’une copie de fichier qui sera écrasée.

Adapter Apache pour un champ légitime identifié

Ce parcours exige un accès d’administration à Apache, confirmé comme couche bloquante. LimitRequestFieldSize limite la taille d’un champ de requête ; la valeur standard documentée est 8 190 octets. Elle se règle dans la configuration serveur ou d’un hôte virtuel, jamais dans .htaccess. En hébergement nommé, la valeur du premier hôte correspondant à l’adresse et au port peut s’appliquer.

L’exemple de 16 384 octets est illustratif. Il ne corrige pas une multiplication de cookies et ne remplace pas le diagnostic d’une limite sur l’ensemble ou sur le nombre de champs. Le fichier doit être celui effectivement chargé par le service.

1. Conservez la configuration active et la valeur initiale du champ identifié.
2. Modifiez seulement la définition effective avec une valeur proportionnée au besoin confirmé.
3. Contrôlez avec apachectl configtest en utilisant le binaire, les chemins et les droits de l’instance réellement exploitée. Le résultat attendu est Syntax OK ; en cas d’échec, corrigez ou restaurez le fichier sans recharger.
4. Après réussite, appliquez par la procédure d’exploitation ; une installation standard peut utiliser apachectl graceful.
5. Si l’essai est inutile ou défavorable, restaurez la valeur, contrôlez puis appliquez le retour.

LimitRequestFieldSize 16384

Adapter Nginx en tenant compte du champ et de l’ensemble

Avec Nginx confirmé responsable, large_client_header_buffers définit des tampons pour les en-têtes clients. La documentation donne 4 8k par défaut. Un champ doit tenir dans un tampon ; augmenter seulement leur nombre ne résout pas un champ individuel trop grand. Le refus peut apparaître sous un statut 400 sur cette couche, même si une autre couche emploie 431.

La directive appartient aux contextes http ou server, avec une influence possible du serveur par défaut. L’exemple de taille ci-dessous ne va ni dans location, ni dans PHP, ni dans .htaccess. Il reste à dimensionner selon la mesure et les ressources autorisées. Ces vérifications ne nécessitent pas de publier la configuration complète : évitez de joindre une sortie nginx -T, qui la révèle, à un ticket public.

1. Conservez la configuration et identifiez la définition réellement appliquée.
2. Adaptez la taille pour un champ trop grand, ou le dimensionnement correspondant à l’ensemble, selon le diagnostic.
3. Vérifiez avec nginx -t, avec les mêmes paramètres de configuration et de préfixe que le service. Attendez le contrôle réussi ; s’il échoue sur une syntaxe ou un fichier inaccessible, ne rechargez pas.
4. Après réussite, rechargez selon l’exploitation ; une installation standard peut utiliser nginx -s reload.
5. En cas d’échec ou d’absence d’amélioration, restaurez l’ancienne définition puis contrôlez et rechargez le retour.

large_client_header_buffers 4 16k;

Valider le parcours complet après la correction

Reprenez la requête exacte qui recevait le refus, avec une session normale. Vérifiez son statut puis la fonction attendue : une page d’erreur renvoyée avec un statut 200 ne constitue pas une réussite. Si le problème concernait l’administration, ouvrez cet écran avec le même compte après reconnexion. Une page publique en cache ne valide pas le trajet connecté.

Si des cookies ont été supprimés, parcourez de nouveau les étapes qui provoquaient leur accumulation. Observez leur nombre et leurs tailles après plusieurs interactions représentatives, sans provoquer d’opération commerciale réelle. Le retour immédiat du refus indique que le nettoyage a seulement réinitialisé le compteur. Recherchez alors le composant responsable au lieu de recommencer l’effacement.

Si une limite serveur a été adaptée, vérifiez les journaux de cette couche et une fonction voisine. Documentez la valeur retenue et retirez les changements temporaires qui n’ont pas contribué au résultat. Le retour arrière d’une configuration consiste à restaurer sa définition initiale, puis à la vérifier et à la recharger. Il ne restaure pas les préférences locales supprimées. Gardez les deux opérations séparées dans le relevé d’intervention.

Prévenir l’accumulation et transmettre une preuve exploitable

Conservez le composant qui crée chaque famille de cookies utile, sa portée et le parcours qui a été vérifié. Lors d’une mise à jour ajoutant un historique, une personnalisation ou une intégration, contrôlez que le volume reste borné. Un cookie par interaction peut devenir problématique avec le temps même si une visite neuve paraît normale.

Pour un ticket, fournissez le statut exact, le domaine, le chemin, l’heure avec fuseau et le type de session. Ajoutez les noms de champs concernés et des mesures expurgées, pas leurs secrets. Indiquez si une session neuve réussit, si le nettoyage du seul site change le résultat et après quelles actions le problème revient. Une capture complète des en-têtes ou un fichier de diagnostic peut contenir des informations de connexion ; préparez une version limitée aux preuves nécessaires.

Pour l’hébergement, précisez la couche confirmée et la limite atteinte, avec le réglage initial et celui essayé. Pour un composant, donnez le scénario de croissance sur copie et sa version. La réparation durable associe un accès rétabli à un volume qui reste maîtrisé. Elle ne repose pas sur une habitude d’effacer toutes les données du navigateur chaque fois que le site refuse la session.