Look up the HTTP status and headers of a URL

The VoriTools server requests the address and reports what came back: the IP that answered, the status code of the final response, and that response's headers. The visitor's browser only receives the result.

The check is a single request, not monitoring: it shows one moment seen from one network. Use it to confirm a redirect, a 404 or a header, and use the timed refresh tool when you need the same address checked again and again.

  1. Type a full address or just a hostname. example.com is requested over http first and follows the site's own redirect onwards; https://example.com/page is used exactly as entered.
  2. Press Check status and headers. The VoriTools server sends the request with a desktop-browser User-Agent and follows up to five redirects.
  3. Read the left table first: the status line the server sent (HTTP/1.1 200 OK), then every header of that final response. The right table repeats the numbers for this check: the IP that answered, the status code, and how many redirects were followed.
  4. If the address cannot be checked, the page names the case instead of one vague sentence: empty input, an address that is not http or https, a private or local address, a host that does not answer, or the 12-second timeout.

What the check sends, what it refuses, and how to read the table

What the check does

The request leaves from the VoriTools server, not from your device, so the answer describes what that network sees. The server identifies itself with a desktop-browser User-Agent; an earlier version sent none at all, and some sites answer 403 to requests that arrive without one.

The page only needs the headers, so the response body is read up to 1 MB and then dropped. A host that stays silent ends the check after 12 seconds, and a connection that cannot be opened ends it after 5.

Reading the response

The first row is the status line, for example HTTP/1.1 200 OK: protocol, code and reason phrase as written by the server. The rows below are the header names and values as received, in the order they arrived, so a header sent twice appears twice.

The right table carries this check's own numbers: the IP address that answered, linked to the IP lookup page, the status code of the final response, and the number of redirects followed. The caption above the headers shows the address that finally answered, which is not always the one that was typed.

Addresses the check refuses

Only http and https are fetched, and only public addresses. Private, reserved and loopback ranges are refused - 127.0.0.1, 10.0.0.1, 192.168.1.1, 169.254.169.254, localhost, and numeric-only hosts such as 0177.0.0.1 - and a redirect that points at one of them is dropped instead of followed.

A name that does not resolve is reported as no response, not as a refused address, because the two call for different fixes.

When the answer is not what a browser shows

Some sites answer 403 or 429 to requests from data-centre addresses even while the page itself is fine. The answer then describes the site’s bot protection, not the page, so it is worth repeating the check before you change anything.

Caches, CDNs and load balancers may answer differently each time, so the same address can return another code a minute later. Check twice before you treat one result as a fact about production.

Recent tools: