Como corrigir erro 413 no Nginx Proxy Manager: guia prático

O erro 413 Request Entity Too Large no Nginx Proxy Manager ocorre quando o corpo da requisição ultrapassa o limite configurado no proxy reverso, bloqueando uploads antes que o backend os processe. Para corrigir, identifique em qual camada o bloqueio acontece e ajuste client_max_body_size no Proxy Host afetado pelo painel do Nginx Proxy Manager.

1. Identifique o domínio e o Proxy Host que retorna HTTP 413.
2. Verifique os logs do Nginx Proxy Manager e procure mensagens de corpo grande.
3. Adicione client_max_body_size na aba Advanced do Proxy Host.
4. Salve a alteração e teste novamente o upload pelo domínio real.
5. Se continuar, confira limites menores na aplicação de destino ou em outro proxy na frente.
6. Reinicie o container somente se a configuração salva não for aplicada.

Pré-requisitos

• Acesso administrativo ao painel do Nginx Proxy Manager.
• Acesso SSH ao servidor onde o Nginx Proxy Manager roda em Docker, se você precisar consultar logs pelo terminal.
• Nome do container do Nginx Proxy Manager, que pode variar conforme o seu docker compose.
• Domínio afetado pelo erro, por exemplo seudominio.com.br.
• Conhecimento do serviço de backend que recebe o upload, pois ele também pode impor limite próprio.
• Janela de manutenção curta caso seja necessário reiniciar o container do proxy.

Como o erro 413 aparece no Nginx Proxy Manager

Erro 413 Request Entity Too Large no Nginx Proxy Manager aparece com frequência quando o Proxy Host volta ao limite padrão de corpo da requisição — seja após uma configuração inicial, restauração de volumes ou troca de servidor. Na prática, o navegador envia um arquivo, uma imagem, um backup, um pacote de mídia ou uma chamada de API com corpo grande, e a camada de proxy rejeita antes que o serviço de destino consiga processar.

O primeiro cuidado é não presumir que o problema está apenas na aplicação. Em um fluxo comum, a requisição passa por navegador, DNS, possível CDN, Nginx Proxy Manager e backend. Se qualquer camada tiver limite menor, o usuário verá falha no upload. Por isso, a correção correta é diagnosticar o ponto de bloqueio e manter os limites coerentes entre proxy e aplicação.

1. Acesse o painel do Nginx Proxy Manager.
2. Entre em Proxy Hosts e localize o host de seudominio.com.br.
3. Abra o host afetado e vá até a seção Advanced.
4. Adicione um limite explícito com client_max_body_size.
5. Salve e repita o upload que antes retornava 413.

client_max_body_size 200m;

Output esperado:
Configuração salva no Proxy Host.
Novo teste de upload não deve retornar HTTP 413 na camada do Nginx Proxy Manager.

Use um valor compatível com o seu caso real. Se o maior arquivo permitido pela aplicação for 100 MB, por exemplo, configurar 200 MB no proxy evita que o Nginx Proxy Manager seja o primeiro bloqueio, mas não substitui o limite interno da aplicação.

Diagnóstico do 413 no Nginx Proxy Manager em Docker

Logs do Nginx Proxy Manager para erro 413 ajudam a confirmar se o bloqueio acontece no proxy ou depois dele. Ao rodar os comandos abaixo, você verá o container ativo e poderá procurar mensagens relacionadas a corpo de requisição grande, como respostas HTTP 413 ou indicação de que o cliente tentou enviar um corpo maior que o permitido.

Se você ainda não acessou seu servidor por SSH, o artigo Acessando servidores VPS Linux da AviraHost pode ajudar no acesso inicial. Depois de conectado, liste os containers para descobrir o nome correto do serviço do Nginx Proxy Manager.

docker ps

Output esperado:
CONTAINER ID   IMAGE                 COMMAND                  STATUS          PORTS
abc123def456   jc21/nginx-proxy-manager:latest   "/init"      Up              80/tcp, 443/tcp, 81/tcp

Com o nome do container em mãos, consulte os logs recentes. Substitua nginx-proxy-manager pelo nome real exibido no seu ambiente. Em setups baseados em docker-compose.yml, o nome do serviço pode incluir prefixos do projeto.

