HTTP Status Checker – Complete Guide to Status Codes, Headers and Redirects

A page "just doesn't work" and you need the facts: does the server answer at all, with which status code, after how many redirects, and with which headers? Browsers hide most of this behind a rendered page, cached responses and silently followed redirects. Developers reach for curl -I, but that is not always at hand, and it shows the view from your own network.

The HTTP Status checker on NetTools.tech requests a URL from our server, follows redirects step by step and shows the status code of each hop, the final status, the total time, the IP address that answered and the final response headers. Use it when you migrate a site, debug a 5xx error, verify an HTTP to HTTPS redirect, or check what caching and security headers a server really sends.

What is an HTTP status check?

In simple terms

Every time a browser asks a web server for a page, the server answers with a short status line before the content, such as 200 OK or 404 Not Found. A status check sends such a request and reports that answer, together with the extra information (headers) the server sends along, without rendering the page.

Technical background

HTTP semantics are defined in RFC 9110. A response starts with a status code, a three-digit integer whose first digit defines the class:

Redirects carry a Location header with the next URL. 301 and 308 are permanent, 302 and 307 temporary; 307 and 308 additionally require the client to keep the request method. 303 See Other tells the client to fetch the target with GET, which is common after form submissions.

Headers are name/value pairs that describe the response: Content-Type, Content-Length, Cache-Control, Server, Strict-Transport-Security, Content-Security-Policy, X-Robots-Tag and many more. Header names are case-insensitive, and the checker shows them in lower case.

Why use an HTTP status checker?

• Confirm what the server really returns. A page can look fine in your browser because of a cached copy while the server now answers 500.
• Find soft errors. A "not found" page that returns 200 confuses search engines; a maintenance page that returns 200 instead of 503 does too.
• Verify redirects after a migration. You see whether http:// goes to https:// and whether old URLs use 301 or a temporary 302.
• Inspect headers. Check Cache-Control, Content-Type, HSTS, CSP or X-Robots-Tag without opening developer tools.
• Get an outside view. The request comes from the NetTools.tech server, not from your network, so local proxies, VPNs and browser extensions are out of the picture.

Who should use it?

• Web developers and DevOps engineers debugging deployments, reverse proxies and CDNs.
• System administrators checking that a service behind a load balancer answers correctly.
• SEO specialists verifying status codes and redirects of important URLs.
• Support staff who need a quick, shareable fact ("the server returns 502") before escalating.

How the HTTP status check works

When you submit a URL, the NetTools.tech server validates it and then makes the request itself:

