ERR_TOO_MANY_REDIRECTS: the Cloudflare Flexible SSL loop and other causes

2026-06-21 · redirects · cloudflare · ssl · https · debugging

redirectscloudflaresslhttpsdebugging

ERR_TOO_MANY_REDIRECTS means the browser followed a redirect chain that never terminated — page A sends you to B, which sends you back to A, forever. Chrome gives up after about twenty hops. By far the most common cause is Cloudflare's SSL/TLS mode set to Flexible, which fights an HTTP-to-HTTPS redirect on your origin. The fix is almost always to change one setting; the diagnosis is always to trace the chain and find the repeating hop.

The Cloudflare Flexible SSL loop

This is the one that catches everyone. With SSL mode set to Flexible, Cloudflare terminates TLS at its edge and then connects to your origin over plain HTTP. Your origin — Nginx, Apache, a framework, a host panel — sees an HTTP request and dutifully redirects it to HTTPS. That redirect goes back to Cloudflare, which re-requests over HTTP again, gets the same redirect, and the loop never closes.

The fix: in the Cloudflare dashboard set SSL/TLS → Overview → Encryption mode to Full or, better, Full (strict). Full makes Cloudflare connect to the origin over HTTPS, so the origin's HTTP-to-HTTPS redirect never fires. Use Full (strict) if your origin has a valid certificate — even a free Let's Encrypt cert counts.

Confirm the loop before you touch anything — watch the chain repeat the same hop:

curl -IL https://example.com
HTTP/2 301
location: https://example.com/
HTTP/2 301
location: https://example.com/
...

Same URL, same status, over and over — that is the signature of a loop, not a normal redirect.

Fighting www and apex redirects

The second classic: one rule forces www.example.com → example.com while another forces example.com → www.example.com. Each side thinks it is canonical, so they ping-pong. It usually happens when a redirect is set in two places — a Cloudflare Page Rule and your DNS host's "domain forwarding" — and nobody remembers the second one. Pick one canonical host and configure the redirect in exactly one layer.

Doubled HTTP-to-HTTPS rules

Closely related: an HTTP-to-HTTPS redirect configured in both your web server and your application (or both Cloudflare's "Always Use HTTPS" and an origin rule). These usually agree, so you never notice — until a proxy rewrites the scheme and the app misreads X-Forwarded-Proto, believes the request is still HTTP after the server already upgraded it, and redirects again. Keep HTTPS enforcement in one layer only.

Trailing-slash and canonical rules

A rule that adds a trailing slash (/about → /about/) running against one that removes it (/about/ → /about) is a guaranteed loop. So are SEO canonical redirects that disagree with the framework's own routing. Trace the chain: if you see /page and /page/ alternating, that is your culprit.

Cookie and session loops

Some loops are stateful. An app redirects unauthenticated users to a login page, the login page can't read its session cookie (wrong Domain, wrong Secure/SameSite, or a clock skew expiring it instantly), so it bounces back to the protected page, which redirects to login again. As a quick client-side check, clear cookies for the site or open an incognito window — if the loop vanishes, it's cookie-driven, and the cookie attributes are where to look.

Diagnose by tracing the full chain

Every one of these is found the same way: follow the redirects and look for the repeating hop.

curl -sIL https://example.com | grep -i '^location:'

The redirect checker does the same trace in the browser and lays each hop out so the loop is obvious at a glance.

Trace your redirect chain →