ERR_TOO_MANY_REDIRECTS means your browser gave up. It followed a redirect, then another, then another, noticed it was going in circles, and stopped — usually after about twenty hops. Nothing crashed; two components simply disagree about the correct address for the page and each keeps handing the visitor back to the other.
One particular misconfiguration causes the large majority of these loops, and it is not obvious unless you know to look for it. This guide starts there, then covers the other causes, and finishes with how to watch the loop happen so you can see exactly which two components are arguing.
Why a Loop Forms
A redirect is a server saying "not here, go there". A loop happens when two rules point at each other, directly or through a chain. The classic shape is one rule forcing HTTP to HTTPS while something upstream keeps converting the request back to HTTP, so the two bounce the visitor between them forever.
Browsers cap the number of hops they will follow and then show this error, which is why the page never finishes loading rather than simply going to the wrong place. The cap exists to stop your browser looping infinitely, not because anything is broken in a way it could detect.
The Number One Cause: Cloudflare Flexible SSL
If you use Cloudflare and your SSL mode is set to Flexible, this is almost certainly your problem. It is the single most common source of redirect loops on the modern web and it catches people out because both halves look correct on their own.
Flexible means Cloudflare talks to your visitor over HTTPS but connects to your origin server over plain HTTP. Your server sees an insecure request arriving, does the responsible thing, and redirects it to HTTPS. Cloudflare receives that redirect, sends the visitor back around, connects to your origin over HTTP again — and the loop is complete.
| SSL mode | Cloudflare to your server | Loop risk |
|---|---|---|
| Off | Plain HTTP end to end | No loop, but no encryption either — do not use |
| Flexible | Plain HTTP | High — this is the classic cause |
| Full | HTTPS, certificate not validated | None |
| Full (strict) | HTTPS, certificate validated | None — the correct setting |
The Other Common Causes
- Conflicting www and non-www rules. One rule adds www, another strips it, and they take turns. This is the second most common cause after Flexible SSL.
- A WordPress site URL mismatch. If the Site Address in settings does not match the address people actually use — http versus https, or www versus not — WordPress redirects to its configured address and whatever forced the original address redirects back.
- Duplicate HTTPS redirects. One in .htaccess, another in a plugin, another in the server config. Each is individually correct and together they conflict.
- A stale cookie or cached redirect in the browser. If the loop follows you across every device, it is server-side; if it only affects you, clear cookies for that domain and try a private window.
- A login redirect that never resolves. The site sends you to log in, the login page sends you to the dashboard, the dashboard decides you are not logged in and sends you back. Usually a session or cookie-domain problem.
- A load balancer or proxy not passing X-Forwarded-Proto. The application cannot tell the original request was HTTPS, assumes HTTP, and redirects — the same shape of problem as Flexible SSL, one layer further in.
Work Through It in This Order
- If you use Cloudflare, check the SSL mode first. Set it to Full (strict) if your origin has a valid certificate. This alone resolves most cases.
- Test in a private window. If the loop disappears, it is a cookie problem on your machine rather than a server rule.
- Look for more than one HTTPS redirect. Check .htaccess, the server config, and any SSL or security plugin. Keep exactly one and remove the rest.
- On WordPress, confirm WordPress Address and Site Address match how the site is genuinely reached, including the https:// prefix and the presence or absence of www.
- Pick one canonical form — www or non-www — and make every rule agree with it. Mixed rules across layers are what creates the argument.
- Temporarily rename .htaccess and reload. If the loop stops, the rule is in that file and you can bisect from there.
- If you use a proxy or load balancer, make sure X-Forwarded-Proto is being passed and that the application is configured to trust it.
How to See Where the Loop Goes
Guessing is slow. Watching the redirect chain takes about ten seconds and tells you exactly which two addresses are bouncing off each other.
From a terminal, run "curl -IL https://yourdomain.com" — the -I asks for headers only and -L follows redirects, so you get the full chain printed out with the Location header at each hop. The moment you see the same two URLs alternating, you have found your loop and you know precisely which pair of rules to look at.
In a browser, open DevTools, go to the Network tab, tick "Preserve log" and reload. Each 301 or 302 appears as its own row with its Location header, so you can read the loop in sequence. It is the same information as curl, presented visually.
Either way, the useful output is the pair of URLs that repeat. Once you know it is bouncing between http://example.com and https://example.com, or between example.com and www.example.com, the search narrows to whichever rules touch that specific pair.
Want a proper SSL certificate on your origin server?
Hosting with free HTTPS SSL included, or a Cloud VPS where you control the certificate yourself — from ฿200/year.
Frequently Asked Questions
I turned off my HTTPS redirect and the loop stopped. Is that a real fix?
It is a workaround, and on Cloudflare Flexible it leaves traffic between Cloudflare and your server unencrypted. Visitors see a padlock and assume the whole path is secure when half of it is not. The proper fix is a valid certificate on the origin plus SSL mode set to Full (strict), then you can turn the redirect back on.
Why does it work for me but loop for everyone else?
Usually caching. Your browser already holds a cookie or a cached redirect that short-circuits the loop, while a fresh visitor follows the whole chain. Always confirm in a private window or a different browser before deciding a redirect problem is fixed.
Does a redirect loop damage SEO?
Yes, and quickly, because Googlebot cannot reach the page at all — it is not slow content, it is no content. Sustained loops cause pages to drop out of the index. Google Search Console will report it as a redirect error, which is worth checking after any SSL or domain change.
How many redirects is too many?
Browsers typically stop at about twenty. But for anything other than a loop you should aim for zero or one — every extra hop adds latency, and chains of three or more suggest layers of rules nobody has cleaned up. Redirect straight to the final destination rather than through intermediate steps.
Should I use www or non-www?
It genuinely does not matter for ranking, as long as you pick one and redirect the other to it consistently. What causes problems is having rules in different layers that disagree — which is exactly how loops start.
GUIDES
Related articles
Keep reading on similar topics
ERR_CONNECTION_TIMED_OUT — What It Means and How to Fix It
The page just hangs and then Chrome says ERR_CONNECTION_TIMED_OUT. This guide shows you how to work out in two minutes whether the problem is on your side or the server side, then walks through the fixes for each — plus how this error differs from the similar-looking ones people confuse it with.
Read more
500 Internal Server Error — Causes and How to Fix It
A 500 is the least informative error on the web: it means "something went wrong and I am not telling you what". The good news is that the server almost always wrote the real reason to a log file. This guide shows you where that log lives and how to work through the causes in the order that finds the culprit fastest.
Read more
403 Forbidden — What It Means and How to Fix It
A 403 is not a broken server. It is a server that understood exactly what you asked for and decided you are not allowed to have it. This guide covers how 403 differs from 401, the causes in order of likelihood, and the cases where a 403 is the server doing its job properly.
Read more