WordPress no permite subir vídeos solución segura

Contexto del problema al subir vídeos en WordPress

Cuando WordPress rechaza un vídeo, el origen no suele estar en un único punto. Intervienen el tamaño del archivo, el tiempo máximo de ejecución, la memoria disponible, el tipo MIME permitido, la biblioteca multimedia, la caché del servidor y, en algunos casos, reglas de seguridad del hosting o del firewall. Por eso conviene tratarlo como una incidencia técnica de carga de archivos y no como un simple error del editor.

Además, subir vídeos directamente a WordPress no siempre es la opción más eficiente. Si se trata de archivos pesados, el sitio puede sufrir más consumo de disco, copias de seguridad más lentas y mayor presión sobre CPU y ancho de banda. En ámbito general, la recomendación suele ser separar el diagnóstico del error de subida y la decisión estratégica sobre dónde alojar el vídeo.

• El síntoma más común es que la carga se detiene sin completar o devuelve un mensaje genérico.
• El problema puede aparecer solo con vídeos y no con imágenes o PDF.
• Un mismo archivo puede subir en staging y fallar en producción por diferencias de límites.
• La biblioteca multimedia puede mostrar errores de HTTP, permisos o respuesta inesperada del servidor.
• Si el archivo es grande, el fallo puede estar fuera de WordPress y depender del servidor web o de PHP.

Diagnóstico inicial y señales útiles al subir vídeos

El primer paso es identificar si el fallo es reproducible y qué mensaje concreto aparece. Pueden verse avisos como HTTP error, El archivo excede el tamaño máximo de subida para este sitio, respuesta 413, error 500, pantalla en blanco, tiempo de espera agotado o carga infinita. También son señales útiles los avisos del hosting sobre uso de CPU, límites de procesos, memoria o bloqueo por reglas WAF, así como cambios recientes en PHP, plugins, CDN o políticas de seguridad.

Conviene hacer comprobaciones prudentes que no empeoren la situación. Lo razonable es probar con una copia del mismo vídeo más pequeña, revisar el límite que muestra WordPress en Medios, confirmar la versión de PHP, anotar el peso exacto del archivo, comprobar si el error afecta a todos los usuarios o solo a uno, y revisar logs antes de desactivar elementos en producción. Si hay Search Console con avisos de cobertura o seguridad, anótelos, aunque no suelen ser la causa directa de la subida.

• Mensaje visible en pantalla, código HTTP y momento exacto en que falla la subida.
• Picos de CPU, memoria o procesos concurrentes registrados por el hosting.
• Cambios recientes en plugins, tema, PHP, reglas del servidor, CDN o firewall.
• Comparativa entre subir desde administrador, desde otro navegador y desde otro usuario con el mismo rol.
• Prueba controlada con un archivo pequeño y otro cercano al límite esperado, sin repetir decenas de intentos.

Causas habituales y cómo confirmarlas

Las causas más frecuentes son límites de PHP como upload_max_filesize y post_max_size, un valor de client_max_body_size en Nginx o una directiva equivalente en la capa web, un tiempo de ejecución insuficiente, falta de espacio en disco, permisos incorrectos en wp-content/uploads o un tipo de archivo que WordPress o el servidor no aceptan en esa configuración. También puede influir una compresión inestable del navegador o una inspección de seguridad que corte la petición.

La confirmación debe hacerse con trazabilidad. No basta con subir límites al azar. Hay que comparar el tamaño real del vídeo con los límites activos, revisar si el límite se aplica a PHP, al proxy, al firewall o al servidor web, y comprobar si el problema desaparece en staging o con un usuario administrador. Si el error surge tras una actualización, un conflicto de plugin o una regla personalizada del tema también puede estar interviniendo.

• El límite de subida de WordPress es inferior al peso del vídeo.
• La suma del archivo y de la petición supera post_max_size aunque upload_max_filesize parezca suficiente.
• El servidor web rechaza la petición antes de que WordPress la procese.
• La carpeta uploads tiene permisos o propiedad incoherentes tras una migración.
• El archivo usa un formato, códec o extensión que provoca rechazo o análisis incompleto.

Seguridad, malware y validación de archivos

Aunque el título se centre en vídeos, la subida de archivos es un punto sensible de seguridad. Un sitio comprometido puede mostrar bloqueos extraños en la biblioteca, usuarios administradores no reconocidos, redirecciones, cambios de permisos o reglas que impiden subir ciertos archivos. También puede ocurrir lo contrario: un plugin de seguridad, un WAF o una política estricta esté bloqueando cargas legítimas por prevención.

Los vectores habituales incluyen plugins vulnerables, credenciales filtradas, permisos demasiado amplios, inyecciones en archivos del sitio y validaciones deficientes del tipo de archivo. La respuesta prudente pasa por realizar copia antes de tocar, rotar contraseñas de administración, FTP, base de datos y panel de hosting, revisar usuarios y roles, validar integridad básica del sitio y aplicar hardening razonable. Si hay sospecha real de intrusión, no conviene limpiar sin conservar evidencia técnica.

