How to trace a redirect chain

The tracer sends the URL you enter to the VoriTools server, which requests it and follows every redirect until the chain ends, eight hops at most. Each hop is listed with its status, the URL that was requested, the Location value when the server sent one, the response time, the remote address, the Server header and the content type.

The request is a plain GET and the server stops reading once the response headers are complete, so no page body is downloaded or shown. The answer comes from one machine: a CDN or a geo-DNS front end can send the same URL somewhere else, so compare with a second vantage point before you change a production setting.

  1. Paste a public HTTP or HTTPS URL. Only the standard ports 80 and 443 are reached, so a URL such as https://example.com:8080/ is refused before any request is made.
  2. Choose the user agent the check should use: a desktop browser, a mobile browser or the VoriTools diagnostic bot.
  3. Press Trace redirects and read the hop list. A 301, 302, 303, 307 or 308 that carries a Location adds another hop; any other response ends the chain.
  4. Read the summary: the number of redirects, the total time and whether the final URL uses HTTPS. When the final URL is still http, the address bar would stay on an insecure scheme.

Reading each hop, and what the trace cannot tell you

How the chain is followed

Every Location value is resolved against the URL of the hop that returned it, so relative targets such as /login or ?lang=en are followed the way a browser resolves them. The next target is resolved and checked against the public-address rule again before it is requested.

Private, reserved and local addresses are refused, as are URLs that carry credentials, and a redirect pointing at a non-standard port stops the trace with a message. A chain that repeats a URL is reported as a loop, and a chain longer than eight hops stops at the limit.

Reading the hop list

The status and its reason phrase come from the response line, and the Location value is shown as the server sent it, before resolution. The time is measured until the response starts arriving, and the address is the IP the connection was pinned to, the same value used for the request, not a second lookup.

The Server header and the content type are shown when the endpoint sends them. A final 200 does not mean the page is healthy; it means the last request answered without asking for another redirect.

What the trace cannot tell you

The report shows response headers, not page content, and it is a single snapshot from one server: caches, geo-DNS and split front ends can answer differently from your network. The probe also runs from a data-centre address and speaks HTTP/1.1, so a site that filters datacentre traffic or browser-impersonating clients can answer 403, 405 or 501 while the same URL opens in your browser; try another user-agent preset before you conclude that the URL is broken.

Recent tools: