Tamaño máximo de subida de archivos en PHP y Nginx: guía

Ajustar el tamaño máximo de subida de archivos es una de las dudas que más veo repetirse entre administradores de servidores y usuarios de WordPress, sobre todo cuando aparece el famoso error HTTP 413 o ese mensaje de «El archivo subido excede la directiva upload_max_filesize». En Apache, con un .htaccess casi siempre basta. Pero en un entorno PHP-FPM con Nginx la cosa cambia: la configuración se reparte entre dos capas y las dos tienen que ir sincronizadas. Aquí explico por qué cada una limita por separado y cómo tocar cada directiva sin equivocarte.

Por qué PHP y Nginx limitan el tamaño de subida por separado

Cuando alguien sube un archivo a tu servidor, la petición pasa primero por Nginx y solo después llega a PHP-FPM. Cada capa trae sus propios controles de seguridad. Nginx decide cuántos bytes acepta en el cuerpo de una petición HTTP antes de rechazarla; PHP, por su parte, define cuánto puede pesar el payload de POST y, dentro de él, cada archivo individual.

De ahí un error clásico. El administrador sube upload_max_filesize en PHP, cree que ya está… y Nginx sigue cortando las peticiones con un 413 Request Entity Too Large. El archivo jamás llega a ejecutarse, por alto que esté el límite de PHP. La regla de oro: el valor de client_max_body_size en Nginx debe ser igual o ligeramente superior a post_max_size en PHP. Ni una excepción.

• Nginx: controla el tamaño del cuerpo de la petición HTTP completa (cabeceras excluidas).
• PHP: controla el POST total (post_max_size) y cada archivo individual (upload_max_filesize).
• Regla práctica: client_max_body_size ≥ post_max_size ≥ upload_max_filesize.

Configurar upload_max_filesize y post_max_size en PHP

Las dos directivas clave viven en el php.ini que usa PHP-FPM. Suele estar en /etc/php/8.1/fpm/php.ini (ajusta la versión según tu instalación). Edita estas líneas:

1. Abre el archivo: sudo nano /etc/php/8.1/fpm/php.ini
2. Localiza y modifica:
   upload_max_filesize = 64M
   post_max_size = 70M
3. Reinicia PHP-FPM: sudo systemctl restart php8.1-fpm

Fíjate en que post_max_size va por encima de upload_max_filesize. ¿Por qué? Porque el POST incluye el archivo más otros datos del formulario, así que conviene dejar un margen del 10-20%. Y si sueles subir varios archivos de golpe, revisa también max_file_uploads, que limita el número de archivos por petición (por defecto 20).

Ajustar client_max_body_size en Nginx

La directiva client_max_body_size es la contraparte en Nginx, y su valor por defecto es de solo 1M. Poco. Muy poco para casi cualquier proyecto actual. Puedes definirla en tres niveles, dentro de nginx.conf o del archivo de configuración de tu sitio (en /etc/nginx/sites-available/): en el bloque http (global), en el bloque server (por sitio) o en el bloque location (por ruta).

Un ejemplo típico para un sitio WordPress:

server {
    client_max_body_size 70M;
    location /wp-admin/ {
        client_max_body_size 100M;
    }
}

Guardas, verificas la sintaxis con sudo nginx -t y recargas con sudo systemctl reload nginx. Detalle importante: reload, no restart. Así no cortas las conexiones activas.

Con ambas capas alineadas, el error 413 desaparece y las subidas funcionan de forma consistente.

Cómo reiniciar servicios y verificar los cambios correctamente

Editar los archivos de configuración no hace nada por sí solo. Hasta que recargues o reinicies los servicios implicados, el servidor sigue funcionando con los valores antiguos. Es un paso que muchos administradores olvidan, y de ahí esa falsa sensación de que «los cambios no funcionan». El procedimiento correcto depende, claro, de la pila que tengas montada.

Reiniciar PHP-FPM

Para aplicar los cambios de php.ini en un servidor con PHP-FPM, el comando varía según tu versión:

1. Debian/Ubuntu: sudo systemctl restart php8.1-fpm (ajusta la versión instalada, que puedes comprobar con php -v).
2. CentOS/RHEL/AlmaLinux: sudo systemctl restart php-fpm.

¿Y si usas PHP como módulo de Apache? Entonces basta con reiniciar Apache: sudo systemctl restart apache2 o sudo systemctl restart httpd.

