404, 500 e 401: o que esses números querem dizer

Cena: tela cinza com um número e a pessoa não sabe se é culpa dela

Você clica num link, espera a página carregar e aparece uma mensagem seca: 404. Ou pior: 500 Internal Server Error. No celular a tela fica quase vazia. No computador, às vezes só um número grande e uma frase em inglês que ninguém pediu para traduzir.

A primeira reação é comum. Será que eu errei o endereço? Será que meu login expirou? Será que o site caiu? Ou será que a culpa é da minha internet?

Esses números não são códigos secretos de programação. São códigos de status HTTP: respostas padronizadas que o servidor manda de volta quando você (ou um aplicativo) faz um pedido. Entender o que cada faixa significa muda a forma como você reage. Em vez de reiniciar o roteador por reflexo, você passa a saber se o problema está no pedido, no servidor ou em outra etapa do caminho.

Este artigo decodifica os códigos que mais aparecem quando a página ou a API falha. Sem jargão desnecessário. Com exemplos do dia a dia e um roteiro curto do que fazer a seguir.

O que é um código de status HTTP

Quando você abre um site, o navegador envia um pedido HTTP para um servidor. O servidor responde com duas coisas importantes: um código numérico de três dígitos e, em geral, um conteúdo (a página, um JSON, uma mensagem de erro).

Esse número de três dígitos é o código de status. Ele resume o resultado do pedido em uma categoria fácil de classificar:

• 1xx: informação intermediária (quase nunca aparece para quem só navega)
• 2xx: deu certo
• 3xx: redirecionamento (o recurso mudou de lugar)
• 4xx: problema no pedido (do lado de quem pediu, ou do que foi pedido)
• 5xx: problema no servidor (do lado de quem deveria responder)

Você não precisa decorar todos. Para o uso prático, 4xx e 5xx resolvem a maior parte das dúvidas. O 404, o 401 e o 500 estão nessa lista porque são os que mais geram confusão: o primeiro parece “sumiu”, o segundo parece “não pode entrar”, o terceiro parece “explodiu algo lá atrás”.

Uma observação útil: o código descreve o resultado daquele pedido específico. Não é um diagnóstico completo do seu computador. Um 404 num link antigo não significa que a internet caiu. Um 500 numa loja online não significa que o seu cartão está bloqueado. É a conversa entre cliente e servidor dizendo: “recebi o pedido, e o resultado foi este”.

Se você integra sistemas (planilhas, apps, webhooks, APIs), o mesmo número aparece no retorno da chamada. A lógica é idêntica: o código conta se o pedido foi aceito, recusado ou se o servidor falhou ao processar.

4xx: o pedido que não deu (404, 401, 403, 400)

A família 4xx diz, em essência: o servidor entendeu a conversa, mas não conseguiu (ou não quis) atender aquele pedido do jeito que veio. Em muitos casos, ajustar o endereço, o login ou o formato dos dados resolve. Em outros, o recurso simplesmente não existe mais.

404 Not Found

O clássico. Significa: “não achei o que você pediu neste endereço”. Causas comuns:

• URL digitada errada (um traço a mais, um ID antigo)
• página removida ou movida sem redirecionamento
• link compartilhado de um post que foi apagado
• rota de API inexistente (/usuarios/999 quando o usuário 999 não existe, dependendo de como a API foi feita)

O 404 quase nunca é culpa da sua conexão. Vale conferir o endereço, buscar o conteúdo pelo menu do site ou pedir o link atualizado a quem enviou.

401 Unauthorized

Apesar do nome em inglês, na prática costuma significar: “você não está autenticado” (ou a autenticação falhou). Exemplos:

• sessão expirada
• token de API ausente, inválido ou vencido
• usuário e senha incorretos
• tentativa de acessar área logada sem login

Se você vê 401, o caminho típico é entrar de novo, renovar o token ou conferir as credenciais da integração. Não é o mesmo que “você não tem permissão para este recurso” (isso costuma ser 403).

