Search results rarely link straight to the page they name. A click can pass a redirector, a consent interstitial, or a sign-in service, and each hop is a separate request that can fail on its own. Safari's Network tab keeps that sequence visible, but only if you start recording before the click. The first failing URL is the useful evidence, not the address shown in the result.

Start the Capture Before the Click

Open Web Inspector on the tab and switch to Network before you touch the search result. Enable Preserve Log so the list survives the navigation that replaces the page. Clear existing entries, then make exactly one click. A capture started after the page loads has already lost the request you need.

Use a page with no private data, and keep the browser profile and VPN state unchanged for the whole comparison. Changing either mid-run makes the two paths incomparable.

Read Redirects in Order

Read the rows top to bottom and follow the status codes. A 301 or 302 whose Location points to another host is a hop, not a destination. The request that follows it is a new navigation with its own name lookup, TLS handshake and policy checks. Count how many hosts the click touches before the content arrives.

The WebKit Network-tab guide documents how request records and the Preserve Log option behave, which is worth reading before interpreting a sparse list. Missing rows usually mean the capture started late or a service worker answered from cache, not that the browser skipped a hop.

Compare Against a Direct Navigation

Run the second pass to the intended final page, typed or pasted directly, under the same profile and network. Compare the two lists from the first row where they diverge. If the clicked path fails at an intermediary the direct path never contacts, the problem sits at that intermediary. If both reach the same origin and only one gets a refusal, account state or request detail is the better lead.

Keep both captures side by side with timestamps. A difference in time is not proof of causation, but it narrows which service to investigate next. Note which host owned each failing row, because the same browser symptom has different owners at different stages. If the direct pass also fails, the click path is not the differentiator.

Name the Failure Stage Precisely

The row's error text is more specific than a general claim that the site is blocked. A name-resolution failure, a connection that never completes, a TLS error and an HTTP status are four different stages with four different owners. Record that stage in words rather than as a generic failure, and the escalation target becomes obvious.

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 and traceroute can add clues about a host, but they do not replay the browser's redirect chain or prove that an HTTPS request succeeds. A successful ping to the host can even coexist with a TLS failure on the same host. Keep the web-request record as the primary evidence and treat later network tests as supporting detail.

Share the Trace Without Leaking Tokens

Before exporting or pasting a trace, review every URL, header and query parameter. Redirect chains often carry session identifiers, email addresses, consent state or signed links. Replace those values or trim them, and keep the origin, status and timing that the investigation actually needs.

Hand over the first failing request, the hop before it and the redirect status. That trio lets the next person reproduce your path without reading a full trace or touching the account.

Nuŋlɔɖi siwo ku ɖe eŋu