Cómo solucionar 413 Request Entity Too Large al subir archivos a un VPS (2026): diagnóstico de límites de Nginx, PHP y Cloudflare

Primero usa las herramientas de desarrollador del navegador para ver las cabeceras de respuesta, o usa curl directamente:

curl -I https://example.com/upload

Si la respuesta contiene:

Server: nginx

lo más probable es que Nginx lo esté bloqueando primero.

Si tienes Cloudflare por delante, las cabeceras de respuesta pueden mostrar:

server: cloudflare
cf-ray: xxxxx

En este punto debes distinguir si lo rechazó Cloudflare o si Cloudflare lo reenvió y el origen lo rechazó.

Luego revisa los registros de Nginx:

sudo tail -n 80 /var/log/nginx/error.log

Un registro típico es:

client intended to send too large body: 20971520 bytes

Al ver esta línea, la dirección queda clara: el límite de tamaño del cuerpo de la solicitud de Nginx es demasiado pequeño.

El límite predeterminado de Nginx suele ser muy pequeño; en muchos entornos es 1MB. Puede que ni siquiera alcance para subir imágenes.

Abre la configuración del sitio:

sudo nano /etc/nginx/sites-available/example.com

O tu configuración está en:

/etc/nginx/conf.d/example.conf

Añade esto dentro del bloque server:

server {
    server_name example.com;

    client_max_body_size 100M;

    root /var/www/example.com;
    index index.php index.html;
}

Si solo quieres ampliar el límite para un endpoint de subida específico, también puedes ponerlo dentro de location:

location /upload/ {
    client_max_body_size 100M;
    try_files $uri $uri/ /index.php?$query_string;
}

No se recomienda escribir 0 para eliminar el límite por completo. Si el endpoint de subida no tiene ningún límite, las solicitudes maliciosas pueden llenar fácilmente el disco, la memoria o el directorio temporal.

Después de cambiarlo, prueba primero:

sudo nginx -t

Si no hay problema, recarga:

sudo systemctl reload nginx

Si usas OpenResty, BT Nginx o Nginx Proxy Manager, la esencia es la misma: busca client_max_body_size, solo cambia el punto de entrada de la configuración.

Muchas personas cambian solo Nginx, el 413 desaparece, pero luego la página de subida indica que el archivo es demasiado grande. Esto se debe a que la solicitud por fin llega a PHP y PHP la bloquea otra vez.

Primero encuentra el archivo de configuración de PHP:

php --ini

Si ejecutas PHP-FPM, las distintas versiones pueden estar en:

/etc/php/8.2/fpm/php.ini
/etc/php/8.1/fpm/php.ini
/etc/php/7.4/fpm/php.ini

Cambia estos valores:

upload_max_filesize = 100M
post_max_size = 100M
max_execution_time = 300
max_input_time = 300
memory_limit = 256M

Nota: post_max_size debe ser mayor o igual que upload_max_filesize.

Si quieres subir archivos de 100MB, yo normalmente lo configuro así:

upload_max_filesize = 100M
post_max_size = 120M
memory_limit = 256M

Después de cambiarlo, reinicia PHP-FPM:

sudo systemctl restart php8.2-fpm

Cambia el número de versión según tu máquina. Puedes comprobarlo con:

systemctl list-units | grep php | grep fpm

Los usuarios de WordPress son los que más se atascan aquí.

Se han cambiado tanto Nginx como PHP, pero la biblioteca de medios del panel sigue mostrando una subida máxima de 2MB, 8MB o 32MB. Esto significa que PHP-FPM no leyó la configuración que cambiaste, o que todavía hay un panel/plugin limitándolo.

Puedes colocar temporalmente un phpinfo.php en el directorio del sitio:

<?php phpinfo();

Después de visitarlo, busca:

upload_max_filesize
post_max_size
Loaded Configuration File

Confirma que la página muestra los nuevos valores.

Recuerda eliminarlo después de revisarlo:

rm /var/www/example.com/phpinfo.php

En WordPress también debes comprobar:

• Si un plugin de seguridad limita las subidas;
• Si el tema o un plugin impone su propio límite de tamaño de archivo;
• Si hay configuración relevante en wp-config.php;
• Si la configuración de PHP en el panel BT sobrescribe tus cambios manuales.

No mires solo el php --ini de la línea de comandos; el sitio web realmente usa PHP-FPM, y los dos archivos de configuración pueden no ser el mismo.

Si tu arquitectura es:

用户 -> Nginx 反向代理 -> Docker / Node / PHP / 后端服务

entonces el Nginx de delante debe ampliar su límite, y el servicio de detrás también debe ampliarlo.

