Consulta de Códigos de Status HTTP
Referência rápida de códigos de status HTTP com descrições
1xx Informação(4)
Cliente deve continuar enviando o restante da requisição.
Servidor entende e mudará para um protocolo diferente.
Servidor recebeu a requisição e está processando.
Retorna alguns headers antes da resposta final para preloading.
2xx Sucesso(10)
Requisição bem sucedida. Resposta contém os dados solicitados.
Requisição bem sucedida e um novo recurso foi criado. Comum para POST.
Requisição aceita para processamento, mas ainda não completada.
Requisição bem sucedida, mas informação pode ser de terceiros.
Requisição bem sucedida, mas sem conteúdo na resposta. Comum para DELETE.
Requisição bem sucedida, cliente deve resetar a visualização do documento.
Servidor entregou conteúdo parcial. Usado para resuming downloads.
Múltiplos códigos de status na resposta (WebDAV).
DAV bindings já listados em resposta anterior (WebDAV).
Servidor completou requisição GET usando instance manipulation.
3xx Redirecionamento(8)
Múltiplas representações disponíveis, cliente deve escolher uma.
Recurso permanentemente movido para nova URL. Use nova URL.
Recurso temporariamente em outra URL.
Use GET para recuperar recurso de outra URL.
Recurso não modificado. Use versão em cache.
Use proxy especificado (deprecated).
Redirecionamento temporário com mesmo método e body.
Redirecionamento permanente com mesmo método.
4xx Erro Cliente(29)
Servidor não consegue entender formato da requisição.
Autenticação requerida.
Reservado para uso futuro. Comum para conteúdo bloqueado.
Servidor entendeu mas recusa autorizar.
Recurso não existe. Código de status mais comum.
Método de requisição não suportado.
Não pode retornar conteúdo correspondente ao Accept header.
Cliente deve autenticar com proxy primeiro.
Servidor timed out esperando pela requisição.
Requisição conflita com estado do servidor. Comum para PUT.
Recurso permanentemente removido.
Requisição deve incluir header Content-Length.
Condições nos headers da requisição não atendidas.
Body da requisição muito grande.
URL da requisição muito longa.
Formato do body da requisição não suportado.
Range solicitado inválido.
Requisitos do header Expect não atendidos.
Easter egg RFC 2324. Servidor recusa fazer café.
Requisição enviada para servidor errado.
Requisição bem formada mas com erros semânticos.
Recurso bloqueado (WebDAV).
Requisição falhou devido a falha anterior (WebDAV).
Servidor não quer processar requisição potencialmente replayed.
Cliente deve mudar para TLS.
Requisição requer headers condicionais.
Limite de taxa excedido. Desacelere.
Headers da requisição muito grandes.
Recurso indisponível por razões legais.
5xx Erro Servidor(11)
Servidor encontrou condição inesperada.
Servidor não suporta funcionalidade requerida.
Servidor recebeu resposta inválida do upstream.
Servidor temporariamente incapaz de lidar com requisição.
Servidor timed out esperando resposta do upstream.
Versão HTTP não suportada.
Erro de configuração de content negotiation.
Servidor não pode armazenar recurso (WebDAV).
Loop infinito detectado (WebDAV).
Extensões adicionais requeridas.
Autenticação de rede requerida.
O que são Códigos de Status HTTP?
A ferramenta de códigos de status HTTP explica as respostas que um servidor devolve a um navegador, rastreador, aplicativo ou cliente de API depois de uma requisição. Códigos 2xx geralmente indicam sucesso, 3xx redirecionamento, 4xx problemas do cliente e 5xx falhas do servidor, mas os detalhes fazem diferença. Um 401 não é igual a um 403, um 404 não tem o mesmo significado que um 410, e um 301 afeta SEO de forma diferente de um 302. A referência ajuda desenvolvedores, suporte e responsáveis por sites a interpretar códigos e escolher a próxima verificação. Ao usar com outras pessoas, entradas, premissas e resultado esperado devem estar claros para evitar interpretações erradas.
Como Usar
Referência Rápida
- Clique em qualquer cartão de código de status para copiá-lo
- Use a caixa de busca para encontrar códigos específicos rapidamente
- Clique nas tags de categoria para filtrar por tipo de status
- Passe o mouse sobre os códigos para ver descrições detalhadas
Dicas de Depuração
- Primeiro, identifique a família do status: 2xx indica sucesso, 3xx indica redirecionamento, 4xx indica problema do lado do cliente e 5xx indica problema do lado do servidor.
- Ao depurar APIs, combine o código de status com o corpo da resposta, os cabeçalhos, o método da requisição e os logs do servidor; o código sozinho raramente explica o problema completo.
Casos de uso
Princípio técnico
Os códigos de status HTTP são inteiros de 3 dígitos retornados na linha de início da resposta, definidos pela especificação de semântica HTTP. A referência normativa atual é o RFC 9110 (HTTP Semantics, junho de 2022), que obsoleta a série anterior RFC 7231, com extensões no RFC 9111 (Caching), RFC 9112 (HTTP/1.1), RFC 9113 (HTTP/2) e RFC 9114 (HTTP/3). O primeiro dígito define a classe da resposta, de modo que códigos não reconhecidos ainda têm tratamento previsível: 1xx informativo (interim, a resposta final segue), 2xx sucesso, 3xx redirecionamento (ação adicional pelo user agent é necessária), 4xx erro do cliente (a requisição está malformada ou não pode ser atendida) e 5xx erro do servidor. Caches e intermediários devem tratar códigos desconhecidos como o código genérico da classe x00 (por exemplo, um 4xx desconhecido é tratado como 400), o que torna a família de status significativa mesmo para códigos proprietários ou de extensão. Os códigos de redirecionamento carregam semântica de preservação de método que historicamente divergiu da intenção. O RFC 9110 §15.4 torna a distinção explícita: 301 Moved Permanently e 302 Found podem reescrever um POST para GET (o comportamento de fato que todos os navegadores adotaram no final dos anos 1990, codificado no RFC 7231); 307 Temporary Redirect e 308 Permanent Redirect exigem que o user agent repita o mesmo método e body. Ferramentas de SEO tipicamente transferem peso equivalente ao PageRank em 301 e 308 e tratam 302/307 como preservadores do sinal da URL original. Os códigos condicionais 304 Not Modified e 412 Precondition Failed dependem dos headers If-None-Match / If-Modified-Since / ETag / Last-Modified da requisição, e 206 Partial Content responde a um header Range com um header Content-Range e um body multipart/byteranges quando múltiplos intervalos são solicitados. As classes 4xx e 5xx carregam detalhes de contrato nos headers. 401 Unauthorized deve incluir um desafio WWW-Authenticate listando os esquemas aceitos (Bearer, Basic, Digest, Negotiate); sem ele, a resposta é tecnicamente malformada. 405 Method Not Allowed deve incluir um header Allow listando os métodos suportados. 429 Too Many Requests, 503 Service Unavailable e 301/307/308 com Retry-After permitem que o servidor sinalize um atraso em segundos (Retry-After: 120) ou como HTTP-date (Retry-After: Wed, 21 Oct 2025 07:28:00 GMT) conforme RFC 9110 §10.2.3. O RFC 9110 descontinua 305 Use Proxy e 306 (reservado/não utilizado), mantém 418 I'm a teapot como o código de piada documentado no RFC 2324 / RFC 7168, e reorganiza os 1xx para que apenas 100 Continue e 101 Switching Protocols sejam obrigatórios na camada HTTP/1.1; 102 Processing e 103 Early Hints (RFC 8297) são extensões opcionais expostas principalmente através da lógica de borda de CDN.
- Referência normativa: RFC 9110 (HTTP Semantics, junho de 2022) obsoleta RFC 7230-7235; extensões estão no RFC 9111 (Caching), 9112 (formato HTTP/1.1), 9113 (HTTP/2), 9114 (HTTP/3).
- Códigos desconhecidos degradam para o código da classe (x00): um 4xx desconhecido é cacheado e renderizado como 400, um 5xx desconhecido como 500 - é isso que torna o primeiro dígito um contrato.
- Preservação de método: 301/302 historicamente permitem reescrita POST → GET (codificada após divergência dos navegadores do início dos anos 1990); 307/308 exigem que o mesmo método e body sejam repetidos - use 308 para mudanças permanentes de endpoints de API.
- 401 Unauthorized deve carregar WWW-Authenticate; 405 Method Not Allowed deve carregar Allow; a ausência desses headers é uma violação da especificação que quebra clientes HTTP bem comportados.
- Retry-After (RFC 9110 §10.2.3) em 429/503/301/307/308: aceita delta-seconds (Retry-After: 120) ou HTTP-date (Retry-After: Wed, 21 Oct 2025 07:28:00 GMT) - clientes devem analisar ambas as formas.
- Cache condicional: 304 Not Modified responde a correspondências de If-None-Match / If-Modified-Since sem body; 206 Partial Content responde a Range com Content-Range e o body parcial ou um documento multipart/byteranges.
- O RFC 9110 descontinua 305 Use Proxy e 306 (reservado), preserva 418 I'm a teapot do RFC 2324 / RFC 7168 como piada, e trata 102 Processing / 103 Early Hints (RFC 8297) como extensões 1xx opcionais que muitos proxies removem.
Exemplos
2xx Sucesso - 200 OK e 204 No Content
200 OK GET /api/users -> corpo de resposta retornado
201 Created POST /api/posts -> novo recurso no header Location
204 No Content DELETE /api/posts/42 -> sucesso, corpo vazio
206 Partial Requisição Range para streaming de vídeo ou downloads retomáveis
RFC: RFC 7231 seção 6.3 define os códigos de status de sucesso 2xx3xx Redirecionamentos - 301 vs 302 vs 304
301 Moved Permanently -> seguro para SEO, navegadores cacheiam a nova URL para sempre
302 Found -> redirecionamento temporário, não cachear o destino
304 Not Modified -> cópia em cache ainda é válida (ETag/Last-Modified coincidem)
307 Temporary Redirect -> como 302, mas o método NÃO deve mudar (POST permanece POST)
308 Permanent Redirect -> como 301, mas preserva o método da requisição
RFC: RFC 7231 seção 6.4 define os códigos de redirecionamento 3xx
RFC: RFC 7232 seção 4.1 define a semântica de 304 Not Modified4xx Erros do cliente - autenticação vs permissão
400 Bad Request JSON malformado, campo obrigatório ausente
401 Unauthorized Token ausente ou inválido - o chamador precisa autenticar
403 Forbidden Autenticado, mas sem permissão para acessar este recurso
404 Not Found Recurso não existe (ou finja que não, por segurança)
409 Conflict Chave duplicada, divergência de versão em lock otimista
429 Too Many Reqs Limite de taxa atingido - veja o header Retry-After
RFC: RFC 7231 seção 6.5 define os códigos de erro 4xx do cliente
RFC: RFC 6585 seção 4 define 429 Too Many Requests5xx Erros do servidor - depurando um upstream
500 Internal Server Error Exceção não tratada no código da aplicação - veja os logs
502 Bad Gateway Nginx/upstream recebeu uma resposta inválida do backend
503 Service Unavailable Manutenção, sobrecarga ou aplicação subindo
504 Gateway Timeout Upstream não respondeu dentro do timeout do proxy
RFC: RFC 7231 seção 6.6 define os códigos de erro 5xx do servidor
Triagem rápida: 5xx = nossa culpa, 4xx = culpa do chamadorSessão real do curl mostrando vários códigos
$ curl -I https://example.com/old-page
HTTP/2 301
location: https://example.com/new-page
$ curl -I https://example.com/admin
HTTP/2 401
www-authenticate: Bearer realm="api"
$ curl -X POST https://example.com/api/posts -d '{}'
HTTP/2 422
content-type: application/json
Nota: 422 Unprocessable Entity é uma extensão do WebDAV (RFC 4918) usada para erros de validaçãoPerguntas frequentes
O que significam as classes 1xx, 2xx, 3xx, 4xx e 5xx?
1xx é informativo (raro na prática). 2xx significa que a requisição foi bem-sucedida. 3xx é redirecionamento — o cliente deve seguir uma URL diferente. 4xx é problema do lado do cliente (requisição inválida, falta de autenticação, recurso ausente). 5xx é problema do lado do servidor (a requisição parecia certa, mas o servidor não conseguiu atender). Sempre confira a classe primeiro ao ler uma linha de log.
Qual a diferença entre 301 e 302?
301 Moved Permanently informa a clientes e mecanismos de busca que o recurso se moveu permanentemente — os navegadores cacheiam o redirecionamento de forma agressiva e o link equity de SEO é transferido para a nova URL. 302 Found é um redirecionamento temporário; os clientes não devem cacheá-lo por muito tempo. Use 308 para redirecionamentos permanentes quando precisar preservar o método da requisição, e 307 para redirecionamentos temporários sob a mesma restrição.
Quando devo retornar 401 vs 403?
401 Unauthorized significa que o cliente não se autenticou ou que as credenciais que ele enviou são inválidas — a resposta deveria incluir um cabeçalho WWW-Authenticate. 403 Forbidden significa que o servidor entendeu quem é o cliente e está se recusando a servir esse recurso de qualquer jeito. Fazer login resolve 401; fazer login não resolve 403.
Devo usar 404 ou 410 para recursos que não existem mais?
404 Not Found quer dizer 'não consigo encontrar isso; pode existir em algum lugar ou voltar mais tarde'. 410 Gone quer dizer 'esse recurso esteve aqui, foi removido propositalmente, não procure mais'. Os mecanismos de busca tiram URLs com 410 do índice mais rápido do que 404, então 410 é a escolha certa para páginas aposentadas que você não quer que sejam recrawladas.
Como devo ler um código de status ao depurar uma API?
Leia primeiro a classe (4xx vs 5xx te diz de que lado olhar), depois o código específico, depois o corpo da resposta. O corpo costuma trazer a mensagem de erro real e um código de erro interno; o status HTTP é só a categoria. Sempre inspecione cabeçalhos como Retry-After, WWW-Authenticate e Location junto com o status.
Códigos não-2xx prejudicam o SEO?
Alguns sim, outros não. Respostas 5xx prolongadas sinalizam um site não confiável e os mecanismos de busca acabam reduzindo a frequência de crawl. Redirecionamentos 301/308 transferem link equity; 302/307 não. 410 remove páginas do índice; 404 demoram mais. 200 com um corpo de soft-404 (uma página real de 'não encontrado' retornando 200) é pior para SEO do que um 404 verdadeiro, porque enche o índice com páginas vazias.
Para que servem 418, 451 e outros códigos incomuns?
418 'I'm a teapot' é o famoso código de 1º de abril da RFC 2324 — serviços de verdade nunca deveriam retorná-lo em produção. 451 Unavailable For Legal Reasons indica que o recurso está bloqueado por uma exigência legal (referência ao Fahrenheit 451 do Bradbury). 429 Too Many Requests sinaliza limitação de taxa e deve vir acompanhado de um cabeçalho Retry-After. 503 Service Unavailable é o código adequado para manutenção planejada.