• Revise si existen usuarios nuevos, cambios en ajustes o archivos modificados sin explicación.
• Compruebe si algún plugin de seguridad o firewall bloquea la ruta de subida o el tipo MIME.
• Evite permisos 777 y confirme propiedad correcta en wp-content y uploads.
• Haga copia de archivos y base de datos antes de limpiar, restaurar o desactivar componentes.
• Rote contraseñas y cierre sesiones si hay indicios de acceso no autorizado.

Rendimiento y estabilidad durante la subida

Los vídeos son archivos pesados y sensibles a cortes de conexión, límites de tiempo y procesos lentos de validación. Si el servidor está justo de recursos, una subida grande puede coincidir con copias de seguridad automáticas, tareas cron, optimizaciones de imágenes o tráfico alto y provocar errores intermitentes. En estos casos, la incidencia no siempre es un límite fijo, sino una combinación de carga y estabilidad.

Desde una perspectiva de mantenimiento, interesa medir cuándo falla, con qué tamaño y con qué recursos. Si el problema aparece en horas punta o solo en producción, conviene revisar cachés de servidor, workers de PHP, memoria, espacio libre y procesos simultáneos. A menudo, lo más seguro es validar primero en staging, ajustar el entorno y repetir una única prueba controlada.

• Revise espacio en disco, inodos y ocupación de la carpeta uploads.
• Compruebe tiempos de ejecución, memoria PHP y saturación de procesos en el hosting.
• Evite lanzar subidas grandes mientras corren copias, importaciones o tareas pesadas.
• Valore alojamiento externo de vídeo si el sitio no necesita servir archivos pesados localmente.
• Monitorice después del cambio para confirmar que el error no era solo puntual.

Plugins, temas y actualizaciones que interfieren

Los conflictos de plugins y tema son frecuentes cuando la biblioteca multimedia deja de funcionar tras actualizar. Un plugin de optimización, seguridad, medios, constructor visual o traducción puede modificar peticiones AJAX, tipos de archivo, reglas REST o límites internos. También el tema puede incorporar funciones personalizadas en functions.php que alteren mime types, validaciones o respuestas del administrador.

La buena práctica es trabajar con staging, copia previa y control de cambios. Si el fallo apareció después de actualizar, lo correcto es identificar qué cambió, revisar compatibilidades y reproducir el problema en un entorno de prueba. Desactivar en bloque sin registro puede ayudar de urgencia, pero dificulta la trazabilidad. Mejor proceder por pasos, registrar cada acción y confirmar qué componente introduce el conflicto.

• Compare lista de plugins, versiones y fecha de actualización antes y después del error.
• Pruebe en staging con el mismo vídeo y el mismo usuario para aislar el conflicto.
• Revise functions.php y mu-plugins si se añadieron filtros sobre subidas o MIME.
• Compruebe compatibilidad entre la versión de WordPress, PHP y los plugins de medios.
• Documente cada cambio y evite aplicar varias correcciones simultáneas en producción.

Hosting, DNS y correo en España

En España, como en otros mercados, muchos proveedores aplican límites por plan, capa web, WAF, PHP o panel de control. Por eso un ajuste en WordPress no siempre basta. Puede haber un límite en Nginx, Apache, proxy inverso o CDN que corte la petición antes de llegar a PHP. También influyen el certificado SSL, la resolución DNS si ha habido migración y las cachés de servidor que mantienen reglas antiguas durante un tiempo.

Aunque el correo no interviene directamente en la subida del vídeo, sí puede ser relevante cuando el sitio envía avisos de error, formularios con adjuntos o notificaciones al equipo. Si tras un cambio de hosting fallan la carga de medios y el correo transaccional, el problema puede ser más amplio y afectar a DNS, rutas, SSL, versión de PHP, límites de recursos y permisos del sistema de archivos. Todo ello varía según proveedor y configuración concreta.

• Revise versión de PHP, memory_limit, upload_max_filesize y post_max_size reales del entorno.
• Confirme si existe un límite de tamaño en Nginx, proxy, firewall o CDN.
• Verifique SSL, DNS y propagación si el problema apareció tras una migración.
• Compruebe cachés de servidor y panel para evitar diagnosticar con datos desactualizados.
• Si hay formularios o flujos de aviso, revise también el correo transaccional asociado.

Pruebas, accesos y documentación técnica

Para resolver bien este problema hacen falta evidencias mínimas. Lo ideal es disponer de acceso a WordPress, panel de hosting, versión de PHP, logs de errores y, si existe, staging. Con eso se puede reconstruir qué ha pasado, cuándo empezó y qué cambió. Sin documentación, el riesgo de tocar parámetros al azar aumenta y se pierde tiempo.