Por ejemplo, Nginx como proxy inverso hacia Node:

location /api/ {
    client_max_body_size 100M;
    proxy_pass http://127.0.0.1:3000;
}

Express también puede tener un límite de body:

app.use(express.json({ limit: '100mb' }));
app.use(express.urlencoded({ limit: '100mb', extended: true }));

Laravel / Symfony / Django / Rails también tienen sus propios límites de subida. Que Nginx permita la solicitud no significa que la aplicación vaya a aceptarla.

Así que si el registro de Nginx no tiene 413 pero el registro de la aplicación tiene errores de subida, revisa la capa de la aplicación.

Si el sitio web tiene Cloudflare por delante, no olvides que también tiene límites.

Los límites de tamaño de subida de Cloudflare varían según el plan. El plan gratuito y los planes de gama baja normalmente no son adecuados para subir directamente archivos muy grandes.

Si necesitas subir paquetes de respaldo de cientos de MB, lo mejor es no usar la subida web normal. Los métodos más fiables son:

• Subir al VPS con SFTP / SCP;
• Subir directamente al almacenamiento de objetos;
• Cambiar la subida del backend a subida por fragmentos;
• Pausar temporalmente el proxy y probar con una conexión directa al origen en nube gris.

Al probar, puedes cambiar el registro DNS de nube naranja a nube gris, omitir Cloudflare y ver si el 413 desaparece.

Si funciona normalmente después de omitirlo, entonces no es un problema del Nginx o PHP del VPS, sino un límite de la capa CDN.

Muchas personas ejecutan WordPress, Nextcloud o Laravel con Docker, luego cambian /etc/nginx en la máquina host y no tiene ningún efecto.

Primero confirma dónde está Nginx:

docker ps

Si Nginx está dentro de un contenedor, la configuración también está dentro del contenedor, o se monta hacia fuera mediante un volumen.

Rutas comunes:

/etc/nginx/conf.d/default.conf
/etc/nginx/nginx.conf

Después de cambiarlo, recarga Nginx dentro del contenedor o reinicia el contenedor:

docker exec -it nginx nginx -t
docker exec -it nginx nginx -s reload

Si usas docker compose:

docker compose restart nginx

Nextcloud también requiere revisar PHP y la configuración de la propia aplicación. Cambiar solo la capa del proxy inverso a menudo no es suficiente.

Si solo subes ocasionalmente imágenes de 50MB, subir el límite a 100M no es un gran problema.

Pero si subes con frecuencia paquetes de respaldo de 1GB o 5GB, no se recomienda simplemente subir mucho el límite. La razón es simple:

• Las subidas interrumpidas fácilmente tienen que empezar de nuevo;
• Los archivos temporales de Nginx pueden llenar el disco;
• PHP es propenso a tiempos de espera al manejar archivos grandes;
• Cuanto más larga es la cadena de proxy inverso, más puntos de fallo hay;
• Las solicitudes maliciosas pueden saturar más fácilmente el ancho de banda y el disco.

Para estos escenarios es más adecuado:

scp backup.tar.gz root@server:/data/backups/

O usar rsync:

rsync -avP backup.tar.gz root@server:/data/backups/

Si el backend del sitio web permite a los usuarios subir archivos grandes, se recomienda implementar subida por fragmentos o subida directa al almacenamiento de objetos, en lugar de dejar que todos los archivos grandes pasen por PHP.

Cuando encuentro un 413, normalmente sigo este orden:

sudo tail -n 80 /var/log/nginx/error.log
sudo nginx -T | grep -n client_max_body_size
sudo nginx -t

Después de confirmar Nginx, reviso PHP:

php --ini
systemctl list-units | grep php | grep fpm

Si es WordPress, uso phpinfo() para confirmar los valores que realmente lee el entorno web.

Si hay Cloudflare por delante, hago otra prueba de conexión directa en nube gris.

Para sitios web normales que suben imágenes, temas y plugins, normalmente esto es suficiente:

Nginx:

client_max_body_size 100M;

PHP:

upload_max_filesize = 100M
post_max_size = 120M
max_execution_time = 300
max_input_time = 300
memory_limit = 256M

Si solo necesitas subir archivos de 20MB, no lo cambies directamente a 1GB. Más grande no siempre es mejor; basta con que sea suficiente.

La esencia del 413 es "el cuerpo de la solicitud es demasiado grande", pero el verdadero problema es que cada capa de la cadena tiene su propio límite superior. Revisa en el orden de Nginx, PHP, aplicación, CDN y Docker, y básicamente no te desviarás.