Errore 431 Request Header Fields Too Large

Questa guida approfondisce errore 431 Request Header Fields Too Large con verifiche progressive e reversibili. Non inviare password, cookie, token, chiavi private, codici 2FA o file di configurazione completi nei ticket.

Che cosa significa

Il 431 può essere generato dal web server, da un proxy o dalla CDN prima che WordPress venga eseguito. Per questo il log PHP può non contenere nulla.

Cookie duplicati, token di autenticazione molto lunghi, plugin che accumulano stato e domini cookie troppo ampi possono far crescere gli header nel tempo.

Come riconoscere il problema

• La finestra anonima funziona.
• Eliminando i cookie del dominio il sito torna accessibile.
• Solo un browser o profilo mostra il 431.
• La risposta arriva prima di PHP.
• Il problema compare dopo numerosi login, test o plugin di tracking.

Cause più frequenti

1. Cookie numerosi o grandi

Sessioni, preferenze e tracking superano la soglia. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.

2. Cookie duplicati

Varianti www, non-www, path e domini generano copie. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.

3. Token JWT e autenticazione

Valori molto lunghi vengono inviati in Authorization o cookie. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.

4. Plugin WordPress

Sicurezza, consenso o e-commerce accumulano dati. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.

5. Proxy e CDN

Ogni livello ha limiti propri per singolo header e totale. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.

6. Header personalizzati

Un client API aggiunge metadati eccessivi. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.

Diagnosi passo per passo

1. Prova una sessione anonima. Escludi i cookie memorizzati. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
2. Esporta l’elenco cookie. Controlla dimensione, dominio, path e duplicati senza condividere valori. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
3. Leggi gli header della richiesta. Usa DevTools e misura Cookie e Authorization. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
4. Identifica il livello che risponde. Controlla Server, ray ID e log. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
5. Disattiva il plugin sospetto in staging. Verifica quale cookie ricompare. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
6. Controlla Set-Cookie. Cerca loop che aggiungono valori a ogni risposta. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
7. Testa hostname canonico. Riduci duplicazioni tra www e non-www. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.

Metodo sicuro di diagnosi

Prima di modificare la configurazione, registra URL o servizio coinvolto, messaggio completo, data e ora, ultima modifica nota, client o rete e risultato ottenuto con un secondo strumento. Questa fotografia iniziale permette di confrontare i test e di tornare alla configurazione precedente quando una modifica non produce il risultato atteso.

Applica una sola correzione alla volta. Dopo ogni intervento ripeti esattamente la stessa operazione e controlla i log dello stesso intervallo temporale. Modificare contemporaneamente DNS, cache, PHP, plugin, proxy e firewall elimina la possibilità di attribuire il risultato a una causa precisa.

Controllo incrociato

Usa almeno due fonti indipendenti. Per HTTP confronta browser, curl e log; per WordPress confronta frontend, wp-admin, Site Health e WP-CLI; per DNS interroga nameserver autoritativi e resolver pubblici; per la posta confronta Webmail, intestazioni originali e Track Delivery. Cache, TTL e code possono mostrare stati differenti per alcuni minuti.

Quando il problema sembra risolto, esegui una seconda prova con una nuova sessione, un secondo utente o una seconda rete quando applicabile. Verifica inoltre che TLS, autenticazione, WAF, permessi e controlli antispam restino attivi: una correzione che disabilita stabilmente le protezioni non è una soluzione definitiva.

Verifica prolungata dopo la correzione

Conserva temporaneamente backup, valori precedenti ed estratti dei log. Ripeti il controllo dopo il normale ciclo di cache, cron, coda o TTL. Se l’anomalia ricompare a intervalli regolari, confronta l’orario con backup, aggiornamenti, rinnovi SSL, rotazioni DNS, processi pianificati e servizi esterni.

Documenta il risultato finale con data, comando o schermata utilizzata e condizione verificata. Questa nota evita interventi duplicati e rende più rapida una futura analisi da parte dell’assistenza.

Procedura di risoluzione

1. Elimina i cookie del dominio. Riparti da una sessione pulita. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
2. Correggi plugin e cookie. Riduci dati, durata, path e dominio. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
3. Usa storage appropriato. Non memorizzare grandi payload nei cookie. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
4. Riduci token e header. Mantieni soltanto claim e metadati necessari. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
5. Allinea hostname canonico. Evita cookie duplicati su varianti del dominio. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
6. Aumenta il limite solo dopo la correzione. Non trasformare una crescita incontrollata in un problema più grande. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
7. Verifica CDN e origine. Mantieni soglie coerenti per richieste legittime. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.

Come raccogliere prove utili

Quando riproduci il problema, conserva soltanto i dati tecnici necessari: codice di risposta, URL priva di token, orario con fuso, request ID, nome del client, dimensione del file o del messaggio e una breve descrizione dell’operazione. Evita screenshot parziali quando puoi esportare il testo originale, perché header, log e messaggi completi permettono una diagnosi più precisa.

Prima di chiudere il controllo, confronta il comportamento con una configurazione nota e funzionante. Per una API usa un payload minimo; per WordPress prova una funzione core senza plugin aggiuntivi; per DNS interroga direttamente i nameserver; per la posta usa Webmail e conserva il file `.eml`. Questo confronto riduce le ipotesi e impedisce modifiche inutili.

Controlli finali

• La sessione normale funziona.
• I cookie restano sotto soglia.
• Nessun Set-Cookie cresce a ogni richiesta.
• CDN e origine rispondono coerentemente.
• Autenticazione continua a funzionare.

Prevenzione

• Cookie piccoli.
• Sessioni scadute.
• Hostname unico.
• Audit dei plugin.
• Monitoraggio header.

Errori da evitare

• Non pubblicare cookie e token.
• Non alzare limiti senza analisi.
• Non cancellare dati di tutti i siti del browser.
• Non disattivare autenticazione.
• Non confondere 431 e 414.

Quando contattare l’assistenza Xlogic

Apri un ticket quando il problema persiste dopo i controlli di base, coinvolge più servizi oppure richiede log e configurazioni non disponibili nel pannello. Indica:

• dominio e URL
• browser
• dimensione approssimativa header
• orario
• plugin e livello che risponde

Non inviare credenziali. URL, orari, codici, header non sensibili e messaggi di errore sono sufficienti per iniziare la diagnosi.

Fonti tecniche ufficiali

• MDN: 431 Request Header Fields Too Large
• IETF RFC 6585

Domande frequenti su errore 431 Request Header Fields Too Large