L’errore 413 Content Too Large indica che il corpo della richiesta supera il limite accettato da uno dei componenti attraversati. Può essere generato da CDN, reverse proxy, web server, PHP o applicazione prima che il file venga elaborato.
Questa guida approfondisce errore 413 Content Too Large con controlli progressivi, modifiche reversibili e verifiche finali. Non inviare password, cookie, token, chiavi private o codici 2FA nei ticket.
Che cosa significa
Il 413 è distinto dall’avviso PHP upload_max_filesize exceeded. Se il proxy rifiuta la richiesta, PHP e WordPress potrebbero non ricevere nulla e non registrare un errore applicativo.
La dimensione da considerare può includere il file, i campi del form, la codifica multipart e più allegati.
Come riconoscere il problema
- Un upload grande restituisce 413.
- File piccoli funzionano.
- WordPress non registra il tentativo.
- La pagina di errore porta il marchio della CDN.
- post_max_size è alto ma il problema resta.
Cause più frequenti
1. Limite CDN
Il provider frontale impone una dimensione massima per 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. Reverse proxy o web server
Il corpo supera il valore accettato dal livello HTTP. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
3. post_max_size
PHP scarta l’intera richiesta quando supera la soglia. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
4. Limite applicativo
Plugin, API o form impongono una dimensione inferiore. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
5. Richiesta multipart più grande
Il totale supera la dimensione apparente del singolo file. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
6. Percorso differente
Un sottodominio o endpoint usa configurazione diversa. 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
- Identifica chi genera il 413. Controlla pagina, header e log. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Misura il corpo completo. Considera più file e campi. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Confronta valori PHP. Verifica post_max_size e upload_max_filesize attivi sul dominio. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Controlla CDN e proxy. Consulta il limite previsto dal servizio. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Prova un file progressivamente più piccolo. Individua la soglia approssimativa. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Controlla endpoint e plugin. Verifica limiti propri dell’applicazione. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Confronta upload web e SFTP. Stabilisci se il problema riguarda esclusivamente HTTP. 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
- Riduci o comprimi il file. Evita richieste inutilmente grandi. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Usa SFTP o CLI. Per backup, archivi e dump di grandi dimensioni. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Aumenta post_max_size in modo coerente. Mantienilo superiore al totale della richiesta. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Modifica il limite del proxy se gestibile. Intervieni soltanto sul virtual host o servizio necessario. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Verifica il piano CDN. Alcuni limiti non sono modificabili dall’origine. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Configura upload a blocchi. Quando l’applicazione lo supporta. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Controlla memoria e timeout. Dopo l’accettazione il file deve essere elaborato correttamente. 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 file previsto viene accettato.
- PHP riceve la richiesta.
- L’applicazione completa l’elaborazione.
- File superiori alla policy restano bloccati.
- Nessun dato sensibile resta in directory pubbliche.
Prevenzione
- Definisci limiti ragionevoli.
- Usa SFTP per archivi.
- Ottimizza media.
- Documenta soglie CDN.
- Controlla PHP dopo cambi versione.
Errori da evitare
- Non impostare limiti enormi senza necessità.
- Non caricare dump in public_html.
- Non confondere 413 e upload_max_filesize.
- Non aggirare la CDN con URL non protetti permanenti.
- Non dimenticare post_max_size.
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 upload
- dimensione file e richiesta
- pagina o header 413
- valori PHP
- CDN o proxy utilizzato
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 413 Content Too Large
Il 413 viene sempre da PHP?
No. Può essere emesso da CDN, proxy o web server prima di PHP.
Perché post_max_size alto non basta?
Un livello precedente può avere una soglia inferiore.
upload_max_filesize e post_max_size sono uguali?
No. Il primo riguarda il singolo file; il secondo l’intera richiesta.
SFTP ha lo stesso limite?
No, non usa l’upload HTTP del sito.
Posso aumentare il limite Cloudflare dal server?
No, i limiti del servizio CDN dipendono dal piano e dalla configurazione Cloudflare.