Guide
A Referência completa de códigos HTTP reúne 72 códigos de status: todos os códigos padrão definidos na RFC 9110 (100–101, 200–206, 300–308, 400–418, 421, 422, 426, 500–505), os códigos de extensão das RFCs 6585 / 7725 / 8297 / 8470 e da série WebDAV (103, 207, 208, 226, 423–425, 428, 429, 431, 451, 506–511) e os códigos não padrão que não estão em RFC nenhuma, mas aparecem todo dia quando você investiga problemas em produção — 444 e 499 do nginx, 520–526 do Cloudflare.
Atualizado em 2026-09-094 sources9 min read
A Referência completa de códigos HTTP reúne 72 códigos de status: todos os códigos padrão definidos na RFC 9110 (100–101, 200–206, 300–308, 400–418, 421, 422, 426, 500–505), os códigos de extensão das RFCs 6585 / 7725 / 8297 / 8470 e da série WebDAV (103, 207, 208, 226, 423–425, 428, 429, 431, 451, 506–511) e os códigos não padrão que não estão em RFC nenhuma, mas aparecem todo dia quando você investiga problemas em produção — 444 e 499 do nginx, 520–526 do Cloudflare.
Diferente das tabelas que trazem apenas o “significado”, aqui cada código é escrito em quatro partes: qual é a semântica; em que situação você vai vê-lo; o que o front-end / cliente deve fazer ao recebê-lo (tentar de novo? ir para o login? ler qual cabeçalho de resposta?); e quando o back-end deve devolvê-lo e com quais cabeçalhos. Os códigos mais frequentes ganham ainda uma quinta parte, “erros comuns”, porque a maioria dos problemas de status em produção não vem de não conhecer o código, e sim de usar o errado — devolver 200 para falha de negócio, 403 para usuário não autenticado, 503 para limite de requisições.
No topo da página há ainda sete grupos de “comparações que confundem”: 401 vs 403, 301/302/307/308, 400 vs 422, 404 vs 410, 502/503/504, 200/201/202/204 e 429 vs 503. São as combinações mais pedidas em entrevistas, revisões de código e depuração.
502) na busca e o cartão que corresponde exatamente aparece fixado no topo.Buscando “429”, o cartão mostra (trecho):
A resposta do back-end correspondente é assim:
429 Too Many Requests Requisições demais RFC 6585
Semântica Requisições demais em um intervalo de tempo (limite de requisições).
Quando Limite de frequência de API, tentativas de login em excesso, crawler limitado, API de IA acima da cota por minuto.
Cliente Ler o cabeçalho Retry-After (segundos ou data) e tentar de novo com backoff exponencial; avisar o usuário para “tentar mais tarde”; não repetir na hora.
Servidor Enviar os cabeçalhos Retry-After e RateLimit-*; contar por usuário / IP / API key.
Erro comum Limite de requisições devolve 403 ou 503 e o cliente não consegue distinguir problema de permissão de “espere um pouco”.HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Retry-After: 30
RateLimit-Limit: 60
RateLimit-Remaining: 0
RateLimit-Reset: 30
{"error":"rate_limited","message":"no máximo 60 requisições por minuto; tente de novo em 30 segundos"}O primeiro dígito do status define a classe, e isso é proposital: mesmo sem conhecer um código específico (um 425 novo, por exemplo), o cliente consegue tratá-lo pela classe — todo 4xx significa “não repita do mesmo jeito, o problema está na requisição”, todo 5xx “pode tentar mais tarde”, todo 3xx “olhe o Location”. A RFC 9110 exige explicitamente que o cliente entenda a semântica da classe e permite que ele não entenda o código individual. É também por isso que um status personalizado precisa cair na centena correta.
Um erro histórico de nomenclatura. O HTTP antigo não separava authentication (quem você é) de authorization (o que você pode fazer); o 401 foi batizado de Unauthorized, mas o cabeçalho WWW-Authenticate que o acompanha e a semântica de “pode dar certo se você enviar as credenciais de novo” falam de autenticação. A RFC 9110, na §15.5.2, passou a escrever "lacks valid authentication credentials". Guarde uma frase: 401 = faça login, 403 = mesmo logado não pode. O front-end usa isso para decidir entre redirecionar ao login e mostrar “sem permissão”; invertido, o usuário logado é jogado de volta à tela de login o tempo todo.
Os quatro códigos de redirecionamento comuns formam uma matriz 2×2. 301 e 308 são permanentes (navegador e mecanismos de busca memorizam o novo endereço), 302 e 307 são temporários. Historicamente, ao tratar 301/302 o navegador transformava POST em GET; a RFC 9110 reconhece essa realidade e oferece 307/308 como as versões estritas, que “precisam manter o método e o corpo da requisição”. Para redirecionar um site para https, o 301 serve; ao migrar um endpoint de API, um POST precisa de 307/308, senão o corpo da requisição se perde.
O 304 costuma ser entendido como “economizou uma requisição”. Na prática o navegador continua enviando uma requisição condicional com If-None-Match / If-Modified-Since, o servidor compara e responde 304 sem corpo — o que se economiza é a transferência, não a ida e volta. Economizar requisições de verdade é papel do Cache-Control: max-age (dentro da validade o navegador nem pergunta ao servidor); os dois trabalham juntos: durante o max-age usa-se a resposta direto e, depois de expirar, uma requisição condicional renova com 304. No DevTools, "200 (from disk cache)" é o primeiro caso e "304" o segundo.
A família 5xx mais comum em produção; distingui-los já reduz o campo de investigação. O proxy reverso (Nginx, gateway, CDN) não consegue conectar ao upstream, ou o upstream devolveu algo inválido — 502, então vá ver se o processo da aplicação caiu. O upstream avisa explicitamente que está ocupado ou em manutenção — 503, normalmente devolvido de propósito, então olhe health checks e circuit breakers. O upstream não responde — 504, então olhe consultas lentas e configuração de timeout. O Cloudflare desdobra esses três casos em 520–526, sendo 521 ≈ 502 (conexão recusada), 522/524 ≈ 504 (timeout de conexão / leitura) e 525/526 problemas na camada TLS.
O antipadrão mais comum é devolver 200 em toda requisição e colocar o erro num campo code do corpo. Isso faz o CDN cachear páginas de erro, derruba os alertas de 5xx do monitoramento, esvazia o significado de fetch().ok no navegador e deixa qualquer estratégia de retry sem base. O certo é dividir: o status HTTP expressa o que aconteceu na camada da requisição (a semântica da RFC 9110) e o código de negócio do corpo expressa o detalhe do domínio — os dois se complementam em vez de se substituírem: estoque esgotado é 422 + {"code":"OUT_OF_STOCK"}, não 200 + {"code":500}.
A comparação 502 / 503 / 504 mostra se a aplicação caiu, se saiu do balanceamento ou se está lenta demais; os cartões 52x do Cloudflare apontam direto para “verifique firewall da origem / certificado / timeout”.
Escreva seus interceptors com a coluna “front-end / cliente”: 401 renova o token ou vai para o login, 403 mostra “sem permissão”, 429 lê o Retry-After e faz backoff, 5xx tenta um número limitado de vezes e reporta.
A criação de recurso devolve 201 + Location? A exclusão devolve 204? Falha de validação de negócio é 400 ou 422? O limite de requisições vem com Retry-After? As colunas “back-end” e “erros comuns” são a sua checklist de revisão.
Os sete grupos de comparação cobrem as perguntas de “qual é a diferença” mais comuns; a seção de princípios explica o nome do 401, por que 307/308 existem e o que o 304 realmente faz.
O servidor de entrada do site (o gateway) não consegue conectar ao back-end que de fato trata a requisição, geralmente porque o processo do back-end caiu ou está reiniciando. Do lado do usuário, só resta atualizar mais tarde; se o site for seu, olhe o processo do back-end e o log de erros do gateway.
Cliente: leia o cabeçalho Retry-After, espere o tempo indicado antes de tentar de novo, faça backoff exponencial em falhas repetidas (1s, 2s, 4s…) e avise o usuário de que “as tentativas são muitas”. Servidor: ao devolver 429, sempre envie Retry-After, de preferência com os cabeçalhos RateLimit-*, para o cliente poder desacelerar antes.
Depende do objeto pedido. GET /users/123 com 123 inexistente — 404; GET /users?name=xxx com resultado vazio — 200 + array vazio. Um resultado vazio numa listagem é um “encontrei, e o resultado é vazio” legítimo, não um erro.
O 204 não tem corpo de resposta, e json() lança SyntaxError ao interpretar uma string vazia. Verifique primeiro response.status === 204 (ou response.headers.get('content-length') === '0') antes de decidir se vai interpretar.
São códigos internos que o nginx grava no log de acesso: 444 quer dizer que o nginx fechou a conexão sem devolver resposta alguma, e 499 que o cliente desconectou antes de o nginx responder. No navegador você vê “conexão reiniciada” ou nenhuma resposta.
Os dados de status são baixados estaticamente com a página, e busca, filtro, cópia e favoritos acontecem no seu navegador, sem nenhuma requisição. Os favoritos ficam no localStorage deste aparelho. Os links externos apontam para o RFC Editor, a IANA e a documentação do Cloudflare, e passam a ser responsabilidade desses sites depois do clique.
Atualizado em 2026-09-09
72 códigos HTTP da RFC 9110, extensões e códigos não padrão de nginx/Cloudflare, com semântica, cenários, tratamento no frontend e backend e erros comuns; 7 comparações de códigos fáceis de confundir; busca, cópia e favoritos
Esta ferramenta ainda não está totalmente traduzida; parte do conteúdo usa o idioma de origem ou um idioma de reserva.
A solicitação foi recebida e o processamento continua; os navegadores quase nunca expõem esses códigos aos scripts da página.
Os cabeçalhos da solicitação foram recebidos; o cliente pode continuar enviando o corpo.
RFC 9110 §15.2.1
O servidor concorda em trocar de protocolo pelo cabeçalho Upgrade.
RFC 9110 §15.2.2
O servidor recebeu a solicitação e está processando, mas ainda não há resposta final.
RFC 2518 (WebDAV, obsoleto)
Alguns cabeçalhos são enviados antes da resposta final — principalmente Link: preload — para o navegador carregar recursos mais cedo.
RFC 8297
A solicitação foi recebida, compreendida e processada com sucesso.
A solicitação foi bem-sucedida; o corpo contém o recurso pedido ou o resultado da operação.
RFC 9110 §15.3.1
A solicitação foi bem-sucedida e um novo recurso foi criado.
RFC 9110 §15.3.2
A solicitação foi aceita, mas ainda não processada — o recibo de uma tarefa assíncrona.
RFC 9110 §15.3.3
A resposta foi bem-sucedida, mas o conteúdo foi modificado por um proxy intermediário.
RFC 9110 §15.3.4
Sucesso, mas sem corpo de resposta.
RFC 9110 §15.3.5
Sucesso, e o cliente deve redefinir a visão do documento (por exemplo, limpar um formulário).
RFC 9110 §15.3.6
Apenas parte do recurso é retornada (solicitação Range bem-sucedida).
RFC 9110 §15.3.7
O corpo é XML e cada sub-recurso informa o próprio status.
RFC 4918 (WebDAV)
Dentro de uma resposta 207, o mesmo recurso já foi reportado antes e não se repete.
RFC 5842 (WebDAV)
O servidor aplicou manipulações de instância (codificação delta) à instância atual e retornou a diferença.
RFC 3229
O cliente precisa executar uma ação adicional — geralmente solicitar outro endereço — antes que a solicitação seja concluída.
O recurso tem várias representações; o cliente deve escolher uma.
RFC 9110 §15.4.1
O recurso mudou de forma permanente para a nova URL em Location; usar essa URL daqui em diante.
RFC 9110 §15.4.2
O recurso está temporariamente em outro lugar; na próxima vez, pedir a URL original.
RFC 9110 §15.4.3
Obter o resultado em Location com GET, independentemente do método desta solicitação.
RFC 9110 §15.4.4
O recurso não mudou — usar a cópia do cache.
RFC 9110 §15.4.5
O recurso só pode ser acessado pelo proxy indicado em Location.
RFC 9110 §15.4.6 (obsoleto)
Em um rascunho significava trocar de proxy; o código está reservado e sem uso.
RFC 9110 §15.4.7
Redirecionamento temporário, e o cliente deve reenviar com o mesmo método e corpo.
RFC 9110 §15.4.8
Redirecionamento permanente que também preserva método e corpo (a versão estrita do 301).
RFC 9110 §15.4.9
A própria solicitação tem um problema: sintaxe, autenticação, recurso inexistente ou frequência excessiva… repetir a mesma solicitação não vai funcionar.
O servidor não entende a solicitação: sintaxe errada, parâmetros ausentes ou malformados, ou JSON que não dá para analisar.
RFC 9110 §15.5.1
Credenciais ausentes ou inválidas — «quem é você?» (o nome Unauthorized na verdade significa não autenticado).
RFC 9110 §15.5.2
Reservado para pagamentos digitais futuros; a especificação não define semântica concreta.
RFC 9110 §15.5.3 (reservado)
O servidor sabe quem você é, mas falta permissão — «você não pode». Reautenticar não adianta.
RFC 9110 §15.5.4
O servidor não encontra o recurso pedido e não diz se é temporário ou permanente.
RFC 9110 §15.5.5
O recurso existe, mas não aceita este método HTTP.
RFC 9110 §15.5.6
O servidor não tem representação que atenda a Accept / Accept-Language.
RFC 9110 §15.5.7
É preciso primeiro autenticar no servidor proxy (a versão proxy do 401).
RFC 9110 §15.5.8
O servidor esperou demais pela solicitação (o cliente nunca terminou de enviá-la).
RFC 9110 §15.5.9
A solicitação está em conflito com o estado atual do recurso; o usuário pode resolver mudando a solicitação.
RFC 9110 §15.5.10
O recurso existiu e agora foi removido permanentemente, sem endereço de encaminhamento.
RFC 9110 §15.5.11
O servidor exige que a solicitação traga Content-Length.
RFC 9110 §15.5.12
Uma condição nos cabeçalhos (If-Match, If-Unmodified-Since) não foi atendida.
RFC 9110 §15.5.13
O corpo da solicitação passa do tamanho permitido pelo servidor.
RFC 9110 §15.5.14 (antes Payload Too Large)
A URL é longa demais para o servidor processar.
RFC 9110 §15.5.15
O servidor não suporta o formato (Content-Type) do corpo da solicitação.
RFC 9110 §15.5.16
A faixa de bytes pedida no cabeçalho Range passa do tamanho do recurso.
RFC 9110 §15.5.17
O servidor não consegue atender ao cabeçalho Expect.
RFC 9110 §15.5.18
Piada de um RFC de 1º de abril de 1998; não deve ser usado em HTTP real.
RFC 2324 (RFC de 1º de abril); marcado como não usado pela RFC 9110
A solicitação chegou a um servidor que não consegue responder por essa autoridade (domínio).
RFC 9110 §15.5.20
A sintaxe e o formato estão corretos, mas não dá para processar semanticamente (falha de validação de negócio).
RFC 9110 §15.5.21 (antes Unprocessable Entity)
O recurso está bloqueado.
RFC 4918 (WebDAV)
Esta operação falhou porque uma operação dependente falhou antes.
RFC 4918 (WebDAV)
O servidor não quer processar uma solicitação que pode ser repetida (dados antecipados do TLS 1.3 0-RTT).
RFC 8470
O servidor recusa processar no protocolo atual e pede a troca para o indicado em Upgrade.
RFC 9110 §15.5.22
O servidor exige um cabeçalho condicional (como If-Match) para evitar atualizações perdidas.
RFC 6585
Muitas solicitações foram enviadas em uma janela de tempo (limitação de taxa).
RFC 6585
Um cabeçalho da solicitação (um campo ou o total) é grande demais.
RFC 6585
O recurso é retido por motivos legais (direitos autorais, ordens governamentais). O número homenageia o romance Fahrenheit 451.
RFC 7725
O servidor sabe que falhou ou que não consegue atender a uma solicitação válida; tentar de novo mais tarde pode funcionar.
O servidor encontrou uma condição inesperada e não conseguiu concluir a solicitação.
RFC 9110 §15.6.1
O servidor não suporta a funcionalidade necessária para concluir a solicitação (normalmente um método desconhecido).
RFC 9110 §15.6.2
Um servidor atuando como gateway ou proxy recebeu uma resposta inválida do upstream.
RFC 9110 §15.6.3
O servidor não consegue atender a solicitação temporariamente (sobrecarga ou manutenção), normalmente só por um tempo.
RFC 9110 §15.6.4
O gateway/proxy esgotou o tempo esperando resposta do upstream.
RFC 9110 §15.6.5
O servidor não suporta a versão principal de HTTP usada pela solicitação.
RFC 9110 §15.6.6
Uma configuração errada de negociação de conteúdo cria um loop.
RFC 2295
O servidor não consegue armazenar o conteúdo necessário para a solicitação.
RFC 4918 (WebDAV)
Um loop infinito foi detectado ao processar a solicitação.
RFC 5842 (WebDAV)
A solicitação precisa ser mais estendida antes que o servidor consiga processá-la.
RFC 2774 (histórico)
O cliente precisa se autenticar no nível de rede (portal cativo) antes de navegar.
RFC 6585
Não estão em nenhuma RFC e aparecem apenas em logs de servidores específicos ou em páginas de erro de CDN; conhecê-los economiza muito tempo de diagnóstico.
O nginx fecha a conexão sem enviar resposta; aparece só nos logs do nginx.
específico do nginx
O cliente desconectou antes de o servidor responder; aparece só nos logs do nginx.
específico do nginx
A resposta da origem para a Cloudflare estava vazia, malformada ou com cabeçalhos grandes demais.
específico da Cloudflare
A Cloudflare não consegue alcançar a origem (conexão TCP recusada).
específico da Cloudflare
A conexão TCP da Cloudflare com a origem esgotou o tempo.
específico da Cloudflare
A Cloudflare não consegue rotear até a origem (problema de DNS ou de roteamento de rede).
específico da Cloudflare
O TCP conectou, mas a origem não retornou resposta HTTP em 100 segundos.
específico da Cloudflare
O handshake TLS entre a Cloudflare e a origem falhou.
específico da Cloudflare
No modo Full (strict), o certificado da origem está expirado, é autoassinado ou não corresponde ao domínio.
específico da Cloudflare