Índice
Qué es el error 413 Request Entity Too Large
Te sale ese número en rojo en la pantalla. El error 413 Nginx, o «Request Entity Too Large», es básicamente un portero de discoteca que te dice «hasta aquí llegaste». El servidor web ve que el navegador está mandando un archivo —una imagen pesada, un plugin, una base de datos— y el tamaño supera el límite que tienen configurado. Nginx, por defecto, es muy parco con estos límites. Es una medida de seguridad. Prefiere cortar la conexión antes de dejar que un archivo gigante se coma la memoria y deje el servidor colgado.
Ahorra ancho de banda y protege la CPU. Bien. Pero a ti, que solo quieres subir un tema nuevo a WordPress o importar una copia de seguridad, te frustra. La conexión se corta de golpe, sin preámbulos, y devuelve el código 413 antes de procesar nada. El servidor está haciendo su trabajo, sí, pero tu trabajo se ha quedado a medias.
Localizar el archivo de configuración principal
Antes de tocar nada, hay que saber dónde estamos. En Linux la estructura de archivos puede ser un laberinto dependiendo de si usas Ubuntu, Debian o CentOS. Lo normal es encontrar el archivo madre en /etc/nginx/nginx.conf. Ojo, sin embargo. En muchos hostings modernos la cosa se complica con carpetas como sites-available y sites-enabled.
Si gestionas un VPS, tu apuesta segura suele ir a /etc/nginx/sites-available/tu-dominio.com. Es mejor cambiar el bloque server aquí que en el archivo global. ¿Por qué? Por limpieza. Así puedes tener límites distintos para cada dominio sin jugarte la vida del resto de servicios que corren en esa misma máquina.
Modificar la directiva client_max_body_size
Toda la solución gira en torno a una sola línea: client_max_body_size. Esta directiva le dice a Nginx cuánto está dispuesto a tragar. Si el paquete de datos pesa más, llega el 413. El problema es que el valor por defecto es ridículo para los estándares de hoy: solo 1 MB.
Abre el archivo con nano o vim. Busca el bloque server (o el http si quieres que sea global) y escribe esto:
client_max_body_size 100M;
En el ejemplo puse 100 Megabytes, pero pon lo que necesites. Puedes usar ‘M’ o ‘G’ si te atreves con Gigabytes. Cuidado con el sitio donde lo pegas. Si lo metes dentro de un bloque location, la regla solo aplica a esa ruta específica. Lo más sensato es situarlo a nivel de bloque server para cubrir todo el dominio, incluido el administrador de WordPress y los endpoints de API.
Consejo de experto: Nada de guardar y cerrar a lo loco. Antes de reiniciar nada, ejecuta nginx -t. Ese comando revisa la sintaxis. Si hay una coma de más o un punto y coma que sobra, te avisará antes de dejar el servidor inoperativo.
Aplicar los cambios en Nginx
Guardar el archivo no basta. Nginx carga la configuración en la memoria al arrancar, así que hay que refrescarlo. Tienes dos caminos: el reinicio a la brava (systemctl restart nginx) o la recarga elegante (nginx -s reload). En producción, elige la segunda opción.
El reload cierra los sockets viejos y abre unos nuevos con la configuración fresca. Lo bueno es que las conexiones que ya estaban en curso se terminan de procesar sin corte seco. Tus usuarios no notarán el parpadeo.
Ajustar la configuración de PHP
No basta con abrir la puerta en Nginx si PHP la tiene cerrada con llave. Si tu sitio corre sobre WordPress, lo más probable es que el cuello de botella esté ahora en el lenguaje de programación. PHP tiene sus propias reglas y, si son más estrictas que las de Nginx, la subida seguirá fallando.
Hay que tumbar mano en el php.ini. Para saber dónde vive, ejecuta php -i | grep php.ini en la terminal. Una vez ahí, busca estas dos variables:
- upload_max_filesize: El tope del archivo en sí. Ponle al menos lo mismo que le pusiste a Nginx.
- post_max_size: El tamaño total de la petición POST. Tiene que ser un pelín mayor que el de subida porque cuenta el archivo más los metadatos del formulario.
upload_max_filesize = 100M
post_max_size = 110M
Y no te olvides de reiniciar PHP-FPM (systemctl restart php7.4-fpm o la versión que tengas) para que todo esto no sea solo tinta sobre papel.
Verificación y pruebas finales
Llega la hora de la verdad. Intenta subir un archivo pesado desde el gestor de medios de WordPress. Si funciona, genial. Pero si quieres ir más allá y ser un poco más técnico, usa curl para simular la subida desde la terminal.
Si la configuración es correcta, el servidor aceptará el handshake. Si ves un 400 o un 500, ya es otro problema (quizá de la aplicación), pero el temido 413 debería haber desaparecido. También puedes crear un phpinfo.php temporal para comprobar visualmente que PHP ha leído los nuevos valores del php.ini.
Preguntas Frecuentes
¿Por qué sigue apareciendo el error si ya modifiqué nginx.conf?
A veces hay una jerarquía silenciosa. Puede que otro archivo en sites-enabled esté sobrescribiendo tu cambio con un valor más bajo. Revisa los bloques anidados; suele haber un conflicto de prioridades.
¿Es seguro aumentar este límite a 1GB o más?
Puedes, pero asume el riesgo. Mientras más grande el límite, más tiempo dura la subida y más memoria se consume. Si diez usuarios intentan subir archivos de 1GB a la vez, tu RAM podría sufrir. Mejor ajustar el límite a lo que realmente necesitas, no a lo que te gustaría tener.
Conclusión
Arreglar el error 413 Nginx es cuestión de coordinación. Tienes que poner de acuerdo a Nginx con PHP. Subes el client_max_body_size en el web server, ajustas el php.ini y recargas los servicios con cuidado. Son barreras técnicas que se caen con unos pocos ajustes, pero hay que hacerlos con orden. Si después de todo esto sigues viendo errores o el servidor va lento, quizá sea hora de pedir ayuda. En RedServicio (redservicio.net) tenemos expertos acostumbrados a optimizar estos detalles para que tú no tengas que pelearte con la configuración.
