Os Códigos de Status HTTP Mais Comuns (E O Que Fazer Sobre Cada Um)

Seu pager dispara às 2 da manhã. A carga do alerta tem um código de status. O que você faz a seguir depende quase inteiramente de qual código você vê.

Essa é a parte que a maioria dos guias de códigos de status HTTP pula. Eles listam definições, classificam os códigos em cinco grupos e param. Útil como glossário, menos útil quando um endpoint real está lançando 502s e um executivo pergunta por que o checkout está quebrado.

Este guia cobre os mesmos dez códigos que você verá com mais frequência, além de algumas menções honrosas. Para cada um: o que significa, o que normalmente o dispara em produção, e o que verificar primeiro. O objetivo é encurtar o tempo entre “vejo o código” e “sei o que consertar.”

O Que É um Código de Status HTTP?

Um código de status HTTP é um número de três dígitos que o servidor envia de volta com cada resposta. Ele informa ao cliente se a solicitação teve sucesso, falhou ou precisa ser redirecionada. Você os vê em todo lugar: na guia Network das DevTools do seu navegador, em logs de balanceadores de carga, em alertas de monitoramento, em painéis de CDN. Este guia foca naqueles que realmente acordam as pessoas.

As Cinco Categorias de Códigos de Status HTTP

O primeiro dígito do código indica a classe da resposta:

• 1xx Informativo. Raro no trabalho diário. Usado principalmente para negociação de protocolo (100 Continue, 101 Switching Protocols para atualizações WebSocket).
• 2xx Sucesso. A solicitação funcionou. 200 é o padrão; 201 significa que um recurso foi criado; 204 significa sucesso sem corpo.
• 3xx Redirecionamento. O recurso está em outro lugar. Navegadores e crawlers seguem esses automaticamente até um limite.
• 4xx Erro do Cliente. A solicitação estava errada. URL errada, autenticação ausente, permissões bloqueadas, payload malformado.
• 5xx Erro do Servidor. A solicitação estava correta. O servidor falhou ao atendê-la.

A divisão entre 4xx e 5xx é a parte que mais importa para o triagem. Um 4xx diz “quem chamou fez algo errado.” Um 5xx diz “nós fizemos algo errado.” O primeiro volta para quem chamou o endpoint. O segundo vai para você.

Para uma enumeração completa, a referência completa de códigos de status HTTP na wiki da Dotcom-Monitor lista todos os códigos definidos na especificação. O resto deste guia foca nos que realmente aparecem em alertas.

Os Dez Códigos de Status HTTP Mais Comuns

200 OK

O servidor processou a solicitação e retornou a resposta esperada. Este é o código que você quer ver na imensa maioria das requisições para um site de produção saudável.

Cuidado com: um 200 OK não é prova de que a página está correta. JavaScript pode falhar silenciosamente e renderizar uma página em branco. Uma API pode retornar 200 com um corpo de erro. Um formulário de login pode mostrar “credenciais inválidas” dentro de uma resposta 200. Checagens apenas por código de status não detectam isso. Combine com checagens em navegador real (mais sobre isso abaixo).

301 Moved Permanently

O recurso tem uma nova URL permanente. Navegadores cacheiam o redirecionamento agressivamente. Motores de busca transferem a maior parte da autoridade do link para o destino.

Use para: mudanças de URL após migração de site, trocar HTTP por HTTPS, consolidar caminhos duplicados, desativar slugs antigos. Uma vez que um 301 está ativo e em cache, revertê-lo é doloroso—navegadores e crawlers continuarão indo para o novo local por semanas.

302 Found (Redirecionamento Temporário)

O recurso está temporariamente em outro lugar. Navegadores não cacheiam o redirecionamento, e motores de busca não transferem toda a autoridade do link.

Cuidado com: 302 é usado demais. Times o escolhem porque o helper de redirecionamento padrão do framework retorna 302. Se a mudança é permanente, use 301. Se precisar preservar o método HTTP (POST continua POST), use 307 ou 308. O Google eventualmente tratará 302 persistentes como 301, mas “eventualmente” não é uma estratégia.

