Проследете клик в търсенето на Safari през пренасочванията му

Резултатите от търсене рядко водят направо към страницата, която назовават. Кликът може да мине през пренасочващ сървър, междинна страница за съгласие или услуга за вход и всяка стъпка е отделна заявка, която може да се провали самостоятелно. Разделът Network в Safari запазва тази последователност видима, но само ако започнете записа преди клика. Първият неуспешен URL е полезното доказателство, а не адресът, показан в резултата.

Стартирайте записа преди клика

Отворете Web Inspector в раздела и преминете към Network, преди да докоснете резултата от търсенето. Включете Preserve Log, за да оцелее списъкът след навигацията, която заменя страницата. Изчистете съществуващите записи и направете точно един клик. Запис, започнал след зареждането на страницата, вече е загубил заявката, която ви трябва.

Използвайте страница без лични данни и дръжте профила на браузъра и състоянието на VPN непроменени през цялото сравнение. Промяна на някое от тях по средата прави двата пътя несравними.

Четете пренасочванията по ред

Четете редовете отгоре надолу и следете кодовете за състояние. 301 или 302, чието поле Location сочи към друг хост, е стъпка, а не дестинация. Заявката след него е нова навигация със свое търсене на име, TLS ръкостискане и проверки на политиката. Пребройте колко хоста докосва кликът, преди съдържанието да пристигне.

Ръководството на WebKit за раздела Network описва как работят записите на заявките и опцията Preserve Log, което си струва да се прочете, преди да тълкувате разреден списък. Липсващите редове обикновено означават, че записът е започнал късно или service worker е отговорил от кеша, а не че браузърът е пропуснал стъпка.

Сравнете с директна навигация

Направете второто преминаване към предвидената крайна страница, въведена или поставена директно, при същия профил и мрежа. Сравнете двата списъка от първия ред, в който се разминават. Ако пътят през клика се проваля при посредник, който директният път никога не докосва, проблемът е при този посредник. Ако и двата стигат до един и същ origin и само един получава отказ, състоянието на акаунта или детайлът на заявката е по-добрата следа.

Дръжте двата записа един до друг с времеви маркери. Разликата във времето не доказва причинност, но стеснява коя услуга да разследвате след това. Отбележете кой хост притежава всеки неуспешен ред, защото един и същ симптом в браузъра има различни собственици на различните етапи. Ако директното преминаване също се проваля, пътят през клика не е разграничителят.

Назовайте етапа на отказа точно

Текстът на грешката в реда е по-конкретен от общо твърдение, че сайтът е блокиран. Отказ при разрешаване на име, връзка, която никога не завършва, TLS грешка и HTTP статус са четири различни етапа с четири различни собственика. Запишете този етап с думи, вместо като общ отказ, и целта за ескалация става очевидна.

Ping и traceroute могат да добавят улики за даден хост, но не възпроизвеждат веригата от пренасочвания на браузъра и не доказват, че HTTPS заявка успява. Успешен ping до хоста може дори да съществува заедно с TLS грешка на същия хост. Дръжте записа на уеб заявката като основно доказателство и третирайте по-късните мрежови тестове като допълнителен детайл.

Споделете трасето без изтичане на токени

Преди да експортирате или поставите трасе, прегледайте всеки URL, хедър и параметър на заявката. Веригите от пренасочвания често носят идентификатори на сесия, имейл адреси, състояние на съгласие или подписани връзки. Заменете тези стойности или ги отрежете и запазете origin, статуса и времето, които разследването наистина се нуждае.

Предайте първата неуспешна заявка, стъпката преди нея и статуса на пренасочването. Тази тройка позволява на следващия човек да възпроизведе пътя ви, без да чете цяло трасе или да докосва акаунта.