HTTP 302 Found: o que significa

O que este erro significa e como reconhecê-lo

• Um navegador, cliente de API, monitor de disponibilidade ou verificador HTTP informa 302 Found.
• A resposta inclui um cabeçalho Location, ou o cliente navega visivelmente para outra URL.
• Uma solicitação parece funcionar em um navegador, mas falha em um cliente de API porque o cliente trata os redirecionamentos de outra maneira.
• Uma solicitação POST ou outro método diferente de GET é redirecionada, e a solicitação seguinte não se comporta como esperado.
• Uma rota, host, método de solicitação, estado de autenticação ou cliente é afetado, enquanto outras URLs funcionam normalmente.
• O DNS pode resolver e o TLS pode ser válido porque a solicitação chegou a um endpoint que se comunica por HTTP; essas verificações são separadas da resposta de redirecionamento.

Causas principais, por probabilidade

1. Roteamento temporário intencional: A aplicação ou o servidor web envia os usuários de uma URL para outra durante uma alteração ou fluxo temporário.
2. Autenticação ou gerenciamento de sessão: Uma solicitação não autenticada é redirecionada para uma rota de login ou relacionada à sessão.
3. Lógica da aplicação: Uma rota, seletor de idioma, fluxo de formulário, feature flag ou regra baseada no estado da solicitação retorna um redirecionamento para determinados usuários ou métodos.
4. Configuração de reverse proxy, CDN ou WAF: Um intermediário aplica um redirecionamento antes que a solicitação chegue à aplicação de origem.
5. Cache ou configuração desatualizada: Uma resposta em cache ou uma regra de roteamento alterada recentemente continua produzindo um redirecionamento inesperado.
6. Incompatibilidade de método ou semântica do redirecionamento: Um 302 pode não ser adequado quando a solicitação seguinte precisa preservar o método e o corpo da solicitação original; o comportamento do cliente deve ser verificado antes da alteração do status.

O código de status, por si só, não identifica qual componente gerou a resposta nem comprova que o site inteiro está com problemas.

Como corrigir

Para visitantes e usuários de API

1. Tente acessar a URL exata novamente uma vez e confirme o esquema, o hostname, o caminho, a query string e a grafia.
2. Verifique se o cliente segue redirecionamentos automaticamente. Se seguir, compare a resposta 302 original com a resposta final, em vez de observar apenas a página final.
3. Se a rota exigir autenticação, faça login pelo fluxo normal do site e tente novamente. Não forneça credenciais a um destino desconhecido.
4. Se uma solicitação de API for afetada, registre o método, a URL da solicitação, o status da resposta, o valor de Location e a resposta final. Não presuma que um redirecionamento de navegador seja um comportamento válido de API.
5. Evite atualizações repetidas quando o destino estiver falhando ou o serviço estiver aplicando limites de solicitação.
6. Se o redirecionamento continuar inesperado, envie ao proprietário do site a URL, o método, o horário, o comportamento do cliente e detalhes sanitizados da resposta. Não compartilhe senhas, cookies, cabeçalhos de autorização ou segredos de API.

Para proprietários de sites e desenvolvedores

1. Reproduza a solicitação exata. Registre o método HTTP, a URL completa, o host, o estado de autenticação, o user agent, o status, o cabeçalho Location e se o cliente seguiu o redirecionamento. A página final exibida pelo navegador pode ocultar o 302 original.
2. Determine se o redirecionamento é intencional. Compare a rota e o método com o roteamento documentado e com os fluxos de autenticação, idioma, manutenção e aplicação.
3. Encontre a camada geradora. Verifique os cabeçalhos da resposta e correlacione o horário da solicitação com os logs da aplicação, do servidor web, do reverse proxy, da CDN e do WAF. Teste um caminho de origem separadamente apenas quando sua infraestrutura e autorização permitirem.
4. Verifique o destino do redirecionamento. Confirme se o valor de Location usa o esquema, host, caminho e parâmetros de consulta pretendidos. Procure cadeias de redirecionamento, loops, um hostname não intencional ou um destino que retorna um erro.
5. Compare os métodos de solicitação. Teste o método afetado separadamente de GET. Se a solicitação precisar manter seu método e corpo, avalie se um status de redirecionamento que preserve o método é exigido pelo design da aplicação e pelo comportamento do cliente.
6. Revise as alterações recentes. Compare deploys e alterações no roteamento, na autenticação, no gerenciamento de sessão, nas regras de proxy, no comportamento da CDN, nas políticas do WAF e no cache.
7. Aplique a correção segura mais pontual. Altere apenas a regra ou o componente responsável, com a autorização adequada e um plano de rollback. Não desative a autenticação nem os controles de segurança apenas para remover um 302.
8. Teste novamente a mesma solicitação. Confirme o status pretendido, o destino, o tratamento do método, os cabeçalhos e a resposta final. Em seguida, teste rotas relacionadas, estados autenticados e não autenticados e métodos de API importantes.

Prevenção e como verificar a correção

• Monitore as taxas de redirecionamento por rota, método HTTP, host, status da resposta e deploy para tornar visíveis alterações inesperadas de 302.
• Mantenha o roteamento da aplicação e as configurações de autenticação, proxy, CDN, WAF e cache sob controle de versão.
• Após os releases, teste tanto a resposta original quanto o destino final de páginas importantes e endpoints de API.
• Inclua casos autenticados, não autenticados e de solicitações diferentes de GET quando esses caminhos forem compatíveis.
• Documente os redirecionamentos temporários intencionais, seus destinos, os métodos afetados e a remoção ou revisão planejada.
• Mantenha logs de servidor e aplicação adequadamente sanitizados por tempo suficiente para correlacionar incidentes de redirecionamento.
• Verifique as cadeias de redirecionamento e a propriedade dos destinos durante as revisões de configuração para evitar loops e alterações não intencionais de host.

Perguntas frequentes