400 Bad Request

O servidor não consegue interpretar a solicitação. JSON malformado, cabeçalhos inválidos, payloads muito grandes, violações de esquema.

Verifique primeiro: o corpo da solicitação. Um pico de 400s em um endpoint de API geralmente significa que um cliente começou a enviar uma estrutura errada—um deploy do lado do consumidor, uma mudança de esquema do seu lado, ou uma integração de terceiros que atualizou o formato. Compare o payload da solicitação com a última versão boa conhecida.

401 Unauthorized

A solicitação não tem credenciais, ou as credenciais foram rejeitadas. O nome é enganoso—a questão é autenticação, não autorização.

Verifique primeiro: tokens. Um pico súbito de 401 em endpoints que antes funcionavam pode significar token expirado, chave de assinatura rotacionada, problema no provedor OIDC, ou alguém mudou a claim de audiência. Se seu monitoramento de disponibilidade de API mostra 401s onde havia 200s, a camada de autenticação geralmente é o culpado.

403 Forbidden

As credenciais são válidas, mas o chamador não tem permissão para acessar este recurso. O problema é autorização, não autenticação.

Verifique primeiro: permissões e regras da infraestrutura. 403s aparecem quando uma política IAM muda, uma regra WAF começa a bloquear tráfego legítimo, uma política de acesso CDN fica muito agressiva, ou uma flag de recurso é ativada para o segmento errado de usuários. Se 403s começaram logo após um deploy, examine as diferenças de políticas e configurações antes do código da aplicação.

404 Not Found

O servidor entendeu a solicitação mas não tem recurso na URL. O código de status mais famoso da existência.

Dois cenários para separar:

• 404s isolados por erros de digitação, favoritos antigos ou crawlers procurando vulnerabilidades. Esses são ruído de fundo.
• Um surto de 404s em URLs canônicos logo após um deploy. Isso é um release quebrado—rotas removidas, artefato da build faltando, ou alguém lançou uma mudança de slug sem redirecionamentos. Faça rollback ou lance um hotfix.

404s persistentes em páginas indexadas acabarão sendo desindexados pelo Google, então páginas canônicas que retornam 404 também têm um custo SEO.

Como Corrigir

Caminho rápido: se a página mudou, adicione um redirecionamento 301 da URL antiga para a nova para que usuários e crawlers caiam no lugar certo. Se a página realmente sumiu, retorne um 404 ou 410 real em vez de um redirecionamento vago para a homepage.

Correção real: audite a origem dos 404s. Links internos quebrados são corrigidos na fonte; rotas faltando após deploy recebem hotfix; uma migração ruim que removeu slugs precisa de um mapa de redirecionamento. Faça crawling periódico do seu site para encontrar links mortos antes do Google.

500 Internal Server Error

O servidor encontrou uma exceção não tratada. O 5xx genérico. Diz que algo quebrou, mas não o que.

Verifique primeiro: logs da aplicação. Todo 500 tem um stack trace em algum lugar—se não tiver, seu sistema de logs precisa de ajustes antes do código. Gatilhos comuns: exceção não capturada em código recém-deployado, dependência downstream retornando formato inesperado, pool de conexão com banco esgotado, loop de reinício por falta de memória. Um pico sustentado de 500 em produção deve disparar paginação on-call.

Como Corrigir

Caminho rápido: se o pico começou logo após um release, faça rollback. Um 500 que aparece minutos após o deploy é o deploy até prova em contrário.

Correção real: leia o stack trace e corrija o caminho de código com erro, depois adicione teste de regressão para não voltar. Se o gatilho foi um limite de recurso—pool de conexões, memória, handle de arquivo—eleve o limite e configure alerta antes de atingir novamente.

502 Bad Gateway

Um proxy, balanceador de carga ou CDN recebeu resposta inválida do servidor upstream. O proxy está saudável. O que está atrás dele não está.

Verifique primeiro: saúde do upstream. Gatilhos comuns: container da aplicação caiu e o load balancer ainda está roteando para ele, upstream está expirando antes de responder, pod Kubernetes em CrashLoopBackOff, worker Nginx mal configurado, ou conexão entre proxy e upstream resetada. 502 é um dos códigos mais informativos em arquiteturas em camadas—diz que a borda está ok e o problema está um salto atrás.

