Firefox: The Page Isn't Redirecting Properly

What’s actually happening

Same loop Chrome calls ERR_TOO_MANY_REDIRECTS, different label. URL A sends the browser to B, B sends it back to A, and Firefox follows the bounce about 20 times before it stops and shows this page. The site is completely unreachable in the browser — no content ever paints. Firefox's message suggests cookies, which is occasionally right (a login/session redirect loop) but far more often it's an SSL or host-canonicalization rule fighting itself. Note that Firefox and Chrome can disagree: a cookie-driven loop sometimes loads in one and not the other.

Common causes

• Cloudflare SSL set to "Flexible" while the origin also forces HTTP→HTTPS — Cloudflare talks to the origin over HTTP, the origin redirects to HTTPS, Cloudflare strips it back to HTTP, forever. The classic cause.
• Contradictory www→non-www and non-www→www rules in two places (CDN page rule plus .htaccess, say) that undo each other.
• A CMS "site URL" set to one protocol/host while the server or proxy forces the other.
• A session/auth cookie that never sets (cookies blocked, wrong cookie domain, or SameSite issue), so a "log in" redirect re-fires every request.
• An HTTPS redirect rule that matches the very URL it redirects to, so the destination immediately redirects again.

How to fix it

1. Trace the chain with curl`curl -IL https://example.com/` prints every hop and its Location header. You'll see A → B → A repeating — that's the loop, and the two URLs in it tell you which rules are colliding. Run it for both the http:// and https:// versions and with/without www.
2. Fix the Cloudflare SSL mode firstIf you're on Cloudflare, go to SSL/TLS > Overview and switch "Flexible" to "Full (strict)" (your origin must have a valid cert, which it should). Flexible + a server HTTPS redirect is the #1 cause of this exact loop. This alone resolves most cases.
3. Pick one canonical host + protocol and enforce it onceDecide on https://example.com OR https://www.example.com, then make sure exactly one rule redirects everything else to it. Delete the contradicting rule — a redirect in .htaccess and a duplicate in the CDN or CMS will fight.
4. Rule out the cookie case Firefox suggestsIf curl shows a loop only after a login/session step, it's the cookie path. Check that the auth cookie's Domain and Path match the site, that SameSite isn't blocking it, and test in a fresh Firefox profile or with cookies enabled. Clearing cookies for the domain clears a stale-cookie loop.
5. Test in private windows across browsersAfter the fix, load the URL in a Firefox private window and a Chrome incognito window. Different engines cache redirects differently; a private window guarantees you're seeing the live behavior, not a cached 301.