Errore HTTP caricando immagini in WordPress

Questa guida approfondisce errore HTTP immagini WordPress con verifiche progressive e reversibili. Non inviare password, cookie, token, chiavi private, codici 2FA o file di configurazione completi nei ticket.

Che cosa significa

Immagini ad altissima risoluzione possono richiedere molta memoria decompressa anche se il file pesa pochi megabyte. Formato, numero di pixel, profilo colore e libreria GD o Imagick influenzano il consumo.

Il codice reale può essere 403, 413, 500 o un timeout. DevTools, error_log e log WAF permettono di sostituire il messaggio generico con una diagnosi precisa.

Come riconoscere il problema

• File piccoli funzionano e immagini grandi no.
• L’upload raggiunge il 100% e poi fallisce.
• Il media è presente ma mancano miniature.
• Solo un formato causa l’errore.
• La risposta XHR mostra 403, 413 o 500.

Cause più frequenti

1. Memoria insufficiente

La decodifica dell’immagine supera memory_limit. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.

2. Dimensioni e formato

Pixel estremi, file corrotto o formato non supportato. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.

3. Imagick o GD

Estensione mancante, policy o errore della libreria. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.

4. Permessi uploads

WordPress non può creare file o directory. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.

5. WAF o ModSecurity

Nome, metadata o payload vengono filtrati. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.

6. Proxy, timeout o limiti upload

La richiesta viene interrotta prima dell’elaborazione. 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. Controlla la richiesta XHR. Leggi codice e corpo della risposta. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
2. Prova una immagine piccola e standard. Per esempio JPEG RGB. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
3. Controlla pixel e integrità. Apri e riesporta il file localmente. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
4. Leggi error_log. Cerca memoria, Imagick, permission denied e timeout. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
5. Verifica Site Health e moduli. Controlla GD, Imagick e versione PHP. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
6. Controlla uploads e quota. Permessi, proprietario, spazio e inode. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
7. Consulta log WAF. Correla URL, IP, orario e rule ID. 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. Ridimensiona e riesporta l’immagine. Riduci pixel e rimuovi metadata non necessari. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
2. Aumenta memory_limit con criterio. Solo se il log conferma memoria esaurita. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
3. Abilita o aggiorna Imagick/GD. Usa moduli compatibili. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
4. Correggi permessi e proprietario. Senza 777. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
5. Applica esclusione WAF mirata. Soltanto per una regola falsa positiva. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
6. Allinea limiti upload e timeout. Controlla PHP, proxy e CDN. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
7. Rigenera le miniature. Dopo aver corretto il problema di elaborazione. 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

• Upload completato.
• Miniature generate.
• Media accessibile.
• Nessun fatal error.
• WAF attivo.

Prevenzione

• Ottimizza immagini.
• Moduli aggiornati.
• Spazio libero.
• Monitoraggio log.
• Formati supportati.

Errori da evitare

• Non caricare originali enormi senza necessità.
• Non usare 777.
• Non disattivare ModSecurity globalmente.
• Non aumentare memoria senza log.
• Non ignorare miniature mancanti.

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:

• file di test o dimensioni
• URL e orario
• codice XHR
• errore log
• modulo immagini

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

Fonti tecniche ufficiali

• WordPress wp_handle_upload
• WordPress Media Settings

Domande frequenti su errore HTTP immagini WordPress