HTTP 413 Request Entity Too Large: Causas Raíces, Soluciones y Guía de Configuración del Servidor

El error HTTP 413 Request Entity Too Large es un código de estado de respuesta del lado del servidor que ocurre cuando el cuerpo de una solicitud entrante — más comúnmente una carga de archivo — supera el tamaño máximo de carga útil configurado en el servidor web, el proxy inverso o la capa de aplicación. El servidor rechaza activamente la solicitud antes de procesarla, devolviendo un estado 413 al cliente.

Este error no es un error del lado del cliente. Es un mecanismo de aplicación deliberado integrado en servidores web como Nginx y Apache, configuraciones del tiempo de ejecución de PHP y middleware a nivel de aplicación. Entender exactamente qué capa está aplicando el límite — y cómo apuntar a la directiva de configuración correcta — es la diferencia entre una solución limpia y horas de resolución de problemas.

Por qué ocurren los errores HTTP 413: Un desglose capa por capa

Una solicitud de carga de archivo pasa por múltiples capas de procesamiento antes de llegar a su aplicación. Cualquiera de estas capas puede rechazar independientemente la solicitud con una respuesta 413. Diagnosticar el error correctamente requiere identificar qué capa es la responsable.

Capa 1: Directivas del servidor web

Nginx aplica límites de tamaño de carga a través de la directiva client_max_body_size. Su valor predeterminado es 1MB, que es agresivamente bajo para la mayoría de las aplicaciones modernas. Esta directiva puede establecerse en el contexto de bloque http, server o location, y el bloque más específico tiene prioridad.

Apache utiliza la directiva LimitRequestBody, que por defecto es 0 (ilimitado) en la mayoría de las distribuciones — pero los proveedores de alojamiento habitualmente la sobreescriben en sus configuraciones globales o de host virtual a un valor restrictivo. Apache también procesa archivos .htaccess, lo que significa que el límite puede aplicarse a nivel de directorio sin tocar la configuración principal.

Capa 2: Configuración del tiempo de ejecución de PHP

PHP introduce dos directivas independientes que ambas deben satisfacerse para que una carga grande tenga éxito:

• upload_max_filesize — el tamaño máximo de un único archivo cargado
• post_max_size — el tamaño máximo del cuerpo completo de la solicitud POST, que debe ser igual o mayor que upload_max_filesize

Una configuración incorrecta común es establecer upload_max_filesize = 50M mientras se deja post_max_size en su valor predeterminado de 8M. El límite del cuerpo POST se evalúa primero, por lo que la carga falla silenciosamente antes de que se verifique el límite de tamaño de archivo.

También hay una tercera directiva que frecuentemente se pasa por alto: max_input_time, que define cuánto tiempo esperará PHP para recibir datos de entrada. En conexiones lentas que cargan archivos grandes, este tiempo de espera puede desencadenar un fallo que se manifiesta como un 413 o una respuesta en blanco.

Capa 3: Proxies inversos y balanceadores de carga

Si su infraestructura utiliza un proxy inverso — HAProxy, Varnish, Cloudflare, o una instancia de Nginx actuando como proxy frente a otro servidor — esa capa de proxy tiene sus propios límites de tamaño de cuerpo. Un 413 devuelto por Cloudflare, por ejemplo, tiene un límite estricto de 100MB en los planes gratuitos y Pro, y ninguna configuración del lado del servidor lo anulará. Siempre verifique los encabezados de respuesta de su capa de proxy para identificar el origen del 413.

Capa 4: Restricciones de aplicaciones y CMS

Los sistemas de gestión de contenido y los frameworks aplican sus propias restricciones de carga sobre las capas del servidor y PHP. WordPress lee el límite de carga efectivo de los valores del tiempo de ejecución de PHP, pero también aplica sus propias restricciones de biblioteca de medios. Algunos plugins de WordPress añaden capas de validación adicionales. Las aplicaciones PHP personalizadas pueden usar lógica de validación $_FILES que impone límites más estrictos de los que permite el servidor.

Configuración de Nginx: Solucionar el 413 a nivel del servidor web

