HTTP 413 Request Entity Too Large: Causas Raiz, Correções e Guia de Configuração do Servidor

O erro HTTP 413 Request Entity Too Large é um código de status de resposta do lado do servidor que ocorre quando o corpo de uma solicitação recebida — mais comumente um upload de arquivo — excede o tamanho máximo de payload configurado no servidor web, proxy reverso ou camada de aplicação. O servidor rejeita ativamente a solicitação antes de processá-la, retornando um status 413 ao cliente.

Este erro não é um bug do lado do cliente. É um mecanismo de aplicação deliberado incorporado em servidores web como Nginx e Apache, configurações de tempo de execução PHP e middleware de nível de aplicação. Entender exatamente qual camada está aplicando o limite — e como direcionar a diretiva de configuração correta — é a diferença entre uma correção limpa e horas de resolução de problemas.

Por Que Ocorrem Erros HTTP 413: Uma Análise Camada por Camada

Uma solicitação de upload de arquivo passa por múltiplas camadas de processamento antes de chegar à sua aplicação. Qualquer uma dessas camadas pode rejeitar independentemente a solicitação com uma resposta 413. Diagnosticar o erro corretamente requer identificar qual camada é responsável.

Camada 1: Diretivas do Servidor Web

O Nginx aplica limites de tamanho de upload através da diretiva client_max_body_size. Seu valor padrão é 1MB, que é agressivamente baixo para a maioria das aplicações modernas. Esta diretiva pode ser definida no contexto de bloco http, server ou location, e o bloco mais específico prevalece.

O Apache usa a diretiva LimitRequestBody, que tem como padrão 0 (ilimitado) na maioria das distribuições — mas os provedores de hospedagem rotineiramente substituem isso em suas configurações globais ou de host virtual por um valor restritivo. O Apache também processa arquivos .htaccess, o que significa que o limite pode ser aplicado no nível do diretório sem tocar na configuração principal.

Camada 2: Configuração de Tempo de Execução PHP

O PHP introduz duas diretivas independentes que ambas devem ser satisfeitas para que um upload grande seja bem-sucedido:

• upload_max_filesize — o tamanho máximo de um único arquivo enviado
• post_max_size — o tamanho máximo do corpo inteiro da solicitação POST, que deve ser igual ou maior que upload_max_filesize

Uma configuração incorreta comum é definir upload_max_filesize = 50M enquanto deixa post_max_size em seu padrão de 8M. O limite do corpo POST é avaliado primeiro, portanto o upload falha silenciosamente antes mesmo de o limite de tamanho do arquivo ser verificado.

Há também uma terceira diretiva frequentemente ignorada: max_input_time, que define por quanto tempo o PHP aguardará para receber dados de entrada. Em conexões lentas fazendo upload de arquivos grandes, esse tempo limite pode desencadear uma falha que se manifesta como um 413 ou uma resposta em branco.

Camada 3: Proxies Reversos e Balanceadores de Carga

Se sua infraestrutura usa um proxy reverso — HAProxy, Varnish, Cloudflare ou uma instância Nginx atuando como proxy na frente de outro servidor — essa camada de proxy tem seus próprios limites de tamanho de corpo. Um 413 retornado pelo Cloudflare, por exemplo, tem um limite rígido de 100MB nos planos gratuito e Pro, e nenhuma quantidade de configuração do lado do servidor irá substituí-lo. Sempre verifique os cabeçalhos de resposta da sua camada de proxy para identificar a origem do 413.

Camada 4: Restrições de Aplicação e CMS

Sistemas de gerenciamento de conteúdo e frameworks aplicam suas próprias restrições de upload além das camadas de servidor e PHP. O WordPress lê o limite de upload efetivo dos valores de tempo de execução do PHP, mas também aplica suas próprias restrições de biblioteca de mídia. Alguns plugins do WordPress adicionam camadas de validação adicionais. Aplicações PHP personalizadas podem usar lógica de validação $_FILES que impõe limites mais rígidos do que o servidor permite.

Configuração Nginx: Corrigindo 413 no Nível do Servidor Web

Para o Nginx, a correção requer modificar client_max_body_size no contexto de configuração correto. Editar o bloco http aplica o limite globalmente; editar um bloco server ou location aplica-o apenas a esse host virtual ou 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;
    }
}

Após editar, valide a sintaxe da configuração antes de recarregar:

nginx -t && systemctl reload nginx

Caso extremo crítico: Se o Nginx estiver atuando como proxy reverso na frente do PHP-FPM ou de outro servidor de aplicação, você também deve verificar as diretivas proxy_read_timeout e proxy_send_timeout. Um upload grande que demorar mais do que o tempo limite será encerrado no meio da transferência, produzindo um erro 413 ou 504 dependendo do comportamento do proxy.

Configuração Apache: Corrigindo 413 no Nível do Servidor Web

A diretiva LimitRequestBody do Apache aceita um valor em bytes. A diretiva pode ser colocada em httpd.conf, um bloco VirtualHost, um bloco Directory, ou um arquivo .htaccess.