Como Corrigir

Caminho rápido: reinicie ou substitua a instância upstream com problema e confirme que os health checks do load balancer removem os nós mortos da rotação.

Correção real: descubra por que o upstream retornou lixo. Verifique se o timeout do proxy é menor que o tempo real de resposta do upstream, se o pod está em loop de crash na inicialização, e se as configurações de keep-alive coincidem dos dois lados da conexão.

503 Service Unavailable

O servidor está temporariamente incapaz de atender o pedido. Capacidade esgotada, modo de manutenção, autoscaler ainda iniciando.

Verifique primeiro: saturação de recursos e limites de taxa. 503s em pico de tráfego geralmente significam que autoscaler não acompanha ou limite de conexão foi alcançado. 503s em estado estável geralmente indicam processo em manutenção ou fila congestionada. Algumas plataformas também retornam 503 quando WAF ou sistema anti-bot upstream limita a taxa de um solicitante—vale a pena verificar antes de assumir que a aplicação é o problema.

Como Corrigir

Caminho rápido: retorne o 503 com um cabeçalho Retry-After para que clientes e crawlers bem comportados recuem em vez de bombardear o servidor em dificuldades. Em PHP:

http_response_code(503);
header('Retry-After: 60');

Correção real: encontre o recurso saturado—conexões ao banco, pool de workers, limite do autoscaler—e remova o gargalo. Se o 503 veio de limite de taxa do CDN ou WAF, aumente o limite ou coloque o solicitante legítimo em lista branca.

Outros Códigos Que Vale Conhecer

Os dez acima cobrem a maior parte do tráfego de produção. Mas alguns outros aparecem com frequência suficiente em incidentes reais para que engenheiros on-call os conheçam de vista.

• 304 Not Modified. Enviado quando um recurso em cache ainda está fresco. Comum em tráfego com CDN na frente. Queda nos 304 pode significar mudança nos cabeçalhos cache-control e aumento de uso de banda de origem.
• 307 Temporary Redirect. Como 302, mas preserva o método HTTP. Um POST continua POST. Use 307 em vez de 302 para redirecionar formulários ou chamadas API não idempotentes.
• 308 Permanent Redirect. Como 301, mas preserva o método HTTP. A escolha moderna para redirecionamentos permanentes de endpoints API que usam POST, PUT, PATCH ou DELETE.
• 429 Too Many Requests. Limite de taxa atingido. Ou você está sendo limitado por uma API upstream ou está limitando alguém. Verifique cabeçalhos Retry-After; respeite-os.
• 504 Gateway Timeout. Proxy desistiu de esperar pelo upstream. Diferente de 502 pois o upstream não retornou uma resposta ruim—não retornou resposta a tempo. Normalmente uma query longa, worker congelado, ou API downstream lenta.

301 vs 302 vs 307 vs 308

Os quatro códigos de redirecionamento são confundidos constantemente. A diferença se baseia em duas coisas: se a mudança é permanente e se o método HTTP é preservado.

Para uma página comum que mudou para sempre, use 301. Quando o redirecionamento precisa manter um POST como POST—envio de formulário ou chamada API não idempotente—use 307 se a mudança for temporária ou 308 se for permanente.

A Referência Completa de Códigos de Status HTTP

Os códigos acima cobrem quase tudo que dispara alerta real. Para os incomuns—que aparecem uma vez por trimestre e fazem você parar para buscar—aqui está a lista padrão completa, além dos códigos não padrão que você verá de fornecedores comuns de infraestrutura.

1xx Informativo

O servidor recebeu a solicitação e continua processando. Você raramente verá isso em logs de aplicação porque a maioria dos clientes e proxies os lida de forma transparente.

2xx Sucesso

A solicitação foi recebida, compreendida e aceita. 200 é a principal; os demais importam quando se constrói APIs ou se trabalha com conteúdo parcial, WebDAV, ou operações em lote.

3xx Redirecionamento