docker logs --tail 100 nginx-proxy-manager 2>&1 | grep -Ei "413|too large|request body"

Output esperado:
client intended to send too large body
HTTP/1.1 413 Request Entity Too Large

Se esse padrão aparecer nos logs do container, o ajuste em client_max_body_size no Proxy Host é o caminho mais direto. Se não aparecer nada no Nginx Proxy Manager, a resposta 413 pode estar vindo de outro proxy antes dele — incluindo CDN como o Cloudflare, que impõe limite próprio de 100 MB no plano gratuito — ou do backend depois dele.

Aumentar limite de upload no Nginx Proxy Manager

Aumentar limite de upload no Nginx Proxy Manager deve ser feito no Proxy Host específico, não de forma genérica sem necessidade. Isso reduz risco de liberar uploads grandes para domínios que não precisam desse comportamento e facilita auditoria quando houver múltiplos sites atrás do mesmo painel.

1. No painel, abra Hosts e depois Proxy Hosts.
2. Clique nos três pontos do domínio afetado e escolha editar.
3. Confirme se Domain Names contém seudominio.com.br.
4. Na aba Advanced, insira a diretiva client_max_body_size.
5. Salve e aguarde o recarregamento da configuração do host.

client_max_body_size 500m;

Output esperado:
Proxy Host salvo sem erro.
O domínio continua respondendo em HTTP/HTTPS.
Uploads até o limite configurado deixam de ser bloqueados pelo proxy.

O valor ideal depende do arquivo aceito pelo seu sistema. Para um painel que recebe anexos pequenos, 50 MB pode ser suficiente. Para importação de mídia, backup ou pacote grande, talvez seja necessário 200 MB, 500 MB ou outro limite coerente. Evite configurar tamanhos muito altos sem necessidade, porque requisições grandes consomem recurso durante o recebimento e encaminhamento.

Se o domínio também usa redirecionamento HTTP para HTTPS, vale revisar se a rota final está correta. Quando houver dúvida sobre o redirecionamento básico, consulte Como redirecionar um site http para https? e confirme se o upload está sendo testado no endereço final.

Validar client_max_body_size aplicado no Proxy Host

client_max_body_size no Nginx Proxy Manager precisa estar presente na configuração carregada para surtir efeito. Salvar pelo painel normalmente recarrega o host, mas em troubleshooting técnico é útil validar a configuração dentro do container, especialmente após restauração de volumes Docker.

Atenção: os comandos abaixo não alteram arquivos, mas expõem a configuração carregada. Execute em uma sessão segura e evite colar saídas completas em locais públicos, pois elas podem conter nomes de domínios internos.

docker exec nginx-proxy-manager nginx -T 2>&1 | grep -n "client_max_body_size"

Output esperado:
client_max_body_size 500m;

Se o comando não retornar o valor configurado, volte ao painel e confirme se a diretiva foi adicionada no Proxy Host certo. Ambientes com múltiplos hosts podem ter entradas parecidas, como www.seudominio.com.br e seudominio.com.br. Testar o domínio errado é uma causa comum de falsa correção.

Também valide o caminho HTTP com uma requisição simples. O objetivo aqui não é provar o upload completo, mas confirmar que você está chegando no mesmo proxy reverso que foi ajustado.

curl -I https://seudominio.com.br

Output esperado:
HTTP/2 200
ou
HTTP/2 301
ou
HTTP/2 302

Respostas como 301 ou 302 podem ser normais quando existe redirecionamento. O ponto principal é garantir que o domínio acessado no teste seja o mesmo configurado no Nginx Proxy Manager.

Testar upload grande sem confundir proxy e backend

Upload grande em proxy reverso deve ser testado de forma controlada. Um erro comum é alterar o Nginx Proxy Manager, testar uma página diferente da rota de upload e concluir que a correção falhou. O teste precisa reproduzir o endpoint real que antes retornava 413.

Você pode criar um arquivo de teste temporário no seu computador ou no servidor apenas para simular tamanho. O comando abaixo cria um arquivo vazio alocado logicamente, útil para testar comportamento de upload quando o endpoint aceita envio por formulário ou API.