# In httpd.conf or VirtualHost block
LimitRequestBody 104857600

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

O valor 104857600 equivale a 100MB (100 × 1024 × 1024). Após modificar httpd.conf ou um arquivo de host virtual, reinicie o Apache:

apachectl configtest && systemctl restart apache2

Nuance importante: Em ambientes de hospedagem compartilhada, as modificações em .htaccess podem ser ignoradas se o provedor de hospedagem tiver definido AllowOverride None em sua configuração de nível de servidor. Nesse caso, apenas o provedor de hospedagem pode alterar o limite. Esta é uma das principais razões técnicas para considerar a migração para um ambiente de VPS Hosting onde você tem acesso root completo à configuração do servidor.

Configuração PHP: Corrigindo 413 no Nível de Tempo de Execução

O arquivo php.ini é a fonte autoritativa para limites de upload do PHP. O arquivo correto a editar depende do seu modelo de execução PHP (mod_php, PHP-FPM, CLI). Use phpinfo() ou php --ini para identificar qual php.ini está realmente carregado.

; 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

Após editar php.ini, reinicie o serviço apropriado:

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

# For Apache with mod_php
systemctl restart apache2

Métodos alternativos quando php.ini não está acessível:

Se você estiver em um plano de hospedagem compartilhada sem acesso direto a php.ini, pode ser possível substituir as configurações PHP usando:

1. Um arquivo .user.ini na raiz web (funciona com PHP-FPM):

upload_max_filesize = 64M
post_max_size = 64M

1. Uma diretiva .htaccess (funciona apenas com mod_php):

php_value upload_max_filesize 64M
php_value post_max_size 64M

1. Código PHP em tempo de execução (eficácia limitada, não recomendado para produção):

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

Observe que ini_set() não pode substituir upload_max_filesize ou post_max_size em tempo de execução no PHP 7.x e posterior — essas diretivas são avaliadas antes do início da execução do script. Os métodos .user.ini ou .htaccess são muito mais confiáveis.

Correção Específica para WordPress para Erros 413

O WordPress exibe seu limite de upload efetivo na tela Mídia > Adicionar Novo. Se o limite exibido for menor do que o que você configurou em php.ini, o problema geralmente é que o WordPress está lendo de um processo PHP diferente ou que uma camada de cache está servindo dados de configuração desatualizados.

Adicione o seguinte ao wp-config.php para definir explicitamente o tamanho do upload:

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

Para instalações WordPress Multisite, o tamanho de upload no nível da rede é controlado separadamente em Administração da Rede > Configurações > Configurações da Rede > Tamanho máximo do arquivo de upload. Esta configuração é independente dos limites PHP e deve ser configurada além das alterações no nível do servidor.

Comparação: Onde Corrigir 413 com Base no Ambiente de Hospedagem

Diagnosticando Qual Camada Está Retornando o 413

Antes de aplicar qualquer correção, confirme a origem da resposta 413. Use curl com saída detalhada para inspecionar os cabeçalhos de resposta:

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

Examine o cabeçalho de resposta Server e quaisquer cabeçalhos X-Powered-By ou CF-RAY. Um cabeçalho CF-RAY indica que o 413 originou no Cloudflare, não no seu servidor. Uma resposta de nginx/1.x.x aponta para a camada Nginx. Nenhum cabeçalho Server pode indicar um balanceador de carga ou WAF upstream da sua aplicação.

Verifique também os logs de erro do servidor imediatamente após acionar o 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

Quando a Configuração do Servidor Não É Suficiente: Considerações de Infraestrutura

Para aplicações que rotineiramente lidam com grandes transferências de arquivos — plataformas de vídeo, sistemas de backup, imagens médicas, catálogos de produtos de e-commerce em grande escala — codificar limites de upload elevados em uma configuração de servidor compartilhado não é uma arquitetura sustentável. Considere estas alternativas:

• Uploads fragmentados: Divida arquivos grandes em fragmentos menores no lado do cliente usando bibliotecas como Resumable.js ou Uppy. Cada fragmento está dentro do limite do servidor, e o servidor os remonta. Isso contorna completamente o 413.
• Uploads diretos para armazenamento de objetos: Gere uma URL pré-assinada para armazenamento compatível com S3 e faça o cliente fazer o upload diretamente, contornando completamente o seu servidor web. O servidor web lida apenas com a transação de metadados.
• Endpoints de upload dedicados: Configure um bloco location separado no Nginx com um client_max_body_size maior especificamente para rotas de upload, mantendo o limite padrão restritivo para todos os outros endpoints.

Para cargas de trabalho computacionalmente intensivas envolvendo processamento de arquivos grandes — transcodificação de vídeo, inferência de aprendizado de máquina em dados enviados — um ambiente de GPU Hosting fornece a capacidade de processamento para lidar tanto com o upload quanto com a computação subsequente sem gargalos.

Se sua aplicação requer um ambiente de painel de controle gerenciado com acesso completo à configuração PHP, um VPS with cPanel oferece o Editor MultiPHP INI no WHM, permitindo substituições de diretivas PHP por domínio sem tocar na linha de comando.

