Wyniki wyszukiwania rzadko prowadzą prosto do strony, którą nazywają. Kliknięcie może przejść przez serwer przekierowujący, pośrednią stronę zgody lub usługę logowania, a każdy skok to osobne żądanie, które może zawieść samo. Karta Network w Safari utrzymuje tę sekwencję widoczną, ale tylko jeśli rozpoczniesz nagranie przed kliknięciem. Pierwszy nieudany URL jest użytecznym dowodem, a nie adresem pokazanym w wyniku.

Zacznij nagranie przed kliknięciem

Otwórz Web Inspector na karcie i przełącz na Network, zanim dotkniesz wyniku wyszukiwania. Włącz Preserve Log, aby lista przetrwała nawigację, która zastępuje stronę. Wyczyść istniejące wpisy, a następnie wykonaj dokładnie jedno kliknięcie. Nagranie rozpoczęte po wczytaniu strony utraciło już potrzebne żądanie.

Użyj strony bez prywatnych danych i przez całe porównanie utrzymuj profil przeglądarki oraz stan VPN bez zmian. Zmiana któregokolwiek z nich w połowie czyni obie ścieżki nieporównywalnymi.

Czytaj przekierowania po kolei

Czytaj wiersze od góry do dołu i śledź kody statusu. 301 lub 302, którego pole Location wskazuje inny host, to skok, a nie cel. Żądanie, które następuje, to nowa nawigacja z własnym rozwiązywaniem nazw, uściskiem TLS i sprawdzeniami zasad. Policz, ilu hostów dotyka kliknięcie, zanim dotrze treść.

Przewodnik WebKit po karcie Network opisuje, jak zachowują się zapisy żądań i opcja Preserve Log, co warto przeczytać przed interpretacją skąpej listy. Brakujące wiersze zwykle oznaczają, że nagranie zaczęło się późno albo service worker odpowiedział z pamięci podręcznej, a nie że przeglądarka pominęła skok.

Porównaj z bezpośrednią nawigacją

Wykonaj drugie przejście do zamierzonej strony końcowej, wpisanej lub wklejonej bezpośrednio, przy tym samym profilu i sieci. Porównaj obie listy od pierwszego wiersza, w którym się rozchodzą. Jeśli kliknięta ścieżka zawodzi na pośredniku, z którym ścieżka bezpośrednia nigdy się nie kontaktuje, problem leży na tym pośredniku. Jeśli obie docierają do tego samego origin i tylko jedna otrzymuje odmowę, stan konta lub szczegół żądania jest lepszą wskazówką.

Trzymaj oba nagrania obok siebie ze znacznikami czasu. Różnica czasu nie dowodzi przyczynowości, ale zawęża, którą usługę badać dalej. Zanotuj, do którego hosta należał każdy nieudany wiersz, ponieważ ten sam objaw przeglądarki ma różnych właścicieli na różnych etapach. Jeśli bezpośrednie przejście też zawodzi, ścieżka kliknięcia nie jest wyróżnikiem.

Nazwij etap awarii precyzyjnie

Tekst błędu w wierszu jest bardziej konkretny niż ogólne twierdzenie, że witryna jest zablokowana. Niepowodzenie rozwiązywania nazw, połączenie, które nigdy się nie kończy, błąd TLS i status HTTP to cztery różne etapy z czterema różnymi właścicielami. Zapisz ten etap słowami, a nie jako ogólną awarię, a cel eskalacji stanie się oczywisty.

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 i traceroute mogą dodać wskazówki o hoście, ale nie odtwarzają łańcucha przekierowań przeglądarki ani nie dowodzą, że żądanie HTTPS się udaje. Nawet udany ping do hosta może współistnieć z błędem TLS na tym samym hoście. Trzymaj zapis żądania sieciowego jako główny dowód, a późniejsze testy sieci traktuj jako szczegół pomocniczy.

Udostępnij ślad bez wycieku tokenów

Przed wyeksportowaniem lub wklejeniem śladu przejrzyj każdy URL, nagłówek i parametr zapytania. Łańcuchy przekierowań często niosą identyfikatory sesji, adresy e-mail, stan zgody lub podpisane linki. Zastąp lub skróć te wartości i zachowaj origin, status oraz czas, których dochodzenie naprawdę potrzebuje.

Przekaż pierwsze nieudane żądanie, skok przed nim i status przekierowania. Ta trójka pozwala następnej osobie odtworzyć twoją ścieżkę bez czytania pełnego śladu i bez dotykania konta.

Powiązane artykuły