truncate -s 150M arquivo-teste-upload.bin

Output esperado:
Arquivo criado com tamanho lógico de 150M.
Nenhuma mensagem indica sucesso na maioria dos sistemas.

Atenção: remova o arquivo de teste depois de validar, para evitar confusão operacional e consumo desnecessário de espaço quando o sistema realmente alocar dados.

ls -lh arquivo-teste-upload.bin

Output esperado:
-rw-r--r-- 1 usuario usuario 150M arquivo-teste-upload.bin

Agora repita o envio pelo mesmo formulário, painel ou rota da aplicação. Se o retorno deixar de ser 413 e passar a ser uma resposta da própria aplicação, como autenticação exigida, validação de tipo de arquivo ou limite interno, isso indica que o Nginx Proxy Manager já não é o bloqueio principal. Nesse ponto, o próximo ajuste deve ser feito no backend.

Confirmar limites da aplicação atrás do Nginx Proxy Manager

Backend com limite menor que o proxy é a principal razão para o erro 413 continuar mesmo após ajustar o Nginx Proxy Manager. O proxy pode aceitar 500 MB, mas uma aplicação PHP com post_max_size e upload_max_filesize menores, Node.js, WordPress, API interna ou outro Nginx atrás dele ainda pode rejeitar o corpo da requisição antes de processar o arquivo.

A validação prática é comparar o comportamento dos logs. Se o Nginx Proxy Manager não registra mais mensagens de corpo grande, mas o navegador ainda mostra 413, consulte os logs do serviço de destino. Em ambientes Docker, identifique o container do backend e filtre por 413, upload ou mensagens de limite.

docker ps

Output esperado:
CONTAINER ID   IMAGE          COMMAND        STATUS       PORTS
def456abc123   app-backend    "start-app"    Up           3000/tcp

docker logs --tail 100 app-backend 2>&1 | grep -Ei "413|upload|too large|limit"

Output esperado:
Mensagem de limite da aplicação, se o backend estiver bloqueando.
Sem retorno, se não houver registros correspondentes nos últimos logs.

Quando o backend for o responsável, ajuste o limite nele com o mesmo critério operacional usado no proxy. Não aumente tudo indiscriminadamente. Defina o tamanho máximo aceito pelo produto, documente o motivo e teste novamente pelo domínio público que passa pelo Nginx Proxy Manager.

Reiniciar o Nginx Proxy Manager com segurança

Reiniciar container do Nginx Proxy Manager é uma ação de último passo quando salvar o Proxy Host não aplica a configuração ou quando você suspeita de estado antigo. Na maioria dos casos, o painel recarrega a configuração necessária, mas um reinício controlado pode ser útil em ambientes Docker.

Atenção: reiniciar o container pode causar uma breve indisponibilidade nos domínios roteados pelo Nginx Proxy Manager. Faça isso em janela adequada e confirme antes se o nome do container está correto.

docker restart nginx-proxy-manager

Output esperado:
nginx-proxy-manager

Depois do reinício, confirme se o container voltou ao estado ativo.

docker ps | grep nginx-proxy-manager

Output esperado:
abc123def456   jc21/nginx-proxy-manager:latest   "/init"   Up

Se o container não voltar, trate isso como falha de inicialização do serviço, não como erro 413. Nesse caso, a prioridade é recuperar o painel e os hosts de proxy antes de repetir o teste de upload. Para uma abordagem geral de serviços que não sobem, veja Como solucionar problemas de inicialização de serviços no VPS Linux: Guia Completo.

Problemas comuns e como resolver

Sintoma: upload ainda retorna 413 depois de salvar o Proxy Host

Causa: o limite foi aplicado no host errado, em outro domínio ou em uma entrada que não recebe a requisição real.

Solução: confirme o domínio acessado no navegador, revise se há variação com www e valide a configuração carregada com nginx -T dentro do container.

Sintoma: logs do Nginx Proxy Manager não mostram 413