O recurso está em outro lugar, ou a cópia em cache ainda é boa. 301 e 302 dominam; os outros importam para APIs (307/308 preservam o método HTTP) e pipelines de cache (304 economiza banda de origem).

4xx Erros do Cliente

A solicitação estava errada. A maioria você nunca verá; meia dúzia comuns aparecem diariamente. Vale saber que existem raros para não perder tempo tentando adivinhar quando um 418 ou 451 aparece no log.

5xx Erros do Servidor

A solicitação estava correta. Algo no lado do servidor falhou. São os códigos mais prováveis de acordar alguém.

Códigos Não Padrão e de Fornecedores

Cloudflare, Nginx, Microsoft e Akamai retornam códigos fora da especificação oficial quando a camada de infraestrutura falha. Estes são os que você deve reconhecer de vista porque indicam que a falha está na borda, não na origem.

Faixas de códigos não listadas acima (104-199, 209-225, 227-299, 309-399, 432-450, 452-499, 512-599) são não atribuídas, depreciadas ou reservadas para uso de fornecedores. Trate qualquer código nessas faixas como específico de fornecedor e consulte a documentação da sua infraestrutura.

Os Códigos Que Seu Monitoramento Deve Realmente Alertar

Dos 60+ códigos acima, os que merecem limiares de alerta na maioria dos setups de produção são uma lista bem mais curta:

• 200—como um baseline. Uma queda súbita significa que algo mais está errado.
• 301, 302, 307, 308—contagem de redirecionamentos. Picos podem significar roteamento mal configurado ou deploy que quebrou URLs canônicos.
• 400—requisições malformadas. Geralmente mudança do lado consumidor.
• 401, 403—falhas de autenticação e permissão. Frequentemente token, IAM ou alteração em WAF.
• 404—recursos ausentes. Ruído de fundo como casos isolados; problema de release em picos.
• 408—timeouts do cliente. Vale alertar em taxas sustentadas; sinalizam chamadas downstream lentas.
• 429—limite de taxa. Ou você está sendo throttled ou está throttleando alguém.
• 500, 502, 503, 504—falhas de aplicação, upstream, capacidade e timeout de gateway. Estes disparam paginação on-call.
• 520-526—falhas na borda do Cloudflare. Se estiver atrás do Cloudflare, são sinais críticos que isolam a falha no caminho borda-origem.

Todo o resto vale registrar, mas raramente merece acordar alguém.

Como Verificar o Código de Status HTTP de uma Página

Antes de agir em um código, você tem que vê-lo. Três maneiras, da mais rápida para a mais completa.

No Chrome DevTools

1. Abra a página.
2. Clique com o botão direito em qualquer lugar e escolha Inspecionar, depois abra a aba Network.
3. Recarregue. A primeira requisição do documento mostra o código na coluna Status.

Na Linha de Comando

Uma requisição só com cabeçalho retorna a linha de status sem baixar o corpo:

curl -I https://example.com

A primeira linha da resposta é o código de status—por exemplo, HTTP/2 200.

Em Escala

Checagens pontuais dizem o estado atual. Não pegam falhas que ocorrem às 3 da manhã e somem antes de você acordar. Para falhas intermitentes, você precisa de checagens agendadas de várias regiões—o que monitoramento sintético faz.

Quando um 200 OK Mente

Um time de e-commerce é acionado às 11 da manhã numa terça-feira. A conversão caiu 80%. Eles conferem o dashboard de uptime. Todos os endpoints estão verdes. Todos os códigos de status são 200. Todas as regiões reportam que o site está no ar.

O site não está no ar. Um deploy 40 minutos antes enviou um bundle JavaScript que quebra a página de checkout. O HTML renderiza, o servidor retorna 200, o monitor de código de status vê 200, nenhum alerta dispara. Usuários veem carrinho vazio e saem.

Este é o modo de falha que o monitoramento puro de código de status não consegue captar. A correção é em camadas:

