El mensaje genérico «Error HTTP» puede representar límite de tamaño, timeout, permisos, disco o inodos agotados, falta de memoria al procesar imágenes, bloqueo del cortafuegos o respuesta REST o AJAX inválida. El estado real y el registro PHP permiten distinguirlos.
Conserva un archivo de prueba seguro y sus dimensiones antes de cambiar todos los límites.
Construye una matriz controlada
Prueba un JPEG o PNG pequeño creado por ti y después el archivo que falla. Anota extensión, bytes, dimensiones y modo de color.
Compara:
imagen pequeña y fallida
JPEG, PNG o WebP compatibles
cargador del navegador y Medios > Añadir nuevo
mismo usuario y otro rol autorizadoNo subas documentos confidenciales durante el diagnóstico.
Inspecciona la petición
Abre Red y anota endpoint, estado, respuesta y duración. WordPress puede usar async-upload.php o REST según el contexto.
Un 413 indica tamaño en proxy o servidor; 403, cortafuegos o permisos; 500, PHP; un timeout, procesamiento. Una respuesta 200 con HTML inválido también puede generar «Error HTTP».
Oculta cookies y nonces y no publiques URLs privadas.
Compara los límites efectivos
Revisa upload_max_filesize, post_max_size, memoria, tiempo de ejecución y límite de cuerpo de servidor o CDN en el PHP web activo.
post_max_size debe incluir toda la petición y superar el archivo. Subir el límite PHP no cambia el de Nginx o Cloudflare.
Usa cPanel, Plesk o configuración compatible y conserva límites justificados.
Revisa disco, inodos y temporales
PHP escribe primero en una carpeta temporal y WordPress mueve después a uploads. Ambas necesitan espacio, inodos y permisos.
Busca las líneas exactas «failed to write» u «open_basedir». No utilices 777 recursivo.
Las copias y cachés pueden llenar la cuota aunque uploads sea pequeño.
Inspecciona el procesamiento de imagen
Tras subir, WordPress genera tamaños mediante GD o Imagick. Una imagen comprimida de alta resolución puede consumir cientos de megabytes al decodificarse.
Busca errores de memoria y biblioteca. Reduce dimensiones antes de subir y elimina tamaños innecesarios mediante código mantenido.
No desactives la validación MIME para aceptar un archivo problemático.
Comprueba tipo y seguridad
Confirma que extensión, MIME y bytes reales coinciden. WordPress limita los tipos según el rol.
Revisa de forma precisa los filtros propios:
add_filter( 'upload_mimes', function ( $mimes ) {
// Add only a business-required, safely handled type.
return $mimes;
} );No permitas PHP ejecutable ni formatos peligrosos.
Relaciona cortafuegos y REST o AJAX
ModSecurity puede marcar nombres o metadatos, y un plugin puede bloquear endpoints. Busca hora e ID.
Crea una corrección estrecha y conserva escaneo y límites. Prueba la inserción desde el editor si utiliza REST.
Excluye las respuestas autenticadas de la caché pública.
Revisa EXIF y metadatos
WordPress puede leer EXIF o IPTC para título, pie y rotación. Metadatos mal formados pueden hacer fallar un solo archivo después de subir sus bytes.
Crea una copia sin metadatos y compara. No borres indiscriminadamente campos de producción; algunos reflejan copyright. Las fotos pueden incluir GPS, así que define quién accede a los originales.
Comprueba cuotas de multisitio y rol
Multisitio puede limitar tipos, tamaño máximo y almacenamiento por sitio independientemente de PHP. El administrador de red y el del sitio pueden obtener resultados distintos.
Revisa la configuración y cuota actual. Amplía solo por necesidad y confirma almacenamiento y copias. No concedas unfiltered_upload de forma amplia.
Verifica todo el ciclo del medio
Sube imágenes representativas, comprueba metadatos, miniaturas, inserción y acceso público o privado. Prueba el borrado y regenera solo los tamaños necesarios.
Vigila disco, inodos, fatales y errores de subida. El mantenimiento recurrente debe definir pautas de medios y alertas; que funcione un archivo pequeño no demuestra que los recursos editoriales normales se procesen con seguridad.