Verificador de cabeçalhos HTTP e redirecionamentos

Siga uma URL salto a salto e leia o que volta: cada redirecionamento da cadeia, o código de status com que ela finalmente responde e os cabeçalhos que envia. O mesmo percurso que uma verificação de uptime faz, sem o cache, os cookies ou o servidor de borda do seu navegador no caminho.

GET a partir da nossa sonda · até 10 saltos · só cabeçalhos, nunca o corpo · nada é armazenado

Digite uma URL para percorrer a cadeia de redirecionamentos.

O que cada código de redirecionamento significa

O número não é enfeite. Ele diz ao cliente se deve lembrar o novo endereço e se o método da requisição sobrevive ao salto, e errar nisso é como um formulário que funcionava começa a perder dados.

código	em cache nos clientes	mantém o método	use para
301 Moved Permanently	sim, de forma agressiva	não, POST geralmente vira GET	Um endereço que nunca vai voltar. Difícil de desfazer: os navegadores guardam.
302 Found	não	não, POST geralmente vira GET	Uma mudança temporária. O padrão que a maioria dos frameworks emite, e a opção segura enquanto você ainda está decidindo.
303 See Other	não	não, sempre vira GET	Depois do envio de um formulário, para que recarregar a página não envie os dados duas vezes.
307 Temporary Redirect	não	sim	Uma mudança temporária em que um POST precisa continuar POST.
308 Permanent Redirect	sim	sim	Uma mudança permanente para uma API, em que transformar POST em GET quebraria quem a chama.

Por que vale a pena ler a cadeia

Está vendo ERR_TOO_MANY_REDIRECTS? Siga como depurar um loop de redirecionamento, um salto por vez para rastrear as respostas e encontrar a regra da aplicação ou do proxy que está mandando a requisição de volta.

Um monitor registra a resposta no fim do percurso, então uma cadeia que funciona é invisível e uma cadeia que quebra parece o site fora do ar. As duas falhas que se escondem ali são um loop, em que uma CDN força HTTPS enquanto a origem manda o HTTPS de volta para HTTP, e um salto que sai discretamente do host em que você começou, o que descarta cookies e cabeçalhos de autorização no caminho.

O comprimento também custa. Cada salto é uma conexão nova, uma nova consulta DNS e, em HTTPS, um novo handshake. Três redirecionamentos na frente de uma página inicial somam quase um segundo antes do primeiro byte de conteúdo real, pago por cada visitante e cada verificação.

Este verificador valida o certificado em cada salto, como um monitor faz, então uma falha de TLS aqui é real. Quando você precisar ler um certificado que já venceu ou é autoassinado, o verificador de certificado SSL o lê sem validar. Se o problema é o próprio nome, a consulta DNS compara dois resolvedores, e o que ICMP, TCP e HTTP comprovam mostra em qual camada uma falha realmente está. Para avaliar juntos o certificado, os redirecionamentos HTTPS e os cabeçalhos de segurança, use o verificador de segurança de sites.

Perguntas frequentes

O que causa ERR_TOO_MANY_REDIRECTS?

Duas regras em que cada uma acha que a outra deveria ter terminado o trabalho. A dupla clássica é uma CDN forçando HTTPS enquanto a origem redireciona HTTPS de volta para HTTP, então a cadeia fica quicando entre as duas para sempre. A lista de saltos acima mostra o ciclo: procure a mesma URL aparecendo duas vezes.

Quais códigos de redirecionamento mantêm o método da requisição?

307 e 308 preservam o método, então um POST continua POST. 301 e 302 não garantem isso e, na prática, quase todo cliente os transforma em GET. 303 sempre vira GET. Se o envio de um formulário só quebra depois que um redirecionamento foi adicionado, geralmente é por isso.

Por que meu navegador mostra algo diferente?

Um navegador responde a partir do próprio cache, envia seus cookies e pode ter recebido um servidor de borda diferente do nosso. A primeira requisição de uma sessão é a honesta, e é ela que esta verificação faz: sem cookies, sem cache e com uma conexão nova a cada vez.

A verificação falha aqui, mas o site carrega para mim. Por quê?

Geralmente é o certificado. Este verificador valida a cadeia como um monitor faz, então um certificado vencido ou um intermediário ausente faz a verificação falhar na hora, enquanto seu navegador pode disfarçar o problema usando o cache. O verificador de certificado SSL lê o certificado sem validá-lo, e é a ferramenta para esse caso.

Um monitor de uptime deve seguir redirecionamentos?

Siga quando você estiver acompanhando se as pessoas conseguem chegar ao site, porque esse é o caminho que elas fazem. Desative quando estiver acompanhando um endpoint específico e um redirecionamento significar que algo mudou: uma rota de API que começa a responder 302 é um incidente, não um sucesso.

Quais cabeçalhos de resposta importam para o uptime?

Primeiro o código de status, depois tudo o que explique um código ruim: Retry-After em um 429 ou 503, cabeçalhos de cache e de borda que dizem se uma CDN respondeu no lugar da sua origem, e Location em um redirecionamento. Cabeçalhos de segurança como HSTS não afetam o uptime, mas a cadeia que os define muitas vezes afeta.

Acompanhe a cadeia, não só a página inicial

Uma verificação HTTP percorre estes saltos a cada minuto, de cada região que você ativar, e avisa você quando o status no fim deles muda.

comece grátis

mais ferramentas gratuitas: calculadora de SLA de uptime · gerador de expressões cron · calculadora de orçamento de erros · gerador de mensagens de incidente · consulta DNS · verificador de certificado SSL · verificador de vencimento de domínio · verificador de segurança de sites · todas as ferramentas