HTTP Status Code and Header Checker Guide: Diagnose Redirects, CORS, Caching, and SSL Problems

Overview

When a page or API request fails, the visible symptom is often incomplete. A browser may show a generic error while the response contains the useful diagnosis: a redirect to an unexpected host, a missing CORS header, a cached error, an expired cookie, or a server-side failure. Checking the HTTP status code and response headers exposes that information.

Start with the exact URL, including its scheme, host, path, and query string. Then test the endpoint in more than one way. Browser developer tools show the request as the browser experienced it, while curl provides a scriptable command-line view. An online HTTP header checker can be useful for a quick public check, but avoid submitting private URLs, credentials, session identifiers, or sensitive response data to a third-party service.

Use this basic sequence:

1. Record the URL and the expected result.
2. Check the first response status before following redirects.
3. Inspect the complete redirect chain, if one exists.
4. Review response headers for CORS, caching, cookies, compression, and server behavior.
5. Repeat the test from the relevant browser, environment, or network.
6. Compare the evidence with application, proxy, CDN, and web-server logs.

Checklist by scenario

Checking a status code and headers with curl

For a normal response, use:

curl -i https://example.com/path

The -i option includes response headers with the body. To follow redirects and show each response, use:

curl -i -L https://example.com/path

To inspect connection details, including TLS negotiation and request routing, use verbose mode:

curl -v https://example.com/path

curl -I requests headers with the HTTP HEAD method. It can be convenient, but some applications handle HEAD differently from GET. If the result looks inconsistent with the browser, compare it with curl -i rather than treating the two requests as identical.

Investigating redirects

A website redirect checker should reveal both the status and destination at each step. Look for unexpected changes between HTTP and HTTPS, different hostnames, added or removed subdomains, repeated redirects, and a final status that is not successful. The Location header identifies the next destination for most redirect responses.

Test the canonical URL, the non-canonical variant, and a representative deep link. A redirect that works for the home page may fail for assets or application routes. If a redirect loop appears, compare the scheme and host seen by the origin server with those presented by the proxy or load balancer. Forwarded protocol and host settings often matter when an application is behind another service.

Troubleshooting CORS

CORS troubleshooting must be performed from the browser context that makes the cross-origin request. Look for Access-Control-Allow-Origin and, when applicable, Access-Control-Allow-Credentials. For a preflighted request, inspect the OPTIONS request and verify that the response permits the intended method and request headers through Access-Control-Allow-Methods and Access-Control-Allow-Headers.

A command-line request can confirm what a server returns, but it does not reproduce every browser enforcement rule. Include an Origin header when testing a particular cross-origin case:

curl -i -H "Origin: https://app.example.com" https://api.example.com/data

Also check whether a CDN or intermediary varies its response by origin. A missing or incorrect Vary: Origin strategy can make behavior appear inconsistent between clients.

Checking caching and cookies

Review Cache-Control, Expires, ETag, and Last-Modified to understand whether a response can be reused or revalidated. A stale page may not indicate that the origin is currently returning bad content. Compare a normal request with a request that sends a revalidation condition, and check whether a cache layer adds its own diagnostic headers.

For authentication or session issues, inspect Set-Cookie attributes such as Secure, HttpOnly, SameSite, domain, path, and expiration. Never paste live cookie values or authorization headers into a public checker. If a token is involved, use a local workflow; a JWT decoder can help inspect claims, but decoding is not the same as validating a token or proving that it is safe to use.

Checking compression and content type

Confirm that Content-Type matches the returned content. An API returning an HTML error page with a successful-looking transport response can confuse a client expecting JSON. Review Content-Encoding and Content-Length when diagnosing transfer or compression problems. Use browser developer tools to compare the transferred size with the decoded response and to see whether an intermediary changed the representation.

Investigating TLS and connection failures

If no HTTP status is available, the failure may occur before an HTTP response is produced. A certificate mismatch, unsupported protocol, DNS problem, refused connection, or proxy failure can prevent the request from reaching the application. Use browser security details and curl -v to separate DNS, TCP, TLS, and HTTP stages. Test the exact hostname users access; a certificate can be valid for one hostname but not another.

What to double-check

• Request method: A GET, HEAD, and OPTIONS request may produce different responses.
• Headers sent by the client: Add an Accept, Origin, or authorization header only when it reflects the real failing request.
• Redirect history: Save every hop, not just the final status.
• Environment: Compare local development, staging, production, and the affected network or region when relevant.
• Cache state: Test with a fresh browser profile or controlled cache conditions before changing server configuration.
• Body and headers together: A status code alone does not confirm that the returned document or API payload is correct.
• Logs and timestamps: Match the request time with origin, reverse-proxy, CDN, and application logs.

For structured API output, a JSON formatter and validator can make the response body easier to inspect after the transport problem is understood. Keep transport diagnosis separate from payload formatting: valid JSON does not mean the request was authorized, cached correctly, or routed to the intended service.

Common mistakes

Checking only the final response: Following redirects can hide the response that caused a routing or HTTPS problem. Capture the full chain first.

Assuming a browser error is a server status: Network and TLS failures may have no HTTP status at all. Establish whether the request reached the HTTP layer.

Using an online checker for private data: Public tools are appropriate only for URLs and headers you are permitted to disclose. Use local commands for internal systems and authenticated endpoints.

Testing CORS outside the browser: curl can show headers, but browser CORS enforcement, credentials, preflight behavior, and JavaScript errors still need browser developer tools.

Changing several settings at once: Alter one redirect, cache, proxy, or CORS rule at a time, then repeat the same request. This preserves a useful before-and-after comparison.

Treating a decoded token as verified: Reading JWT claims does not verify its signature, issuer, audience, expiration, or permissions. Handle authentication data carefully; related token inspection guidance is available in the JWT decoder and debugging guide.

When to revisit

Keep this checklist available whenever a deployment, domain, API route, CDN rule, certificate, reverse proxy, or authentication flow changes. Re-run it before a major release and after changing redirect rules, cache policies, CORS configuration, cookie attributes, compression, or hosting infrastructure. It is also worth revisiting after a browser, framework, proxy, or command-line tool changes, because request defaults and diagnostic interfaces can evolve.

For a practical final pass, save a small test set: the canonical home-page URL, one redirected URL, a representative API endpoint, an authenticated endpoint tested safely, and one static asset. Record the expected status, important headers, and redirect destination for each. When an incident occurs, run the same tests with curl and browser developer tools, compare the results with logs, and change only the configuration that explains the evidence. That turns an HTTP status checker from a one-time lookup into a reusable web-debugging workflow.