How to Diagnose HTTP Status Codes and Redirect Loops

Learn what the main HTTP status codes mean in practice, how to trace a redirect chain, and how to find the cause of redirect loops and 4xx/5xx errors.

The problem

A page returns an error, a link ends up somewhere unexpected, or the browser reports "too many redirects". The HTTP status code and the Location header are the evidence: the status code tells you who considers the request a failure and why, and redirects show exactly where the server is sending you. This guide gives a procedure for reading both.

Step 1: See what the server actually answers

Browsers hide redirects and cache aggressively, so start with a neutral client. The HTTP Status Checker follows each redirect and lists every hop. On the command line:

curl -sI -L --max-redirs 10 http://example.com/old-page | grep -iE '^(HTTP|location)'

HTTP/1.1 301 Moved Permanently
Location: https://example.com/old-page
HTTP/2 301
location: https://www.example.com/old-page
HTTP/2 200
(illustrative output)

Reading it: two permanent redirects before the real page. Each hop costs a round trip, so the best fix is a single redirect straight to the final URL. Use curl -v when you need the full request and response headers.

Step 2: Interpret the status code

2xx — success: 200 OK returned the content; 204 No Content succeeded with nothing to return (common for APIs).
301 and 308 — permanent redirects: The resource has a new permanent URL. Browsers may cache these for a long time. 308 preserves the request method (a POST stays a POST); 301 historically lets clients change POST to GET.
302, 303, and 307 — temporary redirects: The resource is temporarily elsewhere. 307 preserves the method; 303 explicitly tells the client to fetch the new URL with GET (used after form submissions).
304 Not Modified: The cached copy is still valid; no body is sent. Normal and desirable.
400 Bad Request: The server could not parse the request: malformed syntax, oversized headers, or invalid cookies.
401 vs 403: 401 Unauthorized means authentication is missing or failed. 403 Forbidden means the server understood the request and refuses it: a permissions rule, an IP or geography block, or a web application firewall deciding the client looks automated.
404 and 410: Not found, versus intentionally and permanently gone. A site that redirects every missing URL to its home page causes "soft 404" confusion; return a real 404.
405 and 413: Method not allowed (the Allow header lists valid methods), and request body too large.
429 Too Many Requests: Rate limiting. A Retry-After header may say how long to wait.
500 Internal Server Error: The application failed. The response rarely says why; check the server's error logs.
502 Bad Gateway: A proxy, CDN, or load balancer got an invalid response (or none) from the upstream server. Look at the upstream: is it running, listening, and reachable?
503 Service Unavailable: Overloaded, in maintenance, or no healthy backend is available. Often temporary; may include Retry-After.
504 Gateway Timeout: The proxy waited too long for the upstream. Typically slow application code, a slow database, or a firewall silently dropping the proxy's connection.

Step 3: Diagnose a redirect loop

A loop means each URL redirects to another and eventually back to one already visited. Browsers stop with ERR_TOO_MANY_REDIRECTS (Chrome) or "The page isn't redirecting properly" (Firefox); curl stops with error 47:

curl -sIL --max-redirs 5 https://example.com/
curl: (47) Maximum (5) redirects followed
(illustrative)

Trace the chain with the Status Checker or curl -sIL and look for the repeating URL pair. The most common causes:

HTTP/HTTPS disagreement between layers. A CDN or load balancer terminates HTTPS and connects to the origin over plain HTTP, while the origin redirects every HTTP request to HTTPS. Each hop restarts the cycle. The origin should trust the proxy's X-Forwarded-Proto (or Forwarded) header, or the proxy should connect to the origin over HTTPS.
www and non-www rules fighting. One layer redirects example.com to www.example.com while another redirects back.
Redirects set in two places. The web server, the application, and the CDN each carry their own redirect rules, which can conflict.
Login redirect loops. An authenticated page redirects to login, and login redirects back because the session cookie is never accepted (wrong cookie domain, Secure flag over HTTP, or a SameSite mismatch).
Trailing-slash or locale rules that undo each other.

Fix the cause in one place: decide the single canonical URL (scheme, host, path), implement the redirect in exactly one layer, and make every other layer pass requests through unchanged.

Step 4: Check the headers that govern behavior

Use the HTTP Headers Checker on the final URL. The headers most relevant to these problems are Location (where a redirect points), Cache-Control (whether the response may be reused), Set-Cookie, Via (a proxy handled it), and Strict-Transport-Security. If the headers differ from what your browser reports, a CDN or user-agent rule is varying the response; use your browser's developer tools to see the browser's own view.

Pitfalls that waste hours

Cached redirects. Browsers can cache 301 and 308 responses for a very long time. A fixed server can still appear broken in a browser that remembered the old redirect. Test in a private window or with curl.
HSTS memory. Once a browser has seen Strict-Transport-Security, it forces HTTPS for that domain for the stated period, even if the server later misbehaves. This is intended, and it can turn a misconfiguration into a persistent loop for returning visitors.
Testing only from your own network. Bot protection, geography rules, and caches mean other clients may see something different.
Blaming the application. A 502/504 often originates at the proxy or in network paths between layers, not in the application code.

A short troubleshooting workflow

Confirm the URL resolves (DNS Lookup) and the certificate is valid (SSL/TLS Checker).
Trace redirects and read the final status (HTTP Status Checker).
Read the headers on the final response (HTTP Headers Checker).
For 4xx, ask "who is refusing, and why?" For 5xx, follow the request upstream, layer by layer, and read each layer's logs.
Verify the fix with a fresh client, then re-test the full chain.

Security considerations

Open redirects (a redirect that sends visitors to a URL taken from a request parameter) are abused in phishing; validate redirect targets.
Do not disable HTTPS redirects to "fix" a loop; fix the proxy configuration instead.
Use the URL / Domain Analyzer to inspect a suspicious link's redirect chain without opening it in a browser.

Tools used in this guide

HTTP Status Checker — Check the live HTTP status code, response time, and redirect chain for any URL.
HTTP Headers Checker — Inspect response headers, including key security headers like HSTS and CSP.
SSL/TLS Checker — Verify that a domain establishes a working HTTPS connection.
URL / Domain Analyzer — Safe first-level URL triage: components, DNS, redirects, HTTP and TLS details, and potentially suspicious characteristics.

References and further reading

References are primary sources (standards and official documentation). Commands and sample output are illustrative; behavior can vary by operating system and software version.

Keep reading

How to Troubleshoot TLS Certificate Errors — Identify why a browser or client rejects a certificate (expired, wrong name, incomplete chain, untrusted issuer, protocol mismatch) and fix it, using openssl, curl, and certificate checks.
How to Troubleshoot Network Connectivity Step by Step — A layered method for finding where a connection breaks: local configuration, gateway, routing, DNS, the path, the port, and the application, with commands for Windows, Linux, and macOS.