HTTP Redirect Chain Checker
Enter a URL to have the server trace its redirect chain. Review each hop and the final URL, including whether the destination uses HTTPS.
Enter a URL to have the server trace its redirect chain. Review each hop and the final URL, including whether the destination uses HTTPS.
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.
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.
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.
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.