L’errore 400 Bad Request indica che il server ha ricevuto una richiesta che considera non valida e non può elaborarla. La causa può trovarsi nel browser, nei cookie, nella sintassi dell’URL, negli header HTTP, in un proxy, nella CDN o nell’applicazione.
Questa guida approfondisce errore 400 Bad Request con controlli progressivi, modifiche reversibili e verifiche finali. Non inviare password, cookie, token, chiavi private o codici 2FA nei ticket.
Che cosa significa
Ripetere la stessa richiesta senza modificarla normalmente produce lo stesso risultato. Prima di intervenire sul server bisogna capire se l’errore riguarda un singolo browser, una sola URL o tutte le richieste del sito.
Una pagina 400 generata da Cloudflare, LiteSpeed, un plugin o una API può avere aspetto e intestazioni differenti. Identificare il livello che risponde riduce molto il campo di ricerca.
Come riconoscere il problema
- Il sito funziona in finestra anonima ma non nella sessione normale.
- Una URL lunga o con caratteri particolari restituisce 400.
- L’errore compare durante login, upload, API o salvataggio.
- Solo una rete, un proxy o una CDN mostra il problema.
- Il registro segnala request header too large o malformed request.
Cause più frequenti
1. Cookie corrotti o troppo grandi
Cookie vecchi, duplicati o creati da plugin possono rendere eccessiva o incoerente la richiesta. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
2. URL o query string non valida
Caratteri non codificati, parametri troncati o link costruiti male possono essere rifiutati. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
3. Header HTTP eccessivi
Cookie, token e intestazioni personalizzate possono superare i limiti del web server o del proxy. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
4. Richiesta malformata
Un client, bot o plugin può inviare sintassi HTTP non conforme. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
5. Proxy, CDN o WAF
Il livello frontale può normalizzare o rifiutare richieste che l’origine accetterebbe. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
6. Plugin o integrazione WordPress
Form, REST API o autenticazione possono generare parametri non previsti. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
Diagnosi passo per passo
- Prova una finestra anonima. Confronta la stessa URL senza i cookie della sessione. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Controlla il codice e le intestazioni. Usa gli strumenti sviluppatore o curl per identificare server e risposta. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Riduci la URL. Rimuovi parametri uno alla volta e verifica caratteri speciali e codifica. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Controlla error_log e access log. Cerca malformed request, header too large, invalid URI e rule id. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Confronta origine e CDN. Verifica se il 400 è generato prima di raggiungere il server. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Disattiva il componente sospetto in staging. Riproduci il form o la chiamata API senza il plugin recente. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Controlla dimensione di cookie e header. Individua nomi duplicati, token molto lunghi e domini cookie errati. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
Metodo sicuro di diagnosi
Prima di applicare modifiche, registra lo stato iniziale: URL o servizio coinvolto, messaggio completo, data e ora, rete o client, ultima operazione eseguita e risultato da un secondo strumento. Questo consente di distinguere una causa locale da una configurazione condivisa e rende possibile il rollback.
Cambia un solo elemento alla volta. Dopo ogni intervento ripeti esattamente lo stesso test, controlla i log dello stesso intervallo temporale e annota il risultato. Modificare contemporaneamente DNS, cache, PHP, plugin e firewall rende impossibile stabilire quale correzione abbia avuto effetto.
Controllo incrociato
Usa almeno due fonti indipendenti. Per HTTP confronta browser, curl e log; per WordPress confronta frontend, wp-admin e WP-CLI; per DNS interroga nameserver autoritativo e resolver pubblico; per la posta confronta header, Webmail e Track Delivery. Cache e proxy possono mostrare stati differenti per alcuni minuti.
Quando il problema sembra risolto, ripeti il test con una seconda rete o un secondo account e verifica che le protezioni restino attive. Una soluzione che disabilita globalmente TLS, WAF, autenticazione o controlli di sicurezza non è considerata definitiva.
Procedura di risoluzione
- Elimina i cookie del dominio. Rimuovi soltanto i dati del sito e ripeti il login. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Correggi URL e parametri. Codifica correttamente i valori e limita lunghezza e duplicazioni. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Riduci gli header. Correggi plugin o autenticazione che generano cookie e token eccessivi. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Aggiorna client e plugin. Versioni recenti possono correggere richieste non conformi. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Correggi la regola WAF. Applica una esclusione mirata soltanto dopo aver identificato la regola. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Allinea proxy e origine. Verifica hostname, protocollo e trasformazioni delle intestazioni. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Ripeti il test controllato. Usa lo stesso browser e la stessa richiesta dopo una sola modifica. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
Verifica della stabilità dopo l’intervento
Non fermarti al primo test riuscito. Ripeti l’operazione dopo aver aperto una nuova sessione, svuotato soltanto la cache pertinente e atteso l’eventuale scadenza del TTL o del rate limit. Controlla inoltre che una seconda pagina, un secondo utente o un secondo destinatario non presentino ancora il problema.
Conserva per almeno il tempo necessario il backup e la configurazione precedente. Se l’anomalia ricompare, confronta orario, log e processo pianificato: una ricorrenza regolare può dipendere da cron, rinnovi, rotazioni, cache rigenerate o servizi esterni.
Controlli finali
- La URL restituisce la risposta prevista.
- Il problema non ricompare dopo un nuovo login.
- Le richieste API e i form funzionano.
- Nessun nuovo errore appare nei log.
- CDN e origine restituiscono un risultato coerente.
Prevenzione
- Limita cookie e token.
- Valida e codifica gli input.
- Aggiorna plugin e client.
- Monitora i 4xx nei log.
- Testa regole CDN e WAF.
Errori da evitare
- Non aumentare tutti i limiti senza diagnosi.
- Non disattivare il WAF globalmente.
- Non cancellare tutti i dati del browser se basta il dominio.
- Non ignorare richieste anomale dei bot.
- Non pubblicare cookie o token nei ticket.
Quando contattare l’assistenza Xlogic
Apri un ticket quando il problema persiste dopo i controlli di base, coinvolge più servizi o richiede log e configurazioni non disponibili nel pannello. Indica:
- URL completa oscurando token
- data e ora
- browser o applicazione
- intestazioni rilevanti senza credenziali
- estratto del log
Non inviare credenziali. URL, orari, codici, header non sensibili e messaggi di errore sono sufficienti per iniziare la diagnosi.
Fonti tecniche ufficiali
Verifica prolungata dopo la correzione
Una singola prova riuscita non dimostra che il problema sia definitivamente risolto. Ripeti l’operazione dopo una nuova sessione, da una seconda rete o con un secondo utente quando applicabile. Per DNS e posta considera anche TTL, code e cache dei resolver; per HTTP e WordPress controlla una pagina dinamica, una funzione amministrativa e il relativo registro degli errori.
Conserva temporaneamente il backup, i valori precedenti e gli estratti dei log. Se l’anomalia ricompare, confronta l’orario con cron, backup, aggiornamenti, rinnovi SSL, rotazioni DNS, code email e servizi esterni. Una ricorrenza regolare è spesso più significativa del messaggio mostrato durante il singolo evento.
Prima di chiudere l’intervento verifica inoltre che le misure di sicurezza siano ancora operative: HTTPS valido, autenticazione richiesta, WAF attivo, permessi non eccessivi e nessun endpoint di debug o manutenzione lasciato pubblico. La soluzione deve correggere la causa senza ridurre stabilmente le protezioni del servizio.
Domande frequenti su errore 400 Bad Request
Un errore 400 dipende sempre dal browser?
No. Può essere generato dal web server, dalla CDN, dal WAF o dall’applicazione.
Perché la finestra anonima funziona?
Non utilizza normalmente gli stessi cookie e dati della sessione principale.
Svuotare tutta la cache risolve?
Non necessariamente. I cookie sono spesso più rilevanti della cache dei file.
Una URL troppo lunga può causare 400?
Sì, in base ai limiti applicati da browser, proxy e server.
Quali dati servono all’assistenza?
URL, orario, client, intestazioni non sensibili e messaggio del log.