Sökresultat länkar sällan direkt till sidan de namnger. Ett klick kan passera en omdirigerare, en mellanliggande samtyckessida eller en inloggningstjänst, och varje hopp är en separat begäran som kan misslyckas på egen hand. Network-fliken i Safari håller den sekvensen synlig, men bara om du startar inspelningen före klicket. Den första URL som misslyckas är det användbara beviset, inte adressen som visas i resultatet.

Starta inspelningen före klicket

Öppna Web Inspector på fliken och byt till Network innan du rör sökresultatet. Slå på Preserve Log så att listan överlever navigeringen som ersätter sidan. Rensa befintliga poster och gör sedan exakt ett klick. En inspelning som startats efter att sidan laddats har redan tappat begäran du behöver.

Använd en sida utan privata data och håll webbläsarprofilen och VPN-läget oförändrade under hela jämförelsen. Ändrar du något av dem på vägen blir de två vägarna ojämförbara.

Läs omdirigeringarna i ordning

Läs raderna uppifrån och ned och följ statuskoderna. En 301 eller 302 vars Location-fält pekar mot en annan värd är ett hopp, inte en destination. Begäran som följer är en ny navigering med egen namnuppslagning, TLS-handskakning och policykontroller. Räkna hur många värdar klicket berör innan innehållet kommer.

Den WebKits guide till Network-fliken beskriver hur begäransposter och alternativet Preserve Log beter sig, vilket är värt att läsa innan du tolkar en gles lista. Saknade rader betyder oftast att inspelningen började sent eller att en service worker svarade från cachen, inte att webbläsaren hoppade över ett hopp.

Jämför med direkt navigering

Gör den andra omgången mot den avsedda slutsidan, skriven eller inklistrad direkt, under samma profil och nätverk. Jämför de två listorna från den första raden där de skiljer sig. Om den klickade vägen misslyckas hos en mellanhand som den direkta vägen aldrig kontaktar ligger problemet hos den mellanhanden. Om båda når samma origin och bara en får ett avslag är kontotillstånd eller begärandedetalj det bättre spåret.

Håll båda inspelningarna sida vid sida med tidsstämplar. En tidsskillnad är inte bevis för orsakssamband, men den snävar in vilken tjänst som ska undersökas härnäst. Notera vilken värd som ägde varje misslyckad rad, eftersom samma webbläsarsymtom har olika ägare i olika steg. Om den direkta omgången också misslyckas är klickvägen inte det avgörande.

Namnge felsteget exakt

Feltexten i raden är mer specifik än ett allmänt påstående att webbplatsen är blockerad. Ett namnuppslagningsfel, en anslutning som aldrig slutförs, ett TLS-fel och en HTTP-status är fyra olika steg med fyra olika ägare. Skriv ned steget med ord i stället för som ett generiskt fel, och eskaleringsmålet blir tydligt.

StageWhat the row showsWho owns it
Name resolutionNo address, request never startsResolver or local DNS policy
ConnectionAddress known, transport never completesRoute, firewall or upstream reachability
TLSHandshake error or certificate warningInterception, clock or certificate trust
HTTPA status code comes backOrigin, gateway or account policy

Ping och traceroute kan ge ledtrådar om en värd, men de spelar inte upp webbläsarens omdirigeringskedja och bevisar inte att en HTTPS-begäran lyckas. Till och med en lyckad ping mot värden kan samexistera med ett TLS-fel på samma värd. Håll webbegäransposten som huvudbevis och behandla senare nätverkstester som stödjande detalj.

Dela spåret utan att läcka tokens

Innan du exporterar eller klistrar in ett spår, granska varje URL, header och frågeparameter. Omdirigeringskedjor bär ofta sessionsidentifierare, e-postadresser, samtyckesstatus eller signerade länkar. Ersätt eller trimma dessa värden och behåll den origin, status och timing som utredningen faktiskt behöver.

Lämna över den första misslyckade begäran, hoppet före den och omdirigeringsstatusen. Den trion låter nästa person återskapa din väg utan att läsa ett fullständigt spår eller röra kontot.

Relaterade artiklar