403 Forbidden

Aqui o servidor sabe quem você é (ou pelo menos processou o pedido), mas nega o acesso. Diferença prática em relação ao 401:

• 401: “quem é você?” (falta autenticação válida)
• 403: “eu sei quem é, mas você não pode”

Pode ser perfil sem permissão, conteúdo restrito, IP bloqueado ou regra de segurança do site. Trocar de senha raramente resolve um 403. O que resolve é autorização: outra conta, outro papel, ou liberação pela equipe responsável.

400 Bad Request

O pedido chegou malformado. Em páginas, aparece menos. Em APIs e formulários, é frequente: campo obrigatório faltando, data em formato errado, JSON inválido, parâmetro fora do esperado. Se você está testando uma integração e recebe 400, o próximo passo é olhar o corpo da resposta. Muitas APIs devolvem uma mensagem dizendo qual campo falhou. Conhecer a estrutura de um JSON ajuda exatamente nesses momentos.

Outros 4xx que valem um reconhecimento rápido:

• 429 Too Many Requests: você (ou o app) pediu demais em pouco tempo. Espere e tente de novo com menos frequência.
• 408 Request Timeout: o servidor cansou de esperar o pedido completar. Às vezes é rede instável; às vezes o cliente demorou demais para enviar os dados.

Resumo da faixa 4xx: revise o que você pediu (URL, login, permissão, formato). O servidor, em geral, está “vivo”. Ele só não aceitou aquele pedido.

5xx: o servidor que falhou (500, 502, 503)

A família 5xx aponta para o outro lado da mesa. O pedido pode até estar correto, mas o servidor (ou algo na cadeia de servidores) não conseguiu cumprir a tarefa.

500 Internal Server Error

É o “deu ruim” genérico. Algo quebrou no processamento: bug no código, configuração errada, falha ao falar com o banco de dados, exceção não tratada. Para quem usa o site, a ação imediata é simples: anotar a hora, tentar de novo em alguns minutos e, se for crítico (pagamento, prazo), avisar o suporte com o horário e a página exata.

Evite ficar clicando desesperadamente em “pagar” ou “enviar” dezenas de vezes. Em alguns sistemas isso cria pedidos duplicados quando o serviço volta.

502 Bad Gateway

Imagine uma recepção que precisa consultar outro setor e recebe uma resposta inválida (ou nenhuma resposta útil). O 502 costuma indicar problema entre servidores: proxy, CDN, balanceador ou API intermediária que não devolveu o que era esperado. Para o usuário final, a sensação é a mesma de um site fora do ar. Para quem opera sistemas, é um sinal de olhar a cadeia: quem está na frente e quem está atrás.

503 Service Unavailable

O serviço está temporariamente indisponível. Motivos típicos: manutenção programada, sobrecarga, fila cheia. Diferente do 500 “explodiu”, o 503 muitas vezes é intencional ou transitório: “agora não dá, tente mais tarde”. Alguns servidores enviam um cabeçalho sugerindo quando tentar de novo. Se a página de status da empresa existir, é o primeiro lugar a checar.

Outros 5xx úteis no radar:

• 504 Gateway Timeout: um servidor intermediário esperou demais por outro. Rede lenta entre serviços, consulta pesada, timeout curto demais.
• 501 Not Implemented: o servidor não sabe atender aquele método ou recurso. Mais raro no uso diário de sites.

Resumo da faixa 5xx: o problema tende a estar do lado do serviço. Esperar, verificar status públicos e abrir chamado com contexto costuma ser mais eficaz do que culpar o Wi-Fi.

2xx e 3xx em uma frase (deu certo ou redirecionou)

2xx significa sucesso. O mais famoso é o 200 OK: pedido atendido. Em criação de recursos via API, o 201 Created é comum. Em exclusões, às vezes aparece 204 No Content (deu certo, sem corpo na resposta).

