L’errore 406 Not Acceptable indica, secondo HTTP, che il server non può produrre una rappresentazione compatibile con le preferenze indicate dal client. Nella pratica hosting viene talvolta utilizzato anche da WAF o applicazioni per rifiutare contenuti considerati non accettabili.
Questa guida approfondisce errore 406 Not Acceptable con controlli progressivi, modifiche reversibili e verifiche finali. Non inviare password, cookie, token, chiavi private o codici 2FA nei ticket.
Che cosa significa
Gli header Accept, Accept-Language e Accept-Encoding possono influenzare la negoziazione. Tuttavia un 406 durante il salvataggio di testo, codice o form può essere collegato a ModSecurity.
Il messaggio e i log devono stabilire quale interpretazione si applica al caso specifico.
Come riconoscere il problema
- Una API restituisce 406 per un formato richiesto.
- Il salvataggio fallisce solo con una stringa specifica.
- Il log mostra ModSecurity access denied.
- Il browser funziona ma un client personalizzato no.
- Cambiare l’header Accept modifica il risultato.
Cause più frequenti
1. Header Accept non supportato
Il client richiede un formato che l’endpoint non produce. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
2. Content negotiation errata
Lingua, codifica o media type non corrispondono. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
3. Regola ModSecurity
Il payload somiglia a SQL injection, XSS o codice. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
4. Plugin di sicurezza
Un filtro applicativo restituisce 406 invece di 403. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
5. API configurata male
Il server accetta soltanto JSON o un formato specifico. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
6. Cache con variazione incompleta
Una risposta per un header viene servita a client differenti. 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
- Controlla header Accept. Confronta browser e client che fallisce. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Leggi corpo e intestazioni. Identifica server, endpoint e formato atteso. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Registra orario e payload minimo. Riduci il contenuto finché individui la parte che scatena il blocco. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Controlla error_log e audit WAF. Cerca rule id e messaggio. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Prova un media type supportato. Usa la documentazione ufficiale dell’API. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Verifica plugin di sicurezza. Riproduci in staging senza disattivazioni globali. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Controlla Vary e cache. Assicurati che le risposte siano separate per gli header pertinenti. 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
- Correggi Accept. Richiedi un formato realmente supportato. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Invia Content-Type coerente. Distingui il formato richiesto da quello inviato. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Correggi il payload. Rimuovi markup o dati non validi quando possibile. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Richiedi esclusione WAF mirata. Fornisci URL, parametro e rule id. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Aggiorna plugin o API client. Usa versioni compatibili. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Correggi cache e header Vary. Evita rappresentazioni sbagliate. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Mantieni il WAF attivo. Verifica che l’eccezione non permetta input pericolosi. 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
- Il client riceve il formato previsto.
- Il contenuto legittimo viene salvato.
- Il WAF continua a bloccare payload pericolosi.
- La cache varia correttamente.
- Nessun nuovo 406 nei log legittimi.
Prevenzione
- Documenta media type.
- Testa API.
- Aggiorna regole WAF.
- Usa esclusioni minime.
- Monitora codici 406.
Errori da evitare
- Non disattivare ModSecurity globalmente.
- Non impostare Accept */* senza comprendere l’API.
- Non pubblicare payload sensibili.
- Non confondere 406 e 415.
- Non ignorare il rule id.
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 o endpoint
- metodo HTTP
- header Accept e Content-Type
- orario
- rule id o payload minimo oscurato
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 406 Not Acceptable
Il 406 dipende sempre da ModSecurity?
No. Può essere una reale negoziazione del contenuto non supportata.
Qual è la differenza tra Accept e Content-Type?
Accept indica il formato desiderato in risposta; Content-Type descrive il corpo inviato.
Posso disattivare il WAF?
È preferibile identificare la regola e applicare una esclusione minima.
Perché una parola specifica causa 406?
Può corrispondere a un pattern della regola di sicurezza.
Che cosa devo allegare al ticket?
Endpoint, metodo, orario, header, rule id e un esempio minimo non sensibile.