• Execute checagens em navegador real em caminhos críticos do usuário—home, busca, produto, carrinho, checkout. Navegadores reais executam o JavaScript e mostram erros no cliente que uma checagem estilo curl perde.
• Observe sinais no corpo: presença de palavras-chave, visibilidade de elementos, estrutura esperada da resposta. Não confie só no código de status.
• Vincule deploys ao monitoramento: qualquer checagem que fique vermelha em até 15 minutos após um release deve marcar o deploy automaticamente. Metade do tempo pós-morte é descobrir o que mudou; o sistema de monitoramento já sabe.

O Que É um Soft 404?

Uma versão desse problema tem nome: soft 404. Um soft 404 é uma página que retorna 200 OK mas avisa ao usuário que o conteúdo não existe—uma mensagem “página não encontrada” servida com código de sucesso. A orientação do Google é retornar um 404 ou 410 real, pois soft 404s desperdiçam orçamento de crawl e confundem o índice sobre quais páginas são reais.

Monitoramento puro por código não pega soft 404, pela mesma razão que deixa passar checkout quebrado: o código diz 200. Checagens em navegador real com validações no corpo—procurando o conteúdo real esperado ou a ausência da string “not found”—pegam.

Como Códigos HTTP Afetam SEO

Motores de busca usam códigos de status para decidir o que rastrear, o que indexar, e com que frequência voltar. Três padrões importam:

• Códigos 4xx corroem o índice ao longo do tempo. Uma página que retorna 404 por várias tentativas de crawl é removida. Se você apagar uma página, redirecione com 301 em vez de deixar 404.
• Códigos 5xx desaceleram o rastreamento e prejudicam rankings. Googlebot interpreta 5xx persistentes como “este site está doente.” A taxa de rastreamento cai, indexação desacelera, rankings podem cair.
• 301 vs 302 importa. 301 passa autoridade de link. 302 é tratado como temporário e pode não passar. Se mudança for permanente, escolha 301.

A conclusão prática: erros 5xx não são só problema de disponibilidade. São problema de SEO que se agrava quanto mais persistem. Erros DNS, TCP, TLS e HTTP têm custos SEO diferentes—saber em qual camada o erro ocorre ajuda você a triagem mais rápido.

Monitorando Códigos de Status HTTP Sem Afundar em Alertas

Todo time que monitora tráfego HTTP às vezes enfrenta o mesmo problema: alertas demais, sinal de menos. Alguns hábitos mantêm o monitoramento de código de status útil em vez de ruidoso.

Alerta por taxas, não por requisições únicas. Um 500 é ruído. Cinquenta 500 em cinco minutos é incidente. Configure limiares baseados no volume de tráfego baseline.

Separe endpoints públicos dos internos. Um 500 na API de checkout deve alertar. Um 500 num endpoint administrativo pouco usado pode esperar horário comercial.

Teste de onde seus usuários estão. Uma checagem de um data center não pega falha específica regional do CDN. Use rede de monitoramento com múltiplas geografias para detectar problemas locais antes dos clientes.

Combine checagens de status com checagens de conteúdo. 200 OK é ponto de partida, não linha de chegada. Valide que a resposta tem o que deve ter.

O monitoramento de aplicações web da Dotcom-Monitor trata todos os quatro: alerta por taxa, segmentação de endpoints, locais globais de monitoramento, e checagens de conteúdo em navegador real. Para stacks focadas em API, o caminho de monitoramento de API adiciona validação de esquema e SLOs de tempo de resposta em cima de checagens por código de status. Ambos alimentam o mesmo pipeline de alertas para você não montar sinais de três vendors diferentes.

Considerações Finais

Os códigos de status HTTP mais comuns não mudaram em anos. 200, 301, 404, 500, 502, 503—você verá todos esta semana. O que muda é a velocidade com que seu time passa de “vi o código” para “consertei a causa.”

Essa lacuna é onde um bom monitoramento compensa. Só códigos dizem que algo ocorreu. Checagens em camadas—status, conteúdo, navegador real, multi-região—dizem o que, onde, e o que fazer a seguir.

Se quiser ver como é, a Dotcom-Monitor oferece teste gratuito. Aponte para um dos seus endpoints e veja o que aparece.

Perguntas Frequentes