How to Debug Redirect Loops and 301/302 Issues Using HTTP Headers in Chrome

“This page isn’t redirecting properly” — Chrome’s message for an infinite redirect loop isn’t subtle, but finding out why the loop exists is rarely obvious from that screen. The actual answer lives in the response headers being passed back and forth.

This guide covers how to read the relevant headers to identify the root cause, and how to use header overrides to confirm your hypothesis without touching server config.

What Causes Redirect Loops

A redirect loop happens when the browser follows a Location header to a new URL that immediately redirects back — creating a cycle Chrome breaks after a few iterations.

The most common causes:

HTTPS misconfiguration. A server-level rule redirects http:// to https://, but a load balancer or reverse proxy strips the scheme before the origin sees the request — so the origin still thinks the request is HTTP and fires the redirect again.

Conflicting 301/302 rules. Two redirect rules overlap and bounce the request between them. This is common in CMS permalink settings, .htaccess files, or Nginx config that was modified incrementally without removing old rules.

Session and cookie issues. A login flow redirects to an authenticated page, but the Set-Cookie response isn’t being accepted (wrong domain, SameSite restriction, Secure flag mismatch). The auth check fails, re-triggering the redirect.

Cached 301s. Browsers cache 301 Moved Permanently responses. If the destination URL itself later gets redirected, you can end up with a loop from a stale cached entry — even after fixing the server config.

Reading the Headers

Open Chrome DevTools → Network tab. Reproduce the error. You’ll see the loop as a chain of requests. Look at each redirect response in turn.

Location

The Location header in a 3xx response tells you where the browser is being sent:

HTTP/1.1 301 Moved Permanently
Location: https://example.com/

In a loop, you’ll see two responses whose Location values point at each other. Identify the pair — that’s where the conflict is.

Strict-Transport-Security

HSTS tells the browser to always use HTTPS for a domain, even before any redirect fires. If HSTS is set but the target isn’t serving valid HTTPS, you’ll get a loop that isn’t visible in your server logs at all — it’s happening in the browser before the request leaves.

Strict-Transport-Security: max-age=31536000; includeSubDomains

If you suspect stale HSTS, go to chrome://net-internals/#hsts and delete the entry for your domain. Test again.

For login-triggered loops, look at the Set-Cookie header in the redirect response:

Set-Cookie: session=abc123; Domain=.example.com; SameSite=Lax; Secure

Check: does the Domain match what the browser is requesting? Is Secure set but the page is HTTP? Is SameSite=Strict blocking the cookie from being sent on the follow-up request? Any mismatch here means the cookie won’t be stored or sent, and the auth check will keep failing.

Using Header Overrides to Isolate the Problem

Once you have a hypothesis, you want to confirm it without touching your server config. This is where being able to override headers in Chrome becomes useful.

HeaderSnap is a Chrome extension that adds, modifies, and removes HTTP headers on matching requests and responses. It uses Chrome’s native declarativeNetRequest API (MV3), a declarative rule system where Chrome itself applies the header modifications at the network layer.

Pattern 1: HTTPS Redirect Loop

Hypothesis: The origin sees all requests as HTTP because the scheme is being stripped upstream.

Test: Add a request header rule that sets X-Forwarded-Proto: https on all requests to your domain. If the loop stops, you’ve confirmed the origin is checking this header to determine scheme — and it’s not being forwarded correctly from your proxy.

In HeaderSnap, create a rule:

Header Target: Request
Action: Set
Header Name: X-Forwarded-Proto
Header Value: https
URL pattern: *://your-domain.com/*

If the loop stops, you know the fix: configure your load balancer or reverse proxy to forward X-Forwarded-Proto (or use the equivalent trusted header your origin expects).

Hypothesis: The session cookie has a Secure flag but the local or staging environment is HTTP, so the cookie is silently dropped.

Test: Remove the Set-Cookie response header entirely so the browser receives no session cookie, then check if the redirect loop stops.

In HeaderSnap, create a response header rule:

Header Target: Response
Action: Remove
Header Name: Set-Cookie
URL pattern: *://your-local-or-staging-domain/*

Note: the remove action removes the entire Set-Cookie header — not just a single directive like Secure. If the loop stops after removing it, you’ve confirmed the cookie is involved. Investigate why the cookie isn’t being accepted: check for Domain mismatches, a Secure flag on an HTTP origin, or a SameSite restriction blocking the follow-up request.

You can also use HeaderSnap’s profile system to keep these override rules isolated — a “debug” profile for each environment, switched on only when needed.

Verifying Your Rules

If your override isn’t having the expected effect, the URL pattern may not be matching. Use HeaderSnap’s Test tab to enter a URL and confirm which rules apply to it. Adjust the pattern until it matches, then test again.

Quick Checklist

When you hit a redirect loop in Chrome:

Open Network tab in DevTools — identify which two URLs are bouncing
Check Location headers to confirm the cycle
Check Strict-Transport-Security if it’s HTTPS-related; clear HSTS if needed (chrome://net-internals/#hsts)
Check Set-Cookie if it’s login-related — look for Secure, Domain, SameSite mismatches
Check for cached 301s — open an incognito window to rule it out
If the root cause is upstream (proxy config, missing header) — use a header override to confirm before making config changes

Redirect loops are almost always a header problem. Reading the headers in DevTools gets you 80% of the way there; being able to modify them in place closes the rest.