Siga un clic de búsqueda de Safari por sus redirecciones

Los resultados de búsqueda rara vez enlazan directamente con la página que nombran. Un clic puede pasar por un redireccionador, una página intermedia de consentimiento o un servicio de inicio de sesión, y cada salto es una petición distinta que puede fallar por sí sola. La pestaña Network de Safari mantiene visible esa secuencia, pero solo si empieza a grabar antes del clic. La primera URL que falla es la evidencia útil, no la dirección que muestra el resultado.

Inicie la captura antes del clic

Abra Web Inspector en la pestaña y cambie a Network antes de tocar el resultado de búsqueda. Active Preserve Log para que la lista sobreviva a la navegación que sustituye la página. Borre las entradas existentes y haga exactamente un clic. Una captura iniciada después de cargar la página ya ha perdido la petición que necesita.

Use una página sin datos privados y mantenga el perfil del navegador y el estado de la VPN sin cambios durante toda la comparación. Cambiar cualquiera de ellos a mitad de camino hace que los dos caminos no sean comparables.

Lea las redirecciones en orden

Lea las filas de arriba abajo y siga los códigos de estado. Un 301 o 302 cuyo campo Location apunta a otro host es un salto, no un destino. La petición que le sigue es una navegación nueva con su propia resolución de nombres, negociación TLS y comprobaciones de política. Cuente cuántos hosts toca el clic antes de que llegue el contenido.

La Guía de WebKit sobre la pestaña Network documenta cómo se comportan los registros de peticiones y la opción Preserve Log, algo que conviene leer antes de interpretar una lista dispersa. Las filas ausentes suelen significar que la captura empezó tarde o que un service worker respondió desde la caché, no que el navegador se saltara un salto.

Compare con una navegación directa

Haga la segunda pasada a la página final prevista, escrita o pegada directamente, con el mismo perfil y la misma red. Compare las dos listas desde la primera fila en que divergen. Si el camino del clic falla en un intermediario que el camino directo nunca contacta, el problema está en ese intermediario. Si ambos llegan al mismo origin y solo uno recibe un rechazo, el estado de la cuenta o el detalle de la petición es la mejor pista.

Mantenga ambas capturas lado a lado con marcas de tiempo. Una diferencia de tiempo no prueba causalidad, pero acota qué servicio investigar después. Anote qué host poseía cada fila fallida, porque el mismo síntoma del navegador tiene propietarios distintos en etapas distintas. Si la pasada directa también falla, el camino del clic no es el factor diferencial.

Nombre la etapa de fallo con precisión

El texto de error de la fila es más concreto que una afirmación general de que el sitio está bloqueado. Un fallo de resolución de nombres, una conexión que nunca se completa, un error TLS y un estado HTTP son cuatro etapas distintas con cuatro propietarios distintos. Registre esa etapa con palabras en lugar de un fallo genérico, y el objetivo de escalado se vuelve evidente.

Ping y traceroute pueden aportar pistas sobre un host, pero no reproducen la cadena de redirecciones del navegador ni demuestran que una petición HTTPS tenga éxito. Un ping correcto al host puede incluso coexistir con un error TLS en el mismo host. Mantenga el registro de peticiones web como evidencia principal y trate las pruebas de red posteriores como detalle de apoyo.

Comparta el rastro sin filtrar tokens

Antes de exportar o pegar un rastro, revise cada URL, cabecera y parámetro de consulta. Las cadenas de redirección suelen llevar identificadores de sesión, direcciones de correo, estado de consentimiento o enlaces firmados. Sustituya o recorte esos valores, y conserve el origin, el estado y el tiempo que la investigación realmente necesita.

Entregue la primera petición que falla, el salto anterior y el estado de redirección. Esa tríada permite a la siguiente persona reproducir su camino sin leer un rastro completo ni tocar la cuenta.