Acompanhar um clique de pesquisa do Safari pelas suas redireções

Os resultados de pesquisa raramente ligam diretamente à página que nomeiam. Um clique pode passar por um redirecionador, uma página intermédia de consentimento ou um serviço de login, e cada salto é um pedido separado que pode falhar sozinho. O separador Network do Safari mantém essa sequência visível, mas apenas se começar a gravar antes do clique. O primeiro URL que falha é a evidência útil, não o endereço mostrado no resultado.

Comece a captura antes do clique

Abra o Web Inspector no separador e mude para Network antes de tocar no resultado da pesquisa. Ative o Preserve Log para que a lista sobreviva à navegação que substitui a página. Limpe as entradas existentes e faça exatamente um clique. Uma captura iniciada depois de a página carregar já perdeu o pedido de que precisa.

Use uma página sem dados privados e mantenha o perfil do navegador e o estado da VPN inalterados durante toda a comparação. Alterar qualquer um deles a meio torna os dois caminhos incomparáveis.

Leia as redireções por ordem

Leia as linhas de cima para baixo e siga os códigos de estado. Um 301 ou 302 cujo campo Location aponta para outro host é um salto, não um destino. O pedido que se segue é uma nova navegação com a sua própria resolução de nomes, negociação TLS e verificações de política. Conte quantos hosts o clique toca antes de o conteúdo chegar.

O Guia do WebKit para o separador Network documenta como se comportam os registos de pedidos e a opção Preserve Log, o que vale a pena ler antes de interpretar uma lista escassa. As linhas em falta costumam significar que a captura começou tarde ou que um service worker respondeu a partir da cache, não que o navegador tenha saltado um salto.

Compare com uma navegação direta

Faça a segunda passagem à página final pretendida, escrita ou colada diretamente, com o mesmo perfil e a mesma rede. Compare as duas listas a partir da primeira linha em que divergem. Se o caminho clicado falha num intermediário que o caminho direto nunca contacta, o problema está nesse intermediário. Se ambos chegam à mesma origin e apenas um recebe uma recusa, o estado da conta ou o detalhe do pedido é a melhor pista.

Mantenha as duas capturas lado a lado com marcas temporais. Uma diferença de tempo não prova causalidade, mas reduz o serviço a investigar a seguir. Anote que host possuía cada linha falhada, porque o mesmo sintoma do navegador tem proprietários diferentes em etapas diferentes. Se a passagem direta também falhar, o caminho do clique não é o fator distintivo.

Nomeie a etapa da falha com precisão

O texto de erro da linha é mais específico do que uma afirmação geral de que o site está bloqueado. Uma falha de resolução de nomes, uma ligação que nunca termina, um erro TLS e um estado HTTP são quatro etapas diferentes com quatro proprietários diferentes. Registe essa etapa por palavras em vez de uma falha genérica, e o alvo da escalada torna-se óbvio.

Ping e traceroute podem acrescentar pistas sobre um host, mas não reproduzem a cadeia de redireções do navegador nem provam que um pedido HTTPS tem sucesso. Um ping bem-sucedido ao host pode até coexistir com um erro TLS no mesmo host. Mantenha o registo do pedido web como prova principal e trate os testes de rede posteriores como detalhe de apoio.

Partilhe o rasto sem expor tokens

Antes de exportar ou colar um rasto, reveja cada URL, cabeçalho e parâmetro de consulta. As cadeias de redireção transportam frequentemente identificadores de sessão, endereços de e-mail, estado de consentimento ou ligações assinadas. Substitua ou reduza esses valores e conserve a origin, o estado e o tempo de que a investigação realmente precisa.

Entregue o primeiro pedido que falha, o salto anterior e o estado da redireção. Esse trio permite à pessoa seguinte reproduzir o seu caminho sem ler um rasto completo nem tocar na conta.