Seguir un clic de busca de Safari polas súas redireccións

Os resultados de busca raramente ligan directamente coa páxina que nomean. Un clic pode pasar por un redireccionador, unha páxina intermedia de consentimento ou un servizo de inicio de sesión, e cada salto é unha petición distinta que pode fallar por si soa. A lapela Network de Safari mantén visible esa secuencia, pero só se comeza a gravar antes do clic. O primeiro URL que falla é a evidencia útil, non o enderezo que mostra o resultado.

Inicie a captura antes do clic

Abra Web Inspector na lapela e cambie a Network antes de tocar o resultado da busca. Active Preserve Log para que a lista sobreviva á navegación que substitúe a páxina. Borre as entradas existentes e faga exactamente un clic. Unha captura iniciada despois de cargar a páxina xa perdeu a petición que necesita.

Use unha páxina sen datos privados e manteña o perfil do navegador e o estado da VPN sen cambios durante toda a comparación. Cambiar calquera deles a metade de camiño fai que os dous camiños non sexan comparables.

Lea as redireccións en orde

Lea as filas de arriba abaixo e siga os códigos de estado. Un 301 ou 302 cuxo campo Location apunta a outro host é un salto, non un destino. A petición que segue é unha navegación nova coa súa propia resolución de nomes, negociación TLS e comprobacións de política. Conte cantos hosts toca o clic antes de que chegue o contido.

A Guía de WebKit sobre a lapela Network documenta como se comportan os rexistros de peticións e a opción Preserve Log, algo que paga a pena ler antes de interpretar unha lista escasa. As filas ausentes adoitan significar que a captura comezou tarde ou que un service worker respondeu desde a caché, non que o navegador saltase un salto.

Compare cunha navegación directa

Faga a segunda pasada á páxina final prevista, escrita ou pegada directamente, co mesmo perfil e a mesma rede. Compare as dúas listas desde a primeira fila na que diverxen. Se o camiño do clic falla nun intermediario que o camiño directo nunca contacta, o problema está nese intermediario. Se ambos chegan á mesma origin e só un recibe un rexeitamento, o estado da conta ou o detalle da petición é a mellor pista.

Manteña as dúas capturas lado a lado con marcas de tempo. Unha diferenza de tempo non proba causalidade, pero reduce que servizo investigar despois. Anote que host posuía cada fila fallida, porque o mesmo síntoma do navegador ten propietarios distintos en etapas distintas. Se a pasada directa tamén falla, o camiño do clic non é o factor diferenciador.

Nomee a etapa do fallo con precisión

O texto de erro da fila é máis concreto que unha afirmación xeral de que o sitio está bloqueado. Un fallo de resolución de nomes, unha conexión que nunca se completa, un erro TLS e un estado HTTP son catro etapas distintas con catro propietarios distintos. Rexistre esa etapa con palabras en lugar dun fallo xenérico, e o obxectivo de escalado faise evidente.

Ping e traceroute poden engadir pistas sobre un host, pero non reproducen a cadea de redireccións do navegador nin proban que unha petición HTTPS teña éxito. Un ping correcto ao host pode mesmo coexistir cun erro TLS no mesmo host. Manteña o rexistro de peticións web como evidencia principal e trate as probas de rede posteriores como detalle de apoio.

Comparta o rastro sen filtrar tokens

Antes de exportar ou pegar un rastro, revise cada URL, cabeceira e parámetro de consulta. As cadeas de redirección adoitan levar identificadores de sesión, enderezos de correo, estado de consentimento ou ligazóns asinadas. Substitúa ou recorte eses valores, e conserve a origin, o estado e o tempo que a investigación realmente necesita.

Entregue a primeira petición que falla, o salto anterior e o estado de redirección. Esa tríade permite á persoa seguinte reproducir o seu camiño sen ler un rastro completo nin tocar a conta.