Erro 413 Content Too Large

A RFC 9110, seção 15.5.14, renomeou o código para Content Too Large; a RFC 7231 chamava de Payload Too Large e a RFC 2616 de Request Entity Too Large, que é o texto que o nginx ainda mostra. O servidor pode fechar a conexão assim que percebe o tamanho, e se o limite for temporário deve incluir Retry-After.

O difícil é descobrir qual camada recusou, porque cada uma tem seu teto. A Cloudflare aceita corpos de até 100 MB nos planos Free e Pro e 200 MB no Business. As Vercel Functions param em 4,5 MB com FUNCTION_PAYLOAD_TOO_LARGE. O nginx vem com 1 MB, o express.json() com 100 KB, as Server Actions do Next.js com 1 MB e o PHP com upload_max_filesize = 2M e post_max_size = 8M. O filtro de requisições do IIS permite cerca de 28,6 MB. Vale sempre o menor limite do caminho.

Um jeito rápido de saber quem recusou é olhar o corpo da resposta. O nginx devolve uma página HTML com o título 413 Request Entity Too Large, o Express devolve o que o seu tratador de erros gerar, e Cloudflare e Vercel mostram páginas com a própria marca. Muitas vezes o navegador nem consegue exibir a resposta, porque o servidor fecha a conexão enquanto o upload ainda está sendo enviado.

Se você está visitando o site

• O arquivo enviado (foto, vídeo, PDF) é maior do que o site aceita.
• Um formulário com vários anexos soma mais que o limite, mesmo que cada arquivo seja pequeno.

Se você administra o servidor

• O nginx na frente da aplicação continua com o padrão client_max_body_size 1m.
• O limite do parser da aplicação é menor que os uploads esperados, como o express.json() com o padrão de 100 KB recebendo imagens em base64.
• A plataforma limita o corpo: 4,5 MB nas Vercel Functions, 100 MB na Cloudflare Free, 1 MB nas Server Actions do Next.js.
• No PHP, post_max_size ou upload_max_filesize está baixo. O PHP em geral nem manda 413; ele descarta os dados do POST, e o 413 vem do servidor web na frente.

Se você está visitando o site

• Comprima ou reduza o arquivo (exporte a imagem em resolução menor, compacte os documentos) e tente de novo.
• Envie os anexos um por vez se o formulário permitir, ou use um link de compartilhamento em vez de anexar um vídeo grande.

Se você administra o servidor

• Aumente o client_max_body_size no bloco server ou location certo do nginx e recarregue (nginx -s reload). Configure por location, para só a rota de upload aceitar corpos grandes.
• Aumente o limite do parser onde precisa: express.json({ limit: "5mb" }), serverActions.bodySizeLimit no next.config, post_max_size e upload_max_filesize no php.ini.
• Para arquivos maiores que a plataforma aceita, faça o upload direto do navegador para o storage com URL pré-assinada (S3, R2, GCS) e mande só a chave para a sua API.
• Verifique cada camada em ordem (CDN, balanceador, nginx, aplicação) e aumente o menor limite; mudar só a aplicação não resolve se o nginx recusa antes.

O Content-Length pode faltar ou estar errado em uploads em chunks, então checar o cabeçalho é só um atalho; o MaxBytesReader do Go e os limites do parser do Express contam os bytes realmente lidos. Nas Server Actions do Next.js, aumente serverActions.bodySizeLimit no next.config.

// express.json() and express.raw() answer 413 on their own;
// err.type is 'entity.too.large'
app.use(express.json({ limit: '5mb' }));

app.use((err, req, res, next) => {
  if (err.type === 'entity.too.large') {
    return res.status(413).json({ error: 'Body exceeds 5 MB' });
  }
  next(err);
});

// app/uploads/route.ts
const MAX = 5 * 1024 * 1024;

export async function POST(request: Request) {
  const length = Number(request.headers.get('content-length') ?? 0);
  if (length > MAX) {
    return Response.json({ error: 'Body exceeds 5 MB' }, { status: 413 });
  }
  // ...
}

mux.HandleFunc("POST /uploads", func(w http.ResponseWriter, r *http.Request) {
	r.Body = http.MaxBytesReader(w, r.Body, 5<<20) // 5 MB
	data, err := io.ReadAll(r.Body)
	var tooBig *http.MaxBytesError
	if errors.As(err, &tooBig) {
		http.Error(w, "body exceeds 5 MB", http.StatusRequestEntityTooLarge) // 413
		return
	}
	_ = data // ...
})

from fastapi import FastAPI, HTTPException, Request

app = FastAPI()
MAX = 5 * 1024 * 1024

@app.post("/uploads")
async def upload(request: Request):
    if int(request.headers.get("content-length", 0)) > MAX:
        raise HTTPException(status_code=413, detail="Body exceeds 5 MB")
    ...

# Too-large bodies get 413. Default is 1m; 0 disables the check
server {
  client_max_body_size 2m;

  location /uploads/ {
    client_max_body_size 50m;
    proxy_pass http://app;
  }
}

413 vs 414

O 414 trata de URL comprida demais; o 413 trata de corpo grande demais.

413 vs 431

O 431 indica cabeçalhos grandes demais (muitas vezes cookies), mesmo com corpo pequeno.

413 vs 507

O 507 indica que o servidor ficou sem espaço para gravar o upload; o 413 indica que ele não aceita um envio daquele tamanho.

Como resolver o erro 413 Request Entity Too Large no nginx?

Adicione client_max_body_size 50m; (ou o tamanho necessário) no bloco http, server ou location que recebe os uploads, rode nginx -t e depois nginx -s reload. O padrão é 1m, e 0 desativa a verificação.

413 Payload Too Large é o mesmo que 413 Request Entity Too Large?

Sim. É o mesmo código com três nomes ao longo do tempo: Request Entity Too Large (RFC 2616), Payload Too Large (RFC 7231) e Content Too Large (RFC 9110, o atual).

Por que continuo recebendo 413 depois de aumentar o limite?

Outra camada tem limite menor. Confira a CDN (a Cloudflare Free aceita 100 MB), a hospedagem (as Vercel Functions aceitam 4,5 MB), o proxy reverso e o parser da aplicação, e confirme que o nginx realmente recarregou a configuração nova.

Qual o limite padrão de upload no Next.js?

As Server Actions recusam corpos acima de 1 MB, a menos que você aumente serverActions.bodySizeLimit no next.config. Os route handlers não têm limite próprio do framework, mas a hospedagem pode impor um, como o teto de 4,5 MB das Vercel Functions.