Recargar Nginx

Nginx permite recargar la configuración sin cortar las conexiones activas. En producción, esto es lo que quieres:

• Primero verifica la sintaxis con sudo nginx -t. Si devuelve «syntax is ok» y «test is successful», puedes continuar.
• Después aplica los cambios con sudo systemctl reload nginx.

Verificar que los valores están activos

La forma más fiable de confirmar los cambios es preguntarle a PHP directamente. Crea un archivo temporal llamado info.php en la raíz de tu sitio con el contenido <?php phpinfo(); ?>, accede a tudominio.com/info.php y busca las directivas upload_max_filesize, post_max_size y memory_limit. Fíjate también en la columna «Master Value» frente a «Local Value»: si difieren, algún archivo de configuración posterior o una directiva .user.ini está sobrescribiendo tu ajuste. Pasa más de lo que parece.

Y ahora lo importante: elimina el archivo info.php cuando termines. Ese archivo expone información sensible de tu servidor a cualquiera que sepa dónde mirar.

En WordPress puedes ahorrarte el phpinfo completo desde Herramientas → Salud del sitio → Información → Servidor, que muestra los valores efectivos de subida.

Solución al error 413 Request Entity Too Large y otros fallos frecuentes

El error 413 Request Entity Too Large es el síntoma más habitual de una configuración corta. Nginx lo devuelve antes de que la petición llegue a PHP, así que no sirve de nada subir los límites de PHP si client_max_body_size sigue bajo. Esta lista de comprobación funciona mejor si la recorres en orden:

1. El 413 aparece con un código HTML de Nginx: falta client_max_body_size o está en un bloque location que no aplica a tu ruta de subida. Colócalo en el bloque http o server para cubrir todo el sitio.
2. La subida falla pero no hay 413: revisa el log de errores de PHP (/var/log/php*-fpm.log o el error_log de PHP). Mensajes como «POST Content-Length exceeds the limit» apuntan a un post_max_size insuficiente.
3. La página se recarga sin mensaje en WordPress: es el caso más desconcertante, pero tiene explicación: cuando el cuerpo de la petición supera post_max_size, WordPress descarta los datos en silencio. Revisa también max_input_time y max_execution_time si las subidas son lentas.
4. Fallo intermitente en archivos grandes: aumenta client_body_timeout y fastcgi_read_timeout en Nginx (por ejemplo, a 300 segundos) para conexiones lentas.
5. Error 500 tras subir: suele ser memory_limit por debajo de post_max_size. Mantén siempre la jerarquía memory_limit > post_max_size > upload_max_filesize.

Una regla que me ha ahorrado horas de debugging: cuando un error persista, mira siempre dos fuentes, el error.log de Nginx y el log de errores de PHP. Entre ambos te dirán exactamente qué capa está rechazando la subida. Sin adivinanzas.

Conclusiones y buenas prácticas para el tamaño máximo de subida de archivos

Ajustar el tamaño máximo de subida de archivos bien hecho consiste en alinear tres capas: PHP (upload_max_filesize y post_max_size), Nginx (client_max_body_size) y, si existe, cualquier proxy intermedio. La configuración solo funciona cuando todos los valores son coherentes entre sí y superan el tamaño real de los archivos que tus usuarios necesitan subir. Si uno de los tres se queda corto, el sistema entero se queda corto.

Quedémonos con lo esencial:

• Aplica la jerarquía de valores: memory_limit > post_max_size > upload_max_filesize.
• Configura el límite en el bloque http o server de Nginx y valida siempre con nginx -t antes de recargar.
• Localiza el php.ini correcto consultando phpinfo() o php –ini. No edites archivos a ciegas.
• Verifica los cambios desde la Salud del sitio de WordPress o un phpinfo temporal que borrarás después.
• Fija límites razonables según el uso real del sitio: 64M es habitual para WordPress estándar; sube solo si tu caso lo justifica, porque límites excesivos amplían la superficie de ataque y facilitan agotar los recursos del servidor.
• Para archivos muy pesados (vídeo, copias de seguridad), mejor considerar la carga por chunks con plugins especializados que ir elevando los límites indefinidamente.

Si tras seguir esta guía el problema persiste, o prefieres que un profesional revise tu configuración de servidor, en RedServicio (redservicio.net) encontrarás soporte especializado en administración de servidores, Nginx y WordPress para resolver cualquier incidencia con tu hosting de forma rápida y segura.