También conviene guardar pruebas replicables. Una incidencia de subida de vídeo puede parecer solucionada con un archivo pequeño y volver con uno real. Por eso son útiles una muestra del archivo afectado, capturas del mensaje, fechas y cambios aplicados. En ámbito general, la prioridad es conservar trazabilidad y no solo apagar el síntoma.

• Trazabilidad de cambios recientes: registro de actualizaciones, lista de plugins activos, changelog interno y fecha exacta de inicio del fallo.
• Evidencias técnicas: logs de PHP y del servidor web, capturas del error, URLs afectadas, copia de seguridad y export de base de datos si procede.
• Prueba controlada con el mismo vídeo, una versión reducida y un usuario administrador de test.
• Datos del entorno: versión de WordPress, PHP, tema activo, límite de subida mostrado y espacio disponible.
• Accesos temporales y seguros al panel, FTP o SSH, manteniendo control de permisos y revocación posterior.

Plan de acción ordenado y seguro

La forma más segura de abordar esta incidencia es seguir un orden estable. Primero, contención y copia. Segundo, diagnóstico con datos. Tercero, corrección mínima necesaria. Cuarto, verificación con pruebas reales. Quinto, monitorización posterior para comprobar que no reaparece el problema. Este enfoque reduce tiempos de caída y evita encadenar cambios inseguros.

En un caso típico, se revisa el tamaño del vídeo y los límites activos, se identifican bloqueos del servidor web o de PHP, se confirma si existe conflicto de plugin o tema en staging y solo después se ajusta la configuración o se decide una alternativa de alojamiento del vídeo. Si el entorno es sensible, es preferible escalonar los cambios y guardar una ventana de reversión clara.

• Contener y hacer copia de archivos y base de datos antes de modificar parámetros.
• Reunir evidencias: error exacto, tamaño del vídeo, límites activos, logs y cambios recientes.
• Corregir primero el cuello de botella más probable con el menor impacto posible.
• Verificar con el archivo problemático, no solo con un archivo de prueba pequeño.
• Monitorizar durante varios días y dejar documentada la configuración final.

Si ya se ha tocado algo o hay urgencia

Si ya se instaló un plugin de seguridad, se restauró una copia parcial, se cambió de hosting, se tocó functions.php, se borró un plugin crítico o se intentó limpiar malware sin copia, todavía se puede reconducir la situación, pero con cautela. Lo primero es parar cambios adicionales, anotar lo hecho y preservar logs, archivos y fechas. Muchas evidencias desaparecen tras nuevas restauraciones o limpiezas agresivas.

En urgencia real, la prioridad es mantener el sitio estable y acotar el impacto. Si la web está caída, puede ser razonable restaurar servicio mínimo mientras se conserva una copia del estado actual para análisis posterior. Si el sitio sigue online pero no sube vídeos, es mejor no improvisar con varios plugins a la vez. La recuperación ordenada suele ser más eficaz que una secuencia de pruebas sin control.

• No sobrescriba logs ni borre archivos sospechosos sin guardar una copia previa.
• Si se modificó functions.php, compare el cambio exacto y prepárese para revertirlo con copia.
• Tras una restauración parcial, verifique coherencia entre archivos, base de datos y uploads.
• Si se cambió de hosting, documente límites, DNS, SSL y rutas antes de seguir tocando.
• Si se eliminó un plugin crítico, confirme dependencias y evite reinstalar a ciegas sin revisar versiones.

Preguntas frecuentes

Estas dudas son habituales cuando WordPress no permite subir vídeos. La respuesta correcta depende del entorno, pero hay patrones bastante repetidos.

P: ¿Si WordPress muestra un límite de subida, ese es siempre el límite real?

R: No siempre. Puede existir un límite anterior en Nginx, en un proxy, en el firewall o en el plan de hosting que corte la petición antes de que WordPress llegue a gestionarla.

P: ¿Conviene subir vídeos grandes directamente a la biblioteca multimedia?

R: Depende del caso. Para vídeos pesados o uso intensivo, a menudo es más eficiente valorar una solución externa de alojamiento o streaming y dejar WordPress para incrustación y gestión editorial.

P: ¿Puede un plugin de seguridad bloquear vídeos legítimos?

R: Sí. Algunas reglas inspeccionan tipos de archivo, tamaño, rutas o patrones de petición y pueden generar falsos positivos que conviene revisar antes de desactivar protección sin criterio.

P: ¿Es buena idea aumentar límites sin revisar logs?

R: No es lo más prudente. Puede aliviar el síntoma, pero si el origen es un conflicto, un permiso incorrecto o un bloqueo de seguridad, el problema seguirá ahí o incluso empeorará.

P: ¿Qué debería preparar antes de pedir soporte técnico?

R: El mensaje exacto, el tamaño y formato del vídeo, la fecha desde la que falla, los cambios recientes, capturas, acceso temporal seguro y, si es posible, logs de PHP y del servidor.