3xx significa redirecionamento. O navegador (ou o cliente HTTP) é informado de que o recurso está em outro lugar. O 301 é permanente; o 302 e o 307 são temporários, com pequenas diferenças técnicas entre si. Na prática do dia a dia: você digitou um endereço antigo e foi levado ao novo sem perceber. Quando a integração “some” com a resposta, às vezes o cliente não seguiu o redirecionamento automaticamente. Aí o 3xx deixa de ser invisível e vira parte do debug.

Em uma frase: 2xx = deu certo; 3xx = o caminho mudou, siga o novo endereço.

Se a página responde 200 e ainda não aparece na busca, veja como saber se o Google indexou a página.

Como ler o número no navegador e numa ferramenta de integração

No navegador, o código nem sempre aparece grande na tela. Quando a página de erro é customizada, você pode ver só uma ilustração e um texto amigável. Para ver o número de verdade:

1. Abra as ferramentas de desenvolvedor (no Chrome e no Edge, F12 ou clique com o botão direito e “Inspecionar”).
2. Vá à aba Rede (Network).
3. Recarregue a página.
4. Clique na requisição principal (documento) ou na chamada que falhou.
5. Olhe o status: 404, 401, 500 etc.

No celular o caminho é menos cômodo, mas a lógica é a mesma quando você usa um computador para inspecionar. Em apps, o número costuma aparecer em logs ou em mensagens técnicas de suporte.

Em ferramentas de integração (Postman, Insomnia, n8n, Make, scripts, SDKs), o status vem junto da resposta. Treine o olhar nesta ordem:

1. Código (404? 401? 500?)
2. Corpo da resposta (mensagem, campo error, detalhes do JSON)
3. Cabeçalhos quando necessário (autenticação, Retry-After em 429/503)

Exemplo mental rápido:

• Status 401 + mensagem “token expired” → renove a autenticação.
• Status 400 + “email is required” → corrija o payload.
• Status 502 + HTML de gateway → problema de infraestrutura no caminho, não no JSON que você montou.
• Status 200 com dados vazios → o HTTP deu certo; a regra de negócio é que pode não ter encontrado registros. Código de sucesso não garante que o conteúdo é o que você esperava.

Essa leitura em camadas evita o erro clássico de tratar todo fracasso como “a API está fora”. Às vezes a API está no ar e só recusou o seu pedido.

O que fazer agora

Quando a tela cinza aparecer de novo, use este roteiro curto:

1. Leia o número. 4xx ou 5xx? Isso já divide o problema ao meio.
2. Se for 404: confira a URL, o link e se o conteúdo ainda existe. Busque pelo site ou peça o endereço atualizado.
3. Se for 401: faça login de novo, renove o token, confira chave de API e ambiente (produção vs teste).
4. Se for 403: autenticação pode estar ok; falta permissão. Troque de conta ou fale com quem libera acesso.
5. Se for 400: revise o que foi enviado (campos, tipos, JSON). A mensagem de erro costuma apontar o campo.
6. Se for 429: espere. Reduza a frequência das chamadas.
7. Se for 500, 502, 503 ou 504: aguarde alguns minutos, tente de novo sem spam de cliques, veja página de status se houver e, se persistir, abra chamado com horário, URL e print do status.
8. Se for 2xx e mesmo assim “não funcionou”: o transporte HTTP pode ter sido bem-sucedido. O problema pode estar no conteúdo, na regra de negócio ou na tela que interpreta a resposta.

Guardar esses poucos códigos já elimina boa parte da ansiedade digital. 404 não é fim do mundo. 500 não é (necessariamente) o seu computador. 401 quase sempre pede autenticação de novo, não um técnico em casa.

Da próxima vez que um número aparecer sozinho no meio da tela, você já sabe o que ele está tentando dizer: o pedido falhou do seu lado, o servidor falhou do lado dele, ou o caminho só mudou de endereço.