Considerações de Segurança ao Aumentar Limites de Upload

Aumentar os limites de upload sem o endurecimento de segurança correspondente introduz uma superfície de ataque real. Um servidor que aceita solicitações POST de 500MB é um alvo viável para ataques de negação de serviço que esgotam I/O de disco, memória ou pools de conexão.

Implemente os seguintes controles juntamente com qualquer aumento de limite:

• Limitação de taxa em endpoints de upload: No Nginx, use limit_req_zone para restringir a frequência de upload por IP.
• Validação de tipo de arquivo: Nunca confie no tipo MIME fornecido pelo cliente. Valide assinaturas de arquivo (bytes mágicos) no lado do servidor.
• Permissões do diretório de upload: O diretório que recebe uploads não deve ser acessível pela web ou executável. Armazene uploads fora da raiz do documento.
• Verificação de vírus: Integre o ClamAV ou um scanner similar ao pipeline de upload para qualquer endpoint de upload acessível publicamente.
• Uploads apenas autenticados: Exija autenticação antes de aceitar grandes payloads. Endpoints de upload grandes não autenticados são trivialmente abusados.

Para ambientes de produção que lidam com dados enviados sensíveis, combinar sua infraestrutura de hospedagem com SSL Certificates devidamente configurados garante que as transferências de arquivos sejam criptografadas em trânsito, evitando a interceptação do conteúdo enviado.

Matriz de Decisão Técnica: Escolhendo a Correção Certa

Lista de Verificação Prática para Resolver HTTP 413

• Identifique a camada que retorna o 413 usando curl -v e logs de erro do servidor antes de fazer qualquer alteração
• No Nginx, defina client_max_body_size no bloco aplicável mais específico (location preferido sobre server sobre http)
• Certifique-se de que post_max_size seja sempre maior ou igual a upload_max_filesize em php.ini
• Aumente max_input_time e max_execution_time para arquivos grandes em conexões lentas
• Verifique se as substituições de .htaccess são permitidas (AllowOverride All ou AllowOverride Options) antes de depender delas
• Verifique todas as camadas de proxy independentemente — CDN, balanceador de carga e servidor de aplicação aplicam limites separadamente
• Após qualquer alteração de configuração, recarregue (não apenas reinicie) o serviço relevante e limpe qualquer cache de opcode ou de página
• Para WordPress Multisite, configure o limite de upload no nível da rede além das diretivas PHP
• Implemente limitação de taxa e validação de tipo de arquivo antes de aumentar limites em endpoints de upload voltados ao público
• Se a hospedagem compartilhada impedir o acesso à configuração, migre para um ambiente de VPS Hosting ou Dedicated Servers para controle total

Perguntas Frequentes

Qual é o limite de upload padrão no Nginx que causa um erro 413?

O Nginx define client_max_body_size como padrão de 1MB. Qualquer corpo de solicitação que exceda 1MB retornará um 413, a menos que esta diretiva seja explicitamente aumentada na configuração do Nginx.

Posso corrigir um erro 413 sem acesso root ao servidor?

Em hospedagem compartilhada, você pode tentar correções via .htaccess (apenas Apache, se AllowOverride permitir) ou um arquivo .user.ini (apenas PHP-FPM). No entanto, se o provedor de hospedagem tiver definido limites globais restritivos, esses métodos serão ineficazes e você precisará contactar o suporte ou fazer upgrade para um plano VPS.

Por que meu upload falha mesmo após aumentar upload_max_filesize em php.ini?

A causa mais comum é que post_max_size permanece em seu valor padrão mais baixo. O PHP avalia o limite de tamanho do corpo POST antes do limite de tamanho de arquivo individual, portanto o upload é rejeitado antes mesmo de upload_max_filesize ser verificado. Sempre aumente ambas as diretivas simultaneamente.

O Cloudflare causa erros 413?

Sim. O Cloudflare aplica seus próprios limites de tamanho de corpo de solicitação: 100MB nos planos Gratuito e Pro, 200MB no Business e 500MB no Enterprise. Se sua solicitação exceder esses limites, o Cloudflare retorna um 413 antes que a solicitação chegue ao seu servidor de origem. Nenhuma alteração de configuração do lado do servidor resolverá isso — você deve fazer upgrade do seu plano Cloudflare, usar bypass de upload direto (URLs pré-assinadas) ou implementar uploads fragmentados.

Como corrijo permanentemente o 413 no WordPress em um servidor cPanel?

Use o Editor MultiPHP INI do WHM para aumentar upload_max_filesize e post_max_size para a versão PHP e domínio específicos. Em seguida, verifique se a alteração está refletida no WordPress em Mídia > Adicionar Novo. Para WordPress Multisite, atualize adicionalmente o tamanho máximo de upload em Administração da Rede > Configurações. Nenhuma alteração em .htaccess ou wp-config.php é necessária ao usar o editor INI do WHM diretamente.