En resumen. El error 413 significa que el cuerpo de tu solicitud supera el límite configurado. NGINX permite solo 1 MB por defecto mediante client_max_body_size, Apache lo controla con LimitRequestBody y PHP con upload_max_filesize y post_max_size. En WordPress funcionan php.ini, .user.ini y .htaccess. Detrás de un proxy inverso o una CDN siempre manda el valor más bajo de la ruta.
Qué significa el error 413
Subes un tema, un plugin o un archivo multimedia grande y el servidor responde con “413 Request Entity Too Large”. La subida se corta antes de terminar. El motivo es un número: el cuerpo de tu solicitud es más grande que el máximo que el servidor acepta.
El código está en el rango 4xx, así que formalmente apunta al lado del cliente. En la práctica casi siempre es un problema de configuración. El archivo es legítimo y lo único ajustado de más es el límite del servidor.
Otros nombres para el mismo error
Según el servidor web y el navegador verás una redacción distinta. Todas se refieren al mismo código:
- 413 Content Too Large: el nombre actual desde el RFC 9110.
- 413 Payload Too Large: el nombre anterior del RFC 7231, todavía muy común.
- Request Entity Too Large: la variante clásica que muchos servidores siguen devolviendo.
- HTTP Error 413: el término genérico.
- 413 Request Entity Too Large (nginx): NGINX firma su propia página de error.
La tarea es la misma en todos los casos. Ajustas la capacidad del servidor al tamaño real de tus archivos.
Cuándo aparece el error
Un 413 aparece casi siempre en una solicitud POST. Los casos habituales:
- Subes un video grande o un archivo ZIP voluminoso a la Mediateca.
- Instalas un tema o un plugin con muchos extras directamente desde wp-admin.
- Envías un formulario con varios archivos adjuntos.
- Envías por API un payload JSON extenso.
Causas del error 413
Límite de subida demasiado bajo en el servidor
Esta es la causa en la mayoría de los casos. En la configuración del servidor hay un valor que limita el tamaño máximo del cuerpo de una solicitud HTTP. Los proveedores de hosting lo dejan bajo a propósito, porque un límite abierto facilita ataques DoS con flujos de datos interminables. En cuanto lo superas, recibes el 413. La solución está en las directivas que controlan el tamaño máximo del cuerpo y en los valores de PHP que las acompañan.
Permisos de archivo incorrectos
Menos frecuente, pero vale la pena revisarlo. Si el directorio temporal de subidas no pertenece al usuario del servidor web o tiene permisos muy restrictivos, la subida falla antes de que el archivo se procese. En ese escenario lo normal es un 403 o un error de PHP, no un 413. Aun así, revisa los permisos cuando todos los límites están bien puestos y la subida sigue cortándose.
Recursos del servidor insuficientes
En sistemas saturados, sobre todo en hosting compartido, las subidas grandes fallan porque la memoria o el tiempo de ejecución no alcanzan. Eso suele dar un error 500 o un timeout. Si además ves un 413, revisa que upload_max_filesize, post_max_size y el límite del servidor web concuerden entre sí. Un post_max_size pequeño con un upload_max_filesize generoso es una trampa frecuente, porque decide el valor más bajo.
Cómo saber qué capa está bloqueando
Antes de cambiar valores, averigua quién rechazó la solicitud. Crea un archivo de prueba con un tamaño conocido:
dd if=/dev/zero of=test-20mb.bin bs=1M count=20Envíalo al endpoint que falla y revisa la respuesta completa:
curl -v -F "[email protected]" https://tu-dominio.com/wp-admin/async-upload.phpSi el 413 llega con un encabezado Server: nginx y sin salida de WordPress, el rechazo viene de NGINX. Si la respuesta trae un mensaje de error de WordPress, actúa un límite de PHP. En el log de NGINX el caso aparece en texto claro:
sudo tail -f /var/log/nginx/error.logLa línea correspondiente dice “client intended to send too large body” e incluye el tamaño real de la solicitud. Recién entonces sube exactamente el límite que actuó, en lugar de aumentar todos los valores a la vez. Así la configuración queda rastreable y conservas la protección en las demás capas.
Dónde vive cada límite
| Capa | Directiva o valor | Predeterminado | Archivo |
| NGINX | client_max_body_size | 1 MB | nginx.conf o archivo del sitio |
| Apache | LimitRequestBody | 0, es decir sin límite | httpd.conf, VirtualHost, .htaccess |
| PHP, archivo individual | upload_max_filesize | 2M | php.ini, .user.ini |
| PHP, solicitud completa | post_max_size | 8M | php.ini, .user.ini |
| PHP, memoria | memory_limit | 128M | php.ini, .user.ini |
| CDN, ejemplo Cloudflare | límite de subida por plan | 100 MB en Free y Pro | panel del proveedor |
El valor más bajo de esta cadena es el que manda. Un client_max_body_size de 512M no sirve de nada mientras post_max_size siga en 8M.
Cómo solucionar el 413 en WordPress
En WordPress el error se ve casi siempre en la zona de subidas de wp-admin. La ruta que te conviene depende de cuánto acceso tengas al servidor.
Aumentar los límites de subida de PHP
Este es el ajuste principal. Abre tu php.ini. Si no existe, crea un archivo vacío en el directorio raíz y pon estos valores:
upload_max_filesize = 64M
post_max_size = 64M
memory_limit = 128Mupload_max_filesize limita el archivo individual y post_max_size el cuerpo completo de la solicitud. Pon post_max_size igual o más alto que upload_max_filesize, porque si no manda el valor menor. memory_limit puede quedar por encima de ambos, y con subidas grandes 256M tiene sentido siempre que tu proveedor lo permita.
Recarga PHP-FPM o el servidor web después para que los valores tomen efecto.
Ajustar el archivo .htaccess
En un servidor Apache con mod_php, el archivo .htaccess es la vía más confiable cuando no tienes acceso a la php.ini. Agrega estas líneas al final:
php_value upload_max_filesize 64M
php_value post_max_size 64M
php_value max_execution_time 300
php_value max_input_time 300Con PHP-FPM las directivas php_value no funcionan y Apache responde con un error 500. En ese caso usa un archivo .user.ini en el directorio raíz con la misma sintaxis de la php.ini.
functions.php como último recurso
¿Sin acceso a los archivos del servidor? Queda la functions.php de tu tema. Ve a Apariencia > Editor de archivos de temas y agrega:
@ini_set( 'upload_max_filesize', '64M' );
@ini_set( 'post_max_size', '64M' );
@ini_set( 'max_execution_time', '300' );Dos limitaciones: al cambiar de tema el ajuste desaparece. Y upload_max_filesize junto con post_max_size casi nunca se pueden sobrescribir en tiempo de ejecución, porque PHP los evalúa antes de arrancar el script. Si el límite no se mueve, baja una capa hacia .user.ini, .htaccess o php.ini.
Restablecer los permisos de archivo
Si los límites ya están y la subida sigue fallando, restablece los permisos. El estándar es 644 para archivos y 755 para directorios. Por SSH lo resuelves con dos comandos:
find /var/www/html/wp-content -type d -exec chmod 755 {} \;
find /var/www/html/wp-content -type f -exec chmod 644 {} \;Sin acceso SSH usa FileZilla u otro cliente FTP, abre la carpeta wp-content y haz clic derecho en “Atributos de archivo”. Pon 755 para carpetas y 644 para archivos en dos pasadas separadas.
Cómo solucionar el 413 en NGINX y Apache
En tu propio VPS las capas de WordPress muchas veces no bastan. Ahí trabajas directo en la configuración del servidor web.
Definir client_max_body_size en NGINX
NGINX permite 1 MB si no defines nada. Es la causa más común de un 413 detrás de NGINX. Abre /etc/nginx/nginx.conf o el archivo de tu sitio en /etc/nginx/sites-available/ y pon la directiva en el bloque http, server o location:
client_max_body_size 64M;Revisa la sintaxis y recarga el servicio para que el cambio surta efecto:
sudo nginx -t
sudo systemctl reload nginxDefinir LimitRequestBody en Apache
Apache lo controla con LimitRequestBody. La directiva va en httpd.conf, en el VirtualHost o en un .htaccess local:
LimitRequestBody 67108864El valor va en bytes, así que 67108864 equivale a 64 MB. Con 0 eliminas el límite por completo. Evítalo en producción, porque un límite abierto deja el servidor expuesto.
El 413 en configuraciones con proxy inverso
Los stacks modernos ponen NGINX como proxy inverso delante de Apache, de un servidor de aplicaciones o de un contenedor Docker. Entonces ves un 413 de NGINX aunque la configuración de Apache sea correcta. La solicitud llega primero a NGINX y, si supera client_max_body_size, nunca alcanza el backend.
Define el límite en cada capa: balanceador de carga, CDN, proxy inverso, servidor web y PHP. Lo que decide siempre es el valor más bajo de la ruta.
Hay un segundo valor que conviene revisar aquí. Si client_body_buffer_size queda por debajo del tamaño del archivo, NGINX escribe el cuerpo de la solicitud en disco. La subida sigue funcionando, pero con muchas subidas en paralelo cuesta I/O y se vuelve notablemente más lenta.
Cómo prevenir el error 413
Optimizar y comprimir los archivos
La forma más simple de esquivar un 413 es un archivo más chico. Para las imágenes de WordPress usa Smush o EWWW Image Optimizer. Los videos van en YouTube o Vimeo en lugar de la Mediateca, lo que ahorra espacio en disco y ancho de banda en el servidor.
Activar subidas por fragmentos
La subida por fragmentos parte un archivo grande en piezas pequeñas, por ejemplo de 2 MB, y las envía una por una. Cada solicitud queda debajo del límite y el 413 no aparece. Muchos plugins de WordPress para archivos grandes trabajan así, sin que toques ningún archivo del servidor.
Vigilar los límites de la CDN
Una CDN como Cloudflare distribuye el tráfico, pero trae sus propios límites de subida. El plan gratuito y el Pro llegan a 100 MB por solicitud, Business a 200 MB y Enterprise a 500 MB de forma predeterminada. Un archivo de 150 MB se detiene en la CDN antes de que tu servidor lo vea. Alinea el límite de la CDN con client_max_body_size o LimitRequestBody.
Revisar los valores del servidor con regularidad
Abre una página con phpinfo() y mira upload_max_filesize, post_max_size y memory_limit. A medida que el sitio crece, los límites viejos dejan de alcanzar. Borra el archivo después de revisarlo, porque expone detalles de tu entorno.
Dónde está el archivo de configuración de NGINX
El archivo principal está en /etc/nginx/nginx.conf en casi todas las distribuciones de Linux. Muchos montajes reparten la configuración en /etc/nginx/sites-available/ y /etc/nginx/sites-enabled/. Haz un respaldo antes de cada cambio y revisa con sudo nginx -t, porque un error de tipeo impide que NGINX arranque.
FAQ: 413 Request Entity Too Large
¿Qué significa el error 413 Request Entity Too Large?
El servidor rechaza la solicitud porque su cuerpo supera el máximo configurado. El código funciona como mecanismo de protección y evita que una sola solicitud agote los recursos del servidor.
¿Cómo soluciono el 413 Payload Too Large?
Aumenta el tamaño de subida permitido en la configuración del servidor. En NGINX es client_max_body_size, en Apache LimitRequestBody y en PHP upload_max_filesize junto con post_max_size. Recarga el servicio al terminar.
¿Cómo aumento el límite de subida en WordPress?
Con la php.ini, un archivo .user.ini, el .htaccess o, como último recurso, la functions.php de tu tema. La php.ini y la .user.ini son las más confiables porque sobreviven a un cambio de tema.
¿Qué causa el error 413 en NGINX?
Casi siempre client_max_body_size. Sin una definición propia, la directiva se queda en 1 MB. Si tu subida pasa de ahí, sube el valor en la configuración de NGINX y recarga el servicio.
¿Qué valor debo poner en client_max_body_size?
Guíate por el archivo más grande que tu aplicación debe aceptar de verdad y súmale un margen pequeño. Para bibliotecas de medios lo habitual son 64M a 128M. Evita 0, porque con ese valor aceptas solicitudes de cualquier tamaño.
¿El error 413 afecta el posicionamiento SEO?
Un 413 ocasional en el backend no. Si los visitantes topan con el error en el frontend, por ejemplo al subir contenido propio, la tasa de rebote sube. Los errores frecuentes afectan el posicionamiento de forma indirecta, a través de la experiencia de uso.
Casos especiales
El 413 también aparece fuera de las subidas clásicas. Con un WordPress headless o con WordPress como API de backend lo encuentras en llamadas a la REST API con payloads JSON grandes. La causa es la misma y solo cambia el contexto. Ahí conviene además dividir el payload en lugar de seguir subiendo el límite.
Los entornos locales son el segundo caso especial. Tu sistema de desarrollo suele tener límites generosos y el de producción bastante más estrechos. El error aparece entonces después del despliegue. Prueba las subidas en un entorno de staging que refleje la configuración de producción.
Por dónde empezar
Sin acceso al servidor arrancas con el .htaccess o el .user.ini. Con acceso al servidor vas directo a /etc/nginx/nginx.conf o a la configuración de Apache y pones el límite donde aplica a todo el servidor. Después pruebas con una subida real del tamaño que manejas en producción y confirmas que cada capa tomó el valor nuevo.
Deja los valores documentados y vuelve a revisarlos cuando amplíes el stack. Una CDN nueva, un balanceador de carga extra o el cambio de mod_php a PHP-FPM trae un límite propio que conviene conocer antes de que la siguiente subida se quede atorada en él.
