You open a page and, instead of loading, the browser stops with an error: ERR_TOO_MANY_REDIRECTS, or “This page isn’t redirecting properly”.
It means the browser followed redirect after redirect and never reached a page. At some point, the chain points back to an address it already visited.
The loop is almost always caused by two systems that each think they’re in charge. Find those two, and the fix is usually quick.
What a redirect loop looks like
The simplest loop is two rules pointing at each other:
example.com/a → example.com/b
example.com/b → example.com/a
More often, the loop hides across different layers:
http://example.com → https://example.com (set in your hosting)
https://example.com → http://example.com (set somewhere else)
Each rule makes sense on its own. Together, they never end. Browsers give up after a set number of hops and show the error. You can read the short definition in our glossary.
Step 1: rule out your browser
Browsers cache permanent redirects. If you fixed something earlier, your browser may still be replaying the old version.
Open the URL in a private window. If it works there, the loop is already gone and you only need to clear your cache.
Step 2: see the whole chain
Paste the URL into our redirect tester. It follows each hop and stops when it detects a loop. You’ll see exactly which addresses repeat.
From the terminal, curl -IL https://example.com shows the same thing, one block per hop.
Look for the first URL that appears twice. The two hops around it are your suspects.
Step 3: check the usual causes
HTTPS set up in two places. Your hosting forces https://, while a proxy or CDN in front of it talks to your server over http://. The server redirects to HTTPS, the proxy fetches HTTP again, and so on. With Cloudflare, this often happens when its SSL mode is set to Flexible while the origin forces HTTPS.
www and non-www fighting. One system sends example.com to www.example.com, another sends it back. Pick one version and make every layer agree.
A rule that matches its own destination. A wildcard such as /blog/* → /blog/new/* also matches /blog/new/..., so it keeps adding to the path. Make the rule more specific, or send it to a different prefix.
A domain redirected to itself. It sounds obvious, but it happens during migrations. The old and new domains get swapped in a rule, or a catch-all points back to the same domain.
Redirects in two systems at once. For example, a WordPress plugin and the server config both redirect the same page in opposite directions. Decide which system owns the redirect and remove it from the other.
Step 4: fix it in one place
Once you know the two conflicting hops, remove or change one of them. Don’t add a third rule to compensate. That usually moves the loop rather than ending it.
A good rule of thumb: each redirect should be defined in exactly one system. That’s one reason we argue that redirects should live outside your website.
Step 5: test again, everywhere
After the fix, test in a private window and with the tester. Check:
http://andhttps://with and without
wwwone URL caught by each wildcard rule
How to avoid loops in the first place
Most loops come from two systems both handling the same job. A few habits prevent them:
Decide who owns HTTPS. Either your host, your CDN or your redirect service forces
https://, not all three.Decide who owns www. Pick one version of the domain, and set the redirect in one place.
Point rules at final URLs. A rule should never send visitors to a URL that another rule redirects again.
Write wildcard rules carefully. Make sure a wildcard’s destination can’t match its own pattern.
Test before launch. Run the important URLs through a redirect tester before you switch DNS.
When the loop only affects some visitors
Sometimes a loop only happens for logged-in users, or only in one country. That usually points to cookies, a login redirect, or geo rules on the destination site, not the domain redirect itself. Test in a private window and from the redirect tester, which has no cookies, to tell the two apart.
Loops in Redirect Supply
Redirect Supply always sends www to the bare domain first, then runs your rule. That’s two hops by design, not a loop. A loop would only happen if a rule’s destination points back to the same domain and path. Our redirects not working doc covers what to check.
