Como resolver 413 Request Entity Too Large ao enviar arquivos para uma VPS (2026): diagnóstico de limites do Nginx, PHP e Cloudflare

Primeiro use as ferramentas de desenvolvedor do navegador para ver os cabeçalhos de resposta, ou use curl diretamente:

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

Se a resposta contiver:

Server: nginx

provavelmente o Nginx está bloqueando primeiro.

Se você tem o Cloudflare na frente, os cabeçalhos de resposta podem mostrar:

server: cloudflare
cf-ray: xxxxx

Nesse ponto você precisa distinguir se foi o Cloudflare que rejeitou ou se o Cloudflare encaminhou e a origem rejeitou.

Depois veja os logs do Nginx:

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

Um log típico é:

client intended to send too large body: 20971520 bytes

Ao ver essa linha, a direção fica clara: o limite de tamanho do corpo da requisição do Nginx está pequeno demais.

O limite padrão do Nginx costuma ser bem pequeno; em muitos ambientes é 1MB. Pode não ser suficiente nem para enviar imagens.

Abra a configuração do site:

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

Ou sua configuração está em:

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

Adicione isto dentro do bloco server:

server {
    server_name example.com;

    client_max_body_size 100M;

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

Se você quiser aumentar o limite apenas para um endpoint de upload específico, também pode colocá-lo dentro de location:

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

Não é recomendado escrever 0 para remover o limite por completo. Se o endpoint de upload não tiver limite algum, requisições maliciosas podem facilmente encher o disco, a memória ou o diretório temporário.

Depois de alterar, teste primeiro:

sudo nginx -t

Se não houver problema, recarregue:

sudo systemctl reload nginx

Se você usa OpenResty, BT Nginx ou Nginx Proxy Manager, a essência é a mesma: procure client_max_body_size, só muda o ponto de entrada da configuração.

Muitas pessoas alteram apenas o Nginx, o 413 some, mas aí a página de upload avisa que o arquivo é grande demais. Isso acontece porque a requisição finalmente chega ao PHP, e o PHP a bloqueia de novo.

Primeiro encontre o arquivo de configuração do PHP:

php --ini

Se você roda PHP-FPM, versões diferentes podem estar em:

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

Altere estes valores:

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

Atenção: post_max_size deve ser maior ou igual a upload_max_filesize.

Se você quer enviar arquivos de 100MB, eu costumo configurar assim:

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

Depois de alterar, reinicie o PHP-FPM:

sudo systemctl restart php8.2-fpm

Altere o número da versão conforme a sua máquina. Você pode verificar com:

systemctl list-units | grep php | grep fpm

Os usuários de WordPress são os que mais ficam presos aqui.

O Nginx e o PHP foram alterados, mas a biblioteca de mídia do painel ainda mostra upload máximo de 2MB, 8MB ou 32MB. Isso significa que o PHP-FPM não leu a configuração que você alterou, ou que ainda há um painel/plugin limitando.

Você pode colocar temporariamente um phpinfo.php no diretório do site:

<?php phpinfo();

Depois de acessar, procure:

upload_max_filesize
post_max_size
Loaded Configuration File

Confirme que a página mostra os novos valores.

Lembre-se de apagar depois de verificar:

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

No WordPress, também verifique:

• Se algum plugin de segurança limita uploads;
• Se o tema ou algum plugin impõe seu próprio limite de tamanho de arquivo;
• Se há configuração relevante em wp-config.php;
• Se a configuração de PHP no painel BT sobrescreve suas alterações manuais.

Não olhe apenas o php --ini da linha de comando; o site na verdade usa PHP-FPM, e os dois arquivos de configuração podem não ser o mesmo.

Se a sua arquitetura for:

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

então o Nginx da frente precisa aumentar o limite, e o serviço de trás também precisa aumentá-lo.

Por exemplo, Nginx como proxy reverso para Node:

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

O Express também pode ter um limite de body:

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

Laravel / Symfony / Django / Rails também têm seus próprios limites de upload. O Nginx permitir a requisição não significa que a aplicação vai aceitá-la.

Então, se o log do Nginx não tem 413 mas o log da aplicação tem erros de upload, vá verificar a camada da aplicação.

Se o site tem o Cloudflare na frente, não esqueça que ele também tem limites.

Os limites de tamanho de upload do Cloudflare variam conforme o plano. O plano gratuito e os planos de entrada geralmente não são adequados para enviar diretamente arquivos muito grandes.

Se você precisa enviar pacotes de backup de centenas de MB, é melhor não usar o upload web comum. Os métodos mais confiáveis são:

• Enviar para a VPS com SFTP / SCP;
• Enviar diretamente para o armazenamento de objetos;
• Mudar o upload do backend para upload em partes;
• Pausar temporariamente o proxy e testar com conexão direta à origem em nuvem cinza.

Ao testar, você pode mudar o registro DNS de nuvem laranja para nuvem cinza, contornar o Cloudflare e ver se o 413 desaparece.

Se funcionar normalmente após contornar, então não é problema do Nginx ou do PHP da VPS, mas sim um limite da camada de CDN.

Muitas pessoas rodam WordPress, Nextcloud ou Laravel com Docker, depois alteram o /etc/nginx na máquina host e não tem efeito nenhum.

Primeiro confirme onde está o Nginx:

docker ps

Se o Nginx está dentro de um contêiner, a configuração também está dentro do contêiner, ou é montada para fora por meio de um volume.

Caminhos comuns:

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

Depois de alterar, recarregue o Nginx dentro do contêiner ou reinicie o contêiner:

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

Se você usa docker compose:

docker compose restart nginx

O Nextcloud também exige verificar o PHP e a configuração da própria aplicação. Alterar apenas a camada do proxy reverso muitas vezes não é suficiente.

Se você só envia imagens de 50MB ocasionalmente, aumentar o limite para 100M não é grande problema.

Mas se você envia com frequência pacotes de backup de 1GB ou 5GB, não é recomendado simplesmente aumentar muito o limite. O motivo é simples:

• Uploads interrompidos facilmente precisam recomeçar;
• Os arquivos temporários do Nginx podem encher o disco;
• O PHP tende a atingir timeout ao lidar com arquivos grandes;
• Quanto mais longa a cadeia de proxy reverso, mais pontos de falha existem;
• Requisições maliciosas podem saturar mais facilmente a largura de banda e o disco.

Para esses cenários, é mais adequado:

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

Ou usar rsync:

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

Se o backend do site permite que usuários enviem arquivos grandes, recomenda-se implementar upload em partes ou upload direto para o armazenamento de objetos, em vez de deixar todos os arquivos grandes passarem pelo PHP.

Quando encontro um 413, normalmente sigo esta ordem:

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

Depois de confirmar o Nginx, verifico o PHP:

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

Se for WordPress, uso o phpinfo() para confirmar os valores realmente lidos pelo ambiente web.

Se houver Cloudflare na frente, faço mais um teste de conexão direta em nuvem cinza.

Para sites comuns que enviam imagens, temas e plugins, normalmente isto é 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

Se você só precisa enviar arquivos de 20MB, não altere diretamente para 1GB. Maior nem sempre é melhor; basta ser suficiente.

A essência do 413 é "o corpo da requisição é grande demais", mas o verdadeiro problema é que cada camada da cadeia tem seu próprio limite superior. Verifique na ordem Nginx, PHP, aplicação, CDN e Docker, e basicamente você não vai errar o caminho.