Causa: o bloqueio pode estar acontecendo antes do Nginx Proxy Manager, como em uma CDN ou balanceador de carga — o Cloudflare, por exemplo, limita uploads a 100 MB no plano gratuito e retorna 413 antes da requisição chegar ao seu proxy —, ou depois dele, no serviço de backend.

Solução: teste o caminho completo, verifique logs do backend e compare se a resposta 413 aparece no proxy ou apenas na aplicação.

Sintoma: upload pequeno funciona, mas arquivo grande falha

Causa: o limite atual permite requisições menores, mas ainda está abaixo do tamanho do arquivo real enviado pelo usuário.

Solução: defina um valor explícito com client_max_body_size acima do maior upload permitido pelo negócio e replique limite compatível no backend.

Sintoma: após reiniciar, o painel volta mas o erro permanece

Causa: reiniciar não corrige limite mal configurado; ele apenas recarrega o estado do container.

Solução: volte ao diagnóstico, procure client intended to send too large body nos logs e confirme se o backend não está impondo limite menor.

Perguntas frequentes sobre o erro 413 no Nginx Proxy Manager

O que causa o erro 413 Request Entity Too Large no Nginx Proxy Manager?

O erro 413 Request Entity Too Large ocorre quando o arquivo ou corpo da requisição enviado pelo navegador é maior que o limite aceito pelo Nginx Proxy Manager ou pelo serviço de destino. A correção normalmente envolve ajustar o parâmetro client_max_body_size no proxy host e confirmar se a aplicação atrás do proxy também aceita o mesmo tamanho.

Como aumentar o limite de upload no Nginx Proxy Manager?

Para aumentar o limite de upload no Nginx Proxy Manager, edite o Proxy Host afetado e adicione client_max_body_size com o tamanho desejado na seção Advanced. Depois salve a configuração e teste novamente o envio do arquivo pelo domínio que passa pelo proxy reverso.

Preciso reiniciar o container do Nginx Proxy Manager após alterar client_max_body_size?

Na maioria dos casos, salvar o Proxy Host pelo painel já recarrega a configuração necessária para aquele host. Se o erro continuar, reiniciar o container pode ajudar a aplicar a configuração e limpar estados antigos, desde que você tenha conferido antes se não há falha de sintaxe ou limite menor na aplicação de backend.

Por que o erro 413 continua mesmo após ajustar o Nginx Proxy Manager?

O erro pode continuar se o backend também tiver um limite de upload menor, como configurações de PHP, Node.js, WordPress, API ou outro Nginx interno. Também pode haver outro proxy na frente, como CDN ou balanceador, impondo um limite próprio antes da requisição chegar ao Nginx Proxy Manager.

Onde verificar logs do erro 413 no Nginx Proxy Manager?

Os logs podem ser verificados pelo painel do Nginx Proxy Manager na área de logs do proxy host e também diretamente no container Docker. Ao inspecionar os logs, procure mensagens relacionadas a request body, client intended to send too large body ou respostas HTTP 413 para confirmar em qual camada o bloqueio ocorre.

Conclusão

• Corrija o 413 no Nginx Proxy Manager configurando client_max_body_size no Proxy Host exato do domínio afetado.
• Use logs do container e do backend para descobrir se o bloqueio está no proxy, na aplicação ou em outra camada antes dela.
• Verifique também limites impostos por CDNs externas como o Cloudflare, que podem bloquear a requisição antes mesmo de ela chegar ao seu proxy.
• Após qualquer ajuste de configuração, teste uploads reais e documente o limite adotado para evitar regressões em novos hosts.

Leia também

• Checklist: como hospedar múltiplos sites com Docker e Nginx
• Guia para Configurar Limite de Taxa (Rate Limiting) no Nginx em VPS Linux e Servidor Dedicado
• Solucionar erro de permissão no /var/www/html no Debian 12

Precisa de ajuda com erro 413 no Nginx Proxy Manager?

Se o seu proxy reverso roda em Docker e precisa de ajuste seguro para uploads maiores, um VPS bem dimensionado facilita logs, reinícios controlados e manutenção do Nginx Proxy Manager sem depender de gambiarras.

Conheça os planos de Servidor VPS da AviraHost