Tracciare un clic di ricerca Safari attraverso i suoi reindirizzamenti
Un clic di ricerca può passare per un reindirizzatore, una pagina di consenso o un accesso prima della pagina. Confrontate la catena cliccata con una visita diretta e nominate la fase che fallisce.
I risultati di ricerca raramente collegano direttamente alla pagina che nominano. Un clic può passare per un reindirizzatore, una pagina intermedia di consenso o un servizio di accesso, e ogni salto è una richiesta separata che può fallire da sola. La scheda Network di Safari mantiene visibile quella sequenza, ma solo se avviate la registrazione prima del clic. Il primo URL che fallisce è la prova utile, non l'indirizzo mostrato nel risultato.
Avviare la cattura prima del clic
Aprire Web Inspector nella scheda e passare a Network prima di toccare il risultato di ricerca. Attivate Preserve Log perché l'elenco sopravviva alla navigazione che sostituisce la pagina. Cancellate le voci esistenti, poi fate esattamente un clic. Una cattura avviata dopo il caricamento della pagina ha già perso la richiesta che vi serve.
Usate una pagina senza dati privati e mantenete invariati il profilo del browser e lo stato della VPN per tutta la durata del confronto. Cambiarne uno a metà strada rende i due percorsi non confrontabili.
Leggere i reindirizzamenti in ordine
Leggete le righe dall'alto in basso e seguite i codici di stato. Un 301 o 302 il cui campo Location punta a un altro host è un salto, non una destinazione. La richiesta che segue è una nuova navigazione con la propria risoluzione dei nomi, stretta di mano TLS e controlli di policy. Contate quanti host tocca il clic prima che arrivi il contenuto.
Il Guida di WebKit alla scheda Network documenta come si comportano i record delle richieste e l'opzione Preserve Log, cosa che vale la pena leggere prima di interpretare un elenco rado. Le righe mancanti di solito significano che la cattura è iniziata tardi o che un service worker ha risposto dalla cache, non che il browser abbia saltato un salto.
Confrontare con una navigazione diretta
Fate la seconda passata verso la pagina finale prevista, digitata o incollata direttamente, con lo stesso profilo e la stessa rete. Confrontate i due elenchi dalla prima riga in cui divergono. Se il percorso cliccato fallisce su un intermediario che il percorso diretto non contatta mai, il problema sta su quell'intermediario. Se entrambi raggiungono lo stesso origin e solo uno riceve un rifiuto, lo stato dell'account o il dettaglio della richiesta è la pista migliore.
Tenete le due catture affiancate con marche temporali. Una differenza di tempo non prova la causalità, ma restringe quale servizio indagare dopo. Annotate quale host possedeva ogni riga fallita, perché lo stesso sintomo del browser ha proprietari diversi in fasi diverse. Se anche la passata diretta fallisce, il percorso del clic non è il fattore discriminante.
Nominare con precisione la fase di errore
Il testo dell'errore della riga è più specifico di un'affermazione generica che il sito sia bloccato. Un errore di risoluzione dei nomi, una connessione che non si completa mai, un errore TLS e uno stato HTTP sono quattro fasi diverse con quattro proprietari diversi. Annotate quella fase a parole invece che come errore generico, e l'obiettivo dell'escalation diventa evidente.
| Stage | What the row shows | Who owns it |
|---|---|---|
| Name resolution | No address, request never starts | Resolver or local DNS policy |
| Connection | Address known, transport never completes | Route, firewall or upstream reachability |
| TLS | Handshake error or certificate warning | Interception, clock or certificate trust |
| HTTP | A status code comes back | Origin, gateway or account policy |
Ping e traceroute possono aggiungere indizi su un host, ma non riproducono la catena di reindirizzamenti del browser né provano che una richiesta HTTPS riesca. Un ping riuscito all'host può perfino convivere con un errore TLS sullo stesso host. Mantenete il record della richiesta web come prova principale e trattate i test di rete successivi come dettaglio di supporto.
Condividere la traccia senza far trapelare token
Prima di esportare o incollare una traccia, rivedete ogni URL, intestazione e parametro di query. Le catene di reindirizzamento spesso trasportano identificatori di sessione, indirizzi email, stato di consenso o link firmati. Sostituite o riducete quei valori, e conservate l'origin, lo stato e la tempistica di cui l'indagine ha davvero bisogno.
Consegnate la prima richiesta che fallisce, il salto precedente e lo stato del reindirizzamento. Quella terna permette alla persona successiva di riprodurre il vostro percorso senza leggere una traccia completa né toccare l'account.