1. Validation. Only http and https URLs up to 2,048 characters are accepted. If you leave out the scheme, https:// is added. URLs with embedded credentials (user:password@) are refused.
2. Destination guard. The hostname is resolved once. If any of its addresses is private, loopback, link-local or reserved, the request is refused. Only ports 80, 443, 8080 and 8443 are allowed. The connection then goes to exactly the address that was checked, so a second DNS answer cannot redirect it to an internal system.
3. Request. The server sends a GET with the identified user agent Mozilla/5.0 (compatible; NetToolsBot/1.0; +https://nettools.tech/about), Accept-Encoding: gzip, deflate, br and no cookies. Each request has a 10-second limit, and at most the first 32 KB of the body are read; the body itself is not shown.
4. Redirects. Redirects are not followed automatically. For 301, 302, 303, 307 and 308 with a Location header, the server resolves the next URL, runs the destination guard again and requests it, up to 10 redirects. A URL that was already visited ends the chain.
5. Result. You get every hop, the final status, the total time, the IP address of the server that sent the final response and up to 60 final response headers, with Set-Cookie and Cookie removed.

The whole operation is limited to about 25 seconds, and the NetTools.tech API applies per-client rate limits. TLS certificates are verified like in a normal client, so an invalid certificate ends the hop with an error instead of a status code. To inspect the certificate itself, use the SSL Certificate Checker.

How to use the NetTools.tech HTTP Status checker

1. Open HTTP Status.
2. Enter the full URL in the URL field, for example https://example.com/pricing. Include http:// explicitly if you want to test the plain-HTTP entry point and its redirect to HTTPS.
3. Press Run HTTP Status, or click the example chip below the form to fill in a sample URL.
4. Read the hop table, then the summary (final status, total time, server IP).
5. Expand response headers to see the headers of the final response.
6. Use Copy to copy the result as text, for a ticket or a chat with your hosting provider.

The same check is available in the terminal as /httpstatus https://example.com (aliases /http and /curl).

Understanding the results

The reason text next to a code is the standard phrase (for example "Moved Permanently"). For codes without a standard phrase in our list, the checker shows the class, such as "Client error" or "Server error".

Example: an HTTP URL that redirects twice

Checking http://example.com/docs might produce:

Hop  URL                             Status                   Time
1    http://example.com/docs         301 Moved Permanently    38 ms
2    https://example.com/docs        301 Moved Permanently    71 ms
3    https://www.example.com/docs/   200 OK                   124 ms

Final status   200 OK
Total time     241 ms
Server IP      203.0.113.10

Reading it: the site redirects HTTP to HTTPS (hop 1), then adds www and a trailing slash (hop 2). Both are permanent, which is right, but links could point straight at https://www.example.com/docs/ to save two round trips. The response headers of hop 3 would then show whether the page is cached (cache-control) and whether HSTS is set.

Common use cases

• Post-deployment smoke test: check that the home page and key endpoints return 200, not 502 from a proxy that lost its upstream.
• Migration checks: verify that old URLs return 301 to the right new URL instead of 302 or 404.
• Maintenance windows: confirm the maintenance page returns 503 (ideally with Retry-After) rather than 200.
• Header audits: look up cache-control, content-security-policy or strict-transport-security on a production URL.
• Escalations: give the hosting provider or CDN support the exact status, IP and time the server returned.

Troubleshooting

The result shows "No response" with a DNS error

The domain could not be resolved from our server. Check the record with DNS Lookup, and if you changed DNS recently, see whether resolvers already have the new answer with DNS Propagation.

"Connection failed (ECONNREFUSED)" or a timeout

The host exists, but nothing accepted the connection on that port, or a firewall dropped it. Test the port with Port Check and the path with Traceroute. If the site works for you, the server may block our address range or only allow certain countries.

"TLS/certificate error"

The certificate is expired, does not match the hostname, or the chain is incomplete. Clients that verify certificates fail the same way. Run the SSL Certificate Checker for details.

Final status is 301 or 302

The chain ended on a redirect. Either it hit the limit of 10 redirects, or the next URL had already been visited (a loop), or the target was refused by the destination guard. The Redirect Checker reports loops and refused hops explicitly.

403 or 429 although the page opens in a browser

Bot protection, WAF rules or rate limits treat our identified bot request differently from a browser with cookies. That is a property of the site, not an outage. The Redirect Checker lets you repeat the request with a desktop or mobile browser user agent.

500, 502, 503 or 504

500 is an application error, 502 and 504 usually mean a reverse proxy or CDN could not get a valid or timely answer from the origin, and 503 means the service is unavailable or overloaded. Check the application and proxy logs at the time of the check.

Common mistakes

• Testing only https://. Many visitors and old links still arrive on http://; test that entry point too.
• Treating 3xx as an error. A redirect is a normal answer; what matters is where the chain ends and whether permanent moves use 301 or 308.
• Ignoring soft 404s. An error page that returns 200 looks "up" to every monitor; check that missing pages return 404 or 410.
• Assuming one check is global. The result shows one request from one location at one moment.
• Comparing headers with a logged-in browser. Cookies and sessions change responses; our request has neither.

Limitations

• The request comes from a single NetTools.tech server. Geo-routing, CDNs and country blocks can make other regions see something else.
• Only ports 80, 443, 8080 and 8443 and public addresses can be checked; internal or staging systems on private networks cannot.
• Only HTTP redirects are followed. Meta refresh and JavaScript redirects happen in the browser and are not visible here.
• When a hostname has both IPv4 and IPv6 addresses, the IPv4 address is used, so IPv6-specific problems are not tested.
• Only the first 32 KB of a body are read, and the body is not shown. Use the Meta Tag Analyzer to look at page HTML.
• The method is always GET with a bot user agent; you cannot set custom headers, cookies or methods.

Security & privacy

The URL you enter is sent to the NetTools.tech server, which makes the request and returns the result to your browser. The URL and the response are not stored. The target website sees a request from our server's IP address with the NetToolsBot user agent, not from your device.

Do not put secrets into URLs you check: query parameters such as API keys, session tokens or password reset links are sent to the target server and may end up in its logs. URLs with embedded credentials are refused anyway. Cookie headers are stripped from the displayed output.

Related tools

• Redirect Checker – every hop with Location headers, loop detection and a choice of user agent (guide).
• Is It Down – a yes/no availability verdict for a domain (guide).
• SSL Certificate Checker – certificate validity, chain and expiry (guide).
• User Agent – what your own browser sends (guide).
• Meta Tag Analyzer – title, description, canonical and robots tags of the final page (guide).

Summary

The HTTP Status checker shows what a web server answers to a plain request from the NetTools.tech server: each redirect hop, the final status code, timing, the responding IP and the final headers. It is a quick way to separate real server errors from browser caching, local network problems and bot-specific behavior. For deeper redirect analysis, certificate details or page content, continue with the related tools.