Enter a URL. You get the status code, every hop of the redirect chain, the response headers, and the thing no reference page will tell you: whether the fault is yours, theirs, or actually the network.

If you got a status code, the network worked

This is the part worth internalising, because it settles most arguments before they start. A status code is evidence. For any number to come back at all, five things had to succeed in order: the name resolved, a TCP connection opened, TLS negotiated, your request was delivered, and a response travelled back.

So when a ticket says "the network is down" and attaches a 502, the network has already been proven to work. Twice: once in each direction. Whatever is wrong happened after your request arrived safely.

The failures that really are the network

They are the ones with no status code at all. If the answer is a connection refused, a timeout, a DNS failure or a TLS handshake that never completed, there is no number because there was never a complete round trip. That is the case worth escalating, and this tool names it explicitly rather than reporting a blank.

One useful distinction inside that group: refused and silent are different answers. A refusal is a reply: something was there and said no, so the path works and nothing is listening on that port. Silence is what a firewall looks like.

The three codes that get blamed on the network most

502 Bad Gateway. A proxy forwarded your request to a backend and got something unusable back. Both machines belong to them. Your request reached the front door and got as far as the second server.

504 Gateway Timeout. The most-blamed and least-deserving. The timeout happened between two of their own servers, long after your request arrived. Your connection was healthy for the entire duration of the wait: that is why a 504 can take thirty seconds and still prove the network is fine.

403 Forbidden. You reached the server, it understood you, and it said no. Unlike a 401 this is not an invitation to authenticate. If a cf-ray header is present, Cloudflare blocked you rather than the origin: a different problem with a different fix, and the tool points that out when it sees one.

The one everybody reads backwards

499 is non-standard, nginx-specific, and almost always misread as a server failure. It means the opposite: the client closed the connection while nginx was still waiting on its backend. The timeout that fired was yours. A server log full of 499s is telling you that callers are giving up, not that the server is erroring.

Reading the redirect chain

Every hop is listed with its own status code, because a browser collapses the whole journey into a single final page and the interesting failures happen in the middle. A URL redirect checker that reports only the destination hides the part you needed, which hop changed the scheme, which one dropped the path, which one is the permanent mistake.

301 and 308 are permanent. Browsers and search engines cache them, sometimes for a very long time, so a 301 published by accident is genuinely hard to withdraw. 302, 303 and 307 are temporary and are not cached the same way. The distinction that catches people is what happens to the method: 301 and 302 have historically been allowed to turn a POST into a GET, and 307 and 308 are the versions that promise not to. If a form submission arrives at the backend as an empty GET, this is usually why.

Two things to check redirect chains for. A loop, where the same URL appears twice, never resolves and ends as a browser error rather than a status code, so there is no number to go and search for. A long chain costs a round trip per hop: http to https to www to the real path is three, each one latency paid before anything renders. This page follows six and then stops, which is about where a chain stops being a redirect and starts being a misconfiguration.

What this HTTP status checker sends

A single GET from Kodura's server, identifying itself as KoduraHTTPCheck. It reads the status and headers and deliberately discards the body. Redirects are followed up to six hops and every hop is re-checked, so a redirect cannot be used to reach a private address. Nothing is stored.