Para Nginx, la solución requiere modificar client_max_body_size en el contexto de configuración correcto. Editar el bloque http aplica el límite globalmente; editar un bloque server o location lo aplica solo a ese host virtual o endpoint.

# Global setting — applies to all virtual hosts
http {
    client_max_body_size 100M;
}

# Per-virtual-host setting — preferred for multi-tenant environments
server {
    listen 80;
    server_name example.com;
    client_max_body_size 100M;

    # Granular control — apply only to the upload endpoint
    location /wp-admin/async-upload.php {
        client_max_body_size 256M;
    }
}

Después de editar, valide la sintaxis de la configuración antes de recargar:

nginx -t && systemctl reload nginx

Caso límite crítico: Si Nginx actúa como proxy inverso frente a PHP-FPM u otro servidor de aplicaciones, también debe verificar las directivas proxy_read_timeout y proxy_send_timeout. Una carga grande que tarde más que el tiempo de espera será terminada a mitad de la transferencia, produciendo un error 413 o 504 dependiendo del comportamiento del proxy.

Configuración de Apache: Solucionar el 413 a nivel del servidor web

La directiva LimitRequestBody de Apache acepta un valor en bytes. La directiva puede colocarse en httpd.conf, un bloque VirtualHost, un bloque Directory, o un archivo .htaccess.

# In httpd.conf or VirtualHost block
LimitRequestBody 104857600

# In .htaccess (if AllowOverride is enabled for the directory)
LimitRequestBody 104857600

El valor 104857600 equivale a 100MB (100 × 1024 × 1024). Después de modificar httpd.conf o un archivo de host virtual, reinicie Apache:

apachectl configtest && systemctl restart apache2

Matiz importante: En entornos de alojamiento compartido, las modificaciones de .htaccess pueden ignorarse si el proveedor de alojamiento ha establecido AllowOverride None en su configuración a nivel de servidor. En ese caso, solo el proveedor de alojamiento puede cambiar el límite. Esta es una de las principales razones técnicas para considerar migrar a un entorno de VPS Hosting donde tiene acceso root completo a la configuración del servidor.

Configuración de PHP: Solucionar el 413 a nivel del tiempo de ejecución

El archivo php.ini es la fuente autorizada para los límites de carga de PHP. El archivo correcto a editar depende de su modelo de ejecución de PHP (mod_php, PHP-FPM, CLI). Use phpinfo() o php --ini para identificar qué php.ini está realmente cargado.

; Minimum required changes for large file uploads
upload_max_filesize = 128M
post_max_size = 128M
max_input_time = 300
max_execution_time = 300
memory_limit = 256M

Después de editar php.ini, reinicie el servicio apropiado:

# For PHP-FPM
systemctl restart php8.2-fpm

# For Apache with mod_php
systemctl restart apache2

Métodos alternativos cuando php.ini no es accesible:

Si está en un plan de alojamiento compartido sin acceso directo a php.ini, puede ser capaz de anular la configuración de PHP usando:

1. Un archivo .user.ini en la raíz web (funciona con PHP-FPM):

upload_max_filesize = 64M
post_max_size = 64M

1. Una directiva .htaccess (funciona solo con mod_php):

php_value upload_max_filesize 64M
php_value post_max_size 64M

1. Código PHP en tiempo de ejecución (efectividad limitada, no recomendado para producción):

@ini_set('upload_max_filesize', '64M');
@ini_set('post_max_size', '64M');

Tenga en cuenta que ini_set() no puede anular upload_max_filesize o post_max_size en tiempo de ejecución en PHP 7.x y versiones posteriores — estas directivas se evalúan antes de que comience la ejecución del script. Los métodos .user.ini o .htaccess son mucho más confiables.

Solución específica para WordPress para errores 413

WordPress muestra su límite de carga efectivo en la pantalla Medios > Añadir nuevo. Si el límite mostrado es inferior a lo que ha configurado en php.ini, el problema generalmente es que WordPress está leyendo desde un proceso PHP diferente o que una capa de caché está sirviendo datos de configuración obsoletos.

