Urmăriți un clic de căutare Safari prin redirecționările sale

Rezultatele căutării rareori trimit direct la pagina pe care o numesc. Un clic poate trece printr-un redirector, o pagină intermediară de consimțământ sau un serviciu de autentificare, iar fiecare salt este o cerere separată care poate eșua singură. Filonul Network din Safari ține acea secvență vizibilă, dar numai dacă începeți înregistrarea înainte de clic. Primul URL care eșuează este dovada utilă, nu adresa afișată în rezultat.

Începeți înregistrarea înainte de clic

Deschideți Web Inspector în filă și treceți la Network înainte de a atinge rezultatul căutării. Activați Preserve Log pentru ca lista să supraviețuiască navigării care înlocuiește pagina. Ștergeți intrările existente și apoi faceți exact un clic. O înregistrare începută după încărcarea paginii a pierdut deja cererea de care aveți nevoie.

Folosiți o pagină fără date private și păstrați profilul browserului și starea VPN neschimbate pe toată durata comparației. Schimbarea oricăruia dintre ele la mijloc face cele două căi incomparabile.

Citiți redirecționările în ordine

Citiți rândurile de sus în jos și urmăriți codurile de stare. Un 301 sau 302 al cărui câmp Location indică alt host este un salt, nu o destinație. Cererea care urmează este o navigare nouă cu propria rezolvare a numelor, strângere de mână TLS și verificări de politică. Numărați câte gazde atinge clicul înainte ca conținutul să ajungă.

Ghidul WebKit pentru filonul Network documentează cum se comportă înregistrările cererilor și opțiunea Preserve Log, ceea ce merită citit înainte de a interpreta o listă rară. Rândurile lipsă înseamnă de obicei că înregistrarea a început târziu sau că un service worker a răspuns din cache, nu că browserul a sărit un salt.

Comparați cu o navigare directă

Faceți a doua trecere spre pagina finală dorită, tastată sau lipită direct, sub același profil și aceeași rețea. Comparați cele două liste de la primul rând la care diverg. Dacă traseul clicat eșuează la un intermediar pe care traseul direct nu îl contactează niciodată, problema este la acel intermediar. Dacă ambele ajung la aceeași origin și doar unul primește un refuz, starea contului sau detaliul cererii este indiciul mai bun.

Țineți ambele înregistrări alături, cu marcaje de timp. O diferență de timp nu dovedește cauzalitatea, dar restrânge ce serviciu să investigați în continuare. Notați ce gazdă deținea fiecare rând eșuat, pentru că același simptom al browserului are proprietari diferiți la etape diferite. Dacă și trecerea directă eșuează, traseul clicat nu este factorul distinctiv.

Numiți etapa eșecului cu precizie

Textul erorii din rând este mai specific decât o afirmație generală că site-ul este blocat. O eroare de rezolvare a numelui, o conexiune care nu se finalizează niciodată, o eroare TLS și un status HTTP sunt patru etape diferite cu patru proprietari diferiți. Notați acea etapă în cuvinte, nu ca eșec generic, iar ținta escaladării devine evidentă.

Ping și traceroute pot adăuga indicii despre o gazdă, dar nu reproduc lanțul de redirecționări al browserului și nu dovedesc că o cerere HTTPS reușește. Chiar un ping reușit către gazdă poate coexista cu o eroare TLS pe aceeași gazdă. Păstrați înregistrarea cererii web ca dovadă principală și tratați testele de rețea ulterioare ca detaliu de sprijin.

Partajați urma fără a scurge tokenuri

Înainte de a exporta sau lipi o urmă, revizuiți fiecare URL, antet și parametru de interogare. Lanțurile de redirecționare poartă adesea identificatori de sesiune, adrese de e-mail, starea consimțământului sau linkuri semnate. Înlocuiți sau scurtați acele valori și păstrați origin, statusul și momentul de care ancheta are cu adevărat nevoie.

Predați prima cerere care eșuează, saltul dinaintea ei și statusul redirecționării. Acel trio îi permite persoanei următoare să reproducă traseul dumneavoastră fără a citi o urmă completă sau a atinge contul.