Consulte qualquer código de status HTTP: o que significa, quando os servidores o enviam e qual especificação o define. Pesquise por número ou palavra-chave, filtre por classe e acesse diretamente um código por link.
O servidor recebeu os cabeçalhos da solicitação, e o cliente pode enviar o corpo. Ocorre quando um cliente envia “Expect: 100-continue” antes de fazer upload de um corpo grande.
O servidor aceitou uma solicitação WebDAV, mas ainda não a concluiu. Esse código foi removido das especificações WebDAV posteriores e raramente é usado hoje.
Enviado antes da resposta final para que o navegador possa começar a pré-carregar os recursos listados nos cabeçalhos Link. Usado por CDNs e servidores para acelerar o carregamento das páginas.
A solicitação foi concluída com sucesso, e a resposta contém o resultado. Esta é a resposta normal ao carregar uma página ou fazer uma chamada API com sucesso.
A solicitação foi concluída com sucesso e criou um novo recurso, geralmente identificado pelo cabeçalho Location. É comum após um POST bem-sucedido que cria um registro.
A solicitação foi aceita para processamento, mas ainda não foi concluída. Usado por APIs que colocam tarefas em fila, como exportações ou trabalhos em lote.
A solicitação foi concluída com sucesso e não há conteúdo para retornar. Comum em solicitações DELETE e ao salvar dados quando o cliente não precisa de um corpo de resposta.
O servidor retorna apenas o intervalo de bytes solicitado pelo cliente. Ocorre durante a transmissão de vídeos, ao retomar downloads ou quando o cliente envia um cabeçalho Range.
O recurso foi movido permanentemente para a URL indicada no cabeçalho Location. Navegadores e mecanismos de busca atualizam seus links; alguns clientes mudam POST para GET ao seguir o redirecionamento.
O recurso está temporariamente em outra URL, indicada no cabeçalho Location. É comum após logins e em redirecionamentos de curto prazo; os navegadores geralmente o seguem com GET.
O cliente deve buscar o resultado em outra URL usando GET. Usado após um POST de formulário para redirecionar a uma página de confirmação (o padrão Post/Redirect/Get).
A cópia em cache ainda é válida, então o servidor não envia um corpo. Ocorre quando um navegador revalida um arquivo em cache com If-None-Match ou If-Modified-Since.
O recurso está temporariamente em outra URL, e o cliente deve repetir a solicitação com o mesmo método e corpo. Também é usado pelos navegadores para redirecionamentos internos de HSTS para HTTPS.
O recurso foi movido permanentemente, e o cliente deve usar o mesmo método e corpo na nova URL. É a versão permanente do 307, segura para redirecionar solicitações POST.
O servidor não pode processar a solicitação porque ela está malformada, por exemplo, contém JSON inválido, um parâmetro de consulta incorreto ou um cookie corrompido.
A solicitação não contém credenciais de autenticação válidas. Apesar do nome, significa “não autenticado”; o servidor envia um cabeçalho WWW-Authenticate que explica como fazer login.
O servidor entendeu a solicitação, mas a recusa. Fazer login novamente não vai resolver. Pode ocorrer quando faltam permissões, a listagem de diretórios está desativada ou um firewall bloqueia o cliente.
O servidor não consegue encontrar o recurso solicitado. Geralmente, isso acontece por causa de um link digitado incorretamente ou desatualizado, uma página excluída ou uma rota de API incorreta.
O recurso existe, mas não aceita o método HTTP usado, como POST em uma URL somente para leitura. A resposta lista os métodos permitidos no cabeçalho Allow.
O recurso foi removido permanentemente e não voltará. Ao contrário do 404, esse código informa aos mecanismos de busca que removam a URL mais rapidamente.
Uma condição nos cabeçalhos da solicitação, como If-Match, não foi atendida. É usado para evitar que um recurso seja sobrescrito após ter sido alterado desde a última vez que o cliente o leu.
A URL é mais longa do que o servidor consegue processar. Geralmente, isso acontece quando um formulário envia dados demais usando GET ou quando um loop de redirecionamento continua acrescentando parâmetros.
Uma brincadeira de 1º de abril criada em 1998 para o Hyper Text Coffee Pot Control Protocol: um bule que se recusa a fazer café. O HTTP reserva esse código como não utilizado, mas alguns servidores o retornam como easter egg ou para rejeitar bots indesejados.
A solicitação chegou a um servidor que não consegue gerar uma resposta para esse host, por exemplo, quando uma conexão HTTP/2 é reutilizada para outro domínio.
A solicitação está bem formada, mas seu conteúdo é inválido, como um formulário que não passou pelas regras de validação. É amplamente usado por APIs para indicar erros de validação.
O cliente enviou solicitações demais em determinado período. APIs usam esse código para limitar a taxa de solicitações e muitas vezes incluem um cabeçalho Retry-After indicando quando tentar novamente.
Os cabeçalhos da solicitação são grandes demais, muitas vezes por causa de cookies em excesso ou muito grandes. Limpar os cookies do site geralmente resolve o problema.
Não é um código padrão. O nginx o usa internamente para encerrar a conexão sem enviar uma resposta, geralmente para descartar tráfego indesejado; os clientes nunca o recebem de fato.
Não é um código padrão. O nginx o registra quando o cliente encerra a conexão antes de o servidor responder, por exemplo, quando alguém cancela uma página lenta ou ocorre um tempo limite no cliente.
O servidor encontrou um erro inesperado e não conseguiu concluir a solicitação. É um erro genérico causado por um bug, uma falha ou uma configuração incorreta; os detalhes estão nos logs do servidor.
Um gateway ou proxy recebeu uma resposta inválida do servidor upstream. Isso é comum quando a aplicação por trás do nginx ou de um balanceador de carga falha ou está sendo reiniciada.
O servidor está temporariamente impossibilitado de atender à solicitação porque está sobrecarregado ou em manutenção. Um cabeçalho Retry-After pode informar quando tentar novamente.
Um gateway ou proxy não recebeu uma resposta do servidor upstream a tempo. Ocorre quando uma solicitação ao backend demora demais, como uma consulta longa ao banco de dados.
Não é um código padrão. Usado por alguns serviços de hospedagem compartilhada (módulos do Apache, cPanel) quando um site excede o limite de largura de banda.
Não é um código padrão. O Cloudflare o retorna quando o servidor de origem recusa a conexão, geralmente porque o servidor web está fora do ar ou bloqueia os endereços IP do Cloudflare.
Não é um código padrão. O Cloudflare o retorna quando não consegue acessar o servidor de origem, por exemplo, devido a um problema de DNS ou roteamento.
Não é um código padrão. O Cloudflare o retorna quando se conecta à origem, mas não recebe uma resposta HTTP dentro do tempo limite (100 segundos por padrão).
Não é um código padrão. O Cloudflare o retorna quando o certificado SSL da origem é inválido e o modo Full (strict) SSL está ativado.
Definido em Cloudflare
Como usar
Digite um número de código (como 404 ou apenas 5 para todos os erros do servidor) ou uma palavra-chave, como “redirecionamento” ou “tempo limite”.
Restrinja a lista com o filtro de classe: informacional, sucesso, redirecionamento, erro do cliente ou erro do servidor.
Use “Copiar link” em qualquer código para compartilhar um link direto para ele, por exemplo, em um relatório de erro.
Como funciona
Toda resposta HTTP começa com um código de status de três dígitos. O primeiro dígito define a classe: respostas informativas 1xx, sucesso 2xx, redirecionamento 3xx, erros causados pela solicitação 4xx e erros no servidor 5xx. Clientes que não reconhecem um código específico o tratam como o código x00 da mesma classe; assim, um código 4xx desconhecido é tratado como 400.
Os códigos principais são definidos na RFC 9110 (Semântica HTTP, 2022), que substituiu a antiga RFC 7231. Outros vêm de extensões: WebDAV (RFC 4918), RFC 6585 para 428, 429, 431 e 511, RFC 7725 para 451 e RFC 8470 para 425. A RFC 9110 também mudou o nome de dois códigos: 413 agora é “Content Too Large” e 422, “Unprocessable Content”; você ainda pode encontrá-los com os nomes antigos “Payload Too Large” e “Unprocessable Entity”.
Alguns códigos encontrados em logs não são padrões. O nginx usa internamente os códigos 444 e 494–499 (499 indica que o cliente desistiu de esperar), e o Cloudflare retorna 520–526 quando não consegue obter uma resposta adequada do servidor de origem. Eles estão marcados como “Não padrão” na lista. As frases de motivo (como “Not Found”) são exibidas em inglês, conforme aparecem nas especificações; HTTP/2 e HTTP/3 enviam apenas o número.
Exemplos
301 ou 308 ao mudar um site de endereço
Ambos são permanentes. Use 301 para mudanças comuns de página; use 308 quando os clientes precisarem repetir solicitações POST ou PUT para a nova URL, pois alguns clientes transformam POST em GET após um 301.
401 ou 403
Uma API retorna 401 quando nenhum token é enviado ou quando o token expirou, então o cliente deve fazer login. Ela retorna 403 quando o token é válido, mas o usuário não tem permissão; nesse caso, fazer login novamente não adianta.
Como diagnosticar um 502 atrás do nginx
Um erro 502 Bad Gateway do nginx significa que a aplicação por trás dele não respondeu corretamente. Verifique se o processo do app está em execução e o que foi registrado no log; 504, por outro lado, significa que a resposta demorou demais.
Perguntas frequentes
Qual é a diferença entre 404 e 410?
404 significa que o servidor não consegue encontrar o recurso e não diz nada sobre o futuro. 410 indica que o recurso foi removido deliberadamente e não voltará, o que ajuda os mecanismos de busca a remover a URL mais rapidamente.
Um erro de validação deve retornar 400 ou 422?
Ambos são usados. 400 é adequado para solicitações que o servidor não consegue interpretar, como um JSON malformado. 422 é adequado para solicitações interpretadas corretamente, mas com valores inválidos, como um campo de e-mail sem @.
418 I'm a teapot é um código de status real?
Ele vem de uma RFC de 1º de abril de 1998. A RFC 9110 reserva o código 418 como não utilizado, para que não seja atribuído a outra finalidade. Alguns servidores o retornam como brincadeira, mas ele não tem significado padrão.
De onde vem o código 499?
499 é específico do nginx. Ele aparece nos registros do nginx quando o cliente fecha a conexão antes de o servidor enviar uma resposta. O cliente nunca recebe um 499; em geral, esse código indica respostas lentas ou tempos limite no lado do cliente.
Os mecanismos de busca tratam 302 como 301?
Um 302 indica um redirecionamento temporário, então, inicialmente, os mecanismos de busca costumam manter a URL original no índice. Se um 302 permanecer por muito tempo, o Google poderá tratá-lo como um redirecionamento permanente. Use 301 ou 308 para mudanças permanentes.
Privacidade
A lista faz parte da página. A pesquisa e a filtragem acontecem no seu navegador; seus termos de pesquisa não são enviados a lugar nenhum nem incluídos nas estatísticas.