Añada lo siguiente a wp-config.php para definir explícitamente el tamaño de carga:

@ini_set( 'upload_max_size', '128M' );
@ini_set( 'post_max_size', '128M' );
define( 'WP_MEMORY_LIMIT', '256M' );

Para instalaciones de WordPress Multisite, el tamaño de carga a nivel de red se controla por separado en Administración de red > Ajustes > Configuración de red > Tamaño máximo de archivo de carga. Esta configuración es independiente de los límites de PHP y debe configurarse además de los cambios a nivel de servidor.

Comparación: Dónde solucionar el 413 según el entorno de alojamiento

Diagnóstico de qué capa está devolviendo el 413

Antes de aplicar cualquier solución, confirme el origen de la respuesta 413. Use curl con salida detallada para inspeccionar los encabezados de respuesta:

curl -v -X POST -F "file=@/path/to/largefile.zip" https://example.com/upload

Examine el encabezado de respuesta Server y cualquier encabezado X-Powered-By o CF-RAY. Un encabezado CF-RAY indica que el 413 se originó en Cloudflare, no en su servidor. Una respuesta de nginx/1.x.x apunta a la capa de Nginx. La ausencia del encabezado Server puede indicar un balanceador de carga o WAF aguas arriba de su aplicación.

También verifique los registros de errores de su servidor inmediatamente después de provocar el 413:

# Nginx
tail -f /var/log/nginx/error.log

# Apache
tail -f /var/log/apache2/error.log

# PHP-FPM
tail -f /var/log/php8.2-fpm.log

Cuando la configuración del servidor no es suficiente: Consideraciones de infraestructura

Para aplicaciones que manejan rutinariamente transferencias de archivos grandes — plataformas de video, sistemas de respaldo, imágenes médicas, catálogos de productos de comercio electrónico a gran escala — codificar límites de carga altos en una configuración de servidor compartido no es una arquitectura sostenible. Considere estas alternativas:

• Cargas fragmentadas: Divida archivos grandes en fragmentos más pequeños en el lado del cliente usando bibliotecas como Resumable.js o Uppy. Cada fragmento está dentro del límite del servidor, y el servidor los reensambla. Esto evita el 413 por completo.
• Cargas directas al almacenamiento de objetos: Genere una URL prefirmada para almacenamiento compatible con S3 y haga que el cliente cargue directamente, evitando su servidor web por completo. El servidor web solo maneja la transacción de metadatos.
• Endpoints de carga dedicados: Configure un bloque location separado en Nginx con un client_max_body_size más alto específicamente para rutas de carga, manteniendo el límite predeterminado restrictivo para todos los demás endpoints.

Para cargas de trabajo intensivas en cómputo que involucran el procesamiento de archivos grandes — transcodificación de video, inferencia de aprendizaje automático sobre datos cargados — un entorno de GPU Hosting proporciona la capacidad de procesamiento para manejar tanto la carga como el cómputo posterior sin cuellos de botella.

Si su aplicación requiere un entorno de panel de control gestionado con acceso completo a la configuración de PHP, un VPS con cPanel le ofrece el Editor MultiPHP INI en WHM, permitiendo anulaciones de directivas PHP por dominio sin tocar la línea de comandos.

Consideraciones de seguridad al aumentar los límites de carga

Aumentar los límites de carga sin el correspondiente endurecimiento de seguridad introduce una superficie de ataque real. Un servidor que acepta solicitudes POST de 500MB es un objetivo viable para ataques de denegación de servicio que agotan el I/O de disco, la memoria o los grupos de conexiones.

Implemente los siguientes controles junto con cualquier aumento de límite:

• Limitación de velocidad en endpoints de carga: En Nginx, use limit_req_zone para restringir la frecuencia de carga por IP.
• Validación del tipo de archivo: Nunca confíe en el tipo MIME proporcionado por el cliente. Valide las firmas de archivo (bytes mágicos) en el lado del servidor.
• Permisos del directorio de carga: El directorio que recibe las cargas no debe ser accesible desde la web ni ejecutable. Almacene las cargas fuera de la raíz del documento.
• Análisis de virus: Integre ClamAV o un escáner similar en el pipeline de carga para cualquier endpoint de carga accesible públicamente.
• Cargas solo autenticadas: Requiera autenticación antes de aceptar cargas útiles grandes. Los endpoints de carga grande no autenticados son trivialmente abusados.

Para entornos de producción que manejan datos cargados sensibles, combinar su infraestructura de alojamiento con SSL Certificates correctamente configurados garantiza que las transferencias de archivos estén cifradas en tránsito, evitando la interceptación del contenido cargado.

Matriz de decisión técnica: Elegir la solución correcta

Lista de verificación práctica para resolver HTTP 413

• Identifique la capa que devuelve el 413 usando curl -v y los registros de errores del servidor antes de realizar cualquier cambio
• En Nginx, establezca client_max_body_size en el bloque aplicable más específico (location preferido sobre server sobre http)
• Asegúrese de que post_max_size sea siempre mayor o igual que upload_max_filesize en php.ini
• Aumente max_input_time y max_execution_time para archivos grandes en conexiones lentas
• Verifique que las anulaciones de .htaccess estén permitidas (AllowOverride All o AllowOverride Options) antes de depender de ellas
• Verifique todas las capas de proxy de forma independiente — CDN, balanceador de carga y servidor de aplicaciones aplican límites por separado
• Después de cualquier cambio de configuración, recargue (no solo reinicie) el servicio relevante y limpie cualquier caché de opcode o de página
• Para WordPress Multisite, configure el límite de carga a nivel de red además de las directivas de PHP
• Implemente limitación de velocidad y validación del tipo de archivo antes de aumentar los límites en endpoints de carga de acceso público
• Si el alojamiento compartido impide el acceso a la configuración, migre a un entorno de VPS Hosting o Dedicated Servers para tener control total

Preguntas frecuentes

¿Cuál es el límite de carga predeterminado en Nginx que causa un error 413?

Nginx establece client_max_body_size en 1MB de forma predeterminada. Cualquier cuerpo de solicitud que supere 1MB devolverá un 413 a menos que esta directiva se aumente explícitamente en la configuración de Nginx.

¿Puedo solucionar un error 413 sin acceso root al servidor?

En alojamiento compartido, puede intentar soluciones mediante .htaccess (solo Apache, si AllowOverride lo permite) o un archivo .user.ini (solo PHP-FPM). Sin embargo, si el proveedor de alojamiento ha establecido límites globales restrictivos, estos métodos serán ineficaces y deberá contactar al soporte o actualizar a un plan VPS.

¿Por qué falla mi carga incluso después de aumentar upload_max_filesize en php.ini?

La causa más común es que post_max_size permanece en su valor predeterminado más bajo. PHP evalúa el límite de tamaño del cuerpo POST antes del límite de tamaño de archivo individual, por lo que la carga se rechaza antes de que se verifique upload_max_filesize. Siempre aumente ambas directivas simultáneamente.

¿Cloudflare causa errores 413?

Sí. Cloudflare aplica sus propios límites de tamaño del cuerpo de solicitud: 100MB en los planes Free y Pro, 200MB en Business y 500MB en Enterprise. Si su solicitud supera estos límites, Cloudflare devuelve un 413 antes de que la solicitud llegue a su servidor de origen. Ningún cambio de configuración del lado del servidor resolverá esto — debe actualizar su plan de Cloudflare, usar bypass de carga directa (URLs prefirmadas) o implementar cargas fragmentadas.

¿Cómo soluciono permanentemente el 413 en WordPress en un servidor cPanel?

Use el Editor MultiPHP INI de WHM para aumentar upload_max_filesize y post_max_size para la versión de PHP y el dominio específicos. Luego verifique que el cambio se refleje en WordPress en Medios > Añadir nuevo. Para WordPress Multisite, actualice adicionalmente el tamaño máximo de carga en Administración de red > Ajustes. No se requieren cambios en .htaccess o wp-config.php cuando se usa el editor INI de WHM directamente.