Redirect Loop: Fixing the ERR_TOO_MANY_REDIRECTS Error

The browser won't open the page and just keeps spinning; in the end it shows the ERR_TOO_MANY_REDIRECTS message. If you fetch the headers with curl -I, you'll see that a 301 or 302 code is returned every time and the destination address points back to the same place again. This is the redirect loop, and it almost always comes from one of three specific places: a www vs. non-www conflict, an SSL setting in Cloudflare, or a rewrite rule whose condition is written incorrectly.

Before making any change, look at the chain. Guessing here is a waste of time.

curl -sIL http://example.com | grep -Ei '^(HTTP/|location:)'
curl -sIL https://www.example.com | grep -Ei '^(HTTP/|location:)'

Read the output from top to bottom. If location: repeats and points back to an address you've already seen, the loop is confirmed. Also count the number of hops; browsers usually stop after about 20 redirects, but in practice a loop with just two hops can take a site down.

The www loop; the most common form of redirect loop

The classic scenario is this: in the hosting panel you've written a rule that sends example.com to www.example.com, and at the same time in DNS you've pointed the www record with a CNAME to the main domain, or a reverse Forwarding is enabled in the domain panel. The result is this:

http://example.com   → 301 → https://www.example.com
https://www.example.com → 301 → https://example.com
https://example.com  → 301 → https://www.example.com   (and so on infinitely)

Here's the mistake people make: they think the problem is the browser or the cache and hit Ctrl+F5 several times. But the loop is on the server, and each time a correct and clean response is returned. The sign is that in Incognito mode exactly the same thing happens, and curl shows the same chain.

The solution is to unify the direction. Choose one version as canonical and let only one layer write the redirect. In Apache with .htaccess:

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^ https://www.example.com%{REQUEST_URI} [R=301,L]

The important point in this rule is [OR] and [L]. If you remove [L] or write the condition so that it also applies to www itself, the loop comes back. In Nginx, the equivalent is a separate server block for the non-canonical version, not two nested ifs.

Check DNS before making changes

Sometimes the loop isn't in the web server at all. A wrong A or CNAME record causes the domain to reach a server where your site isn't even hosted, and that server forwards the domain somewhere else. Use the DNS and network lookup tool to view the A, AAAA, and CNAME records and make sure www and the root point to the same destination.

Cloudflare and the Flexible SSL trap

I see this a lot, and few people suspect it first. In Cloudflare, the SSL mode is set to Flexible, meaning traffic between the user and Cloudflare goes over HTTPS, but between Cloudflare and your server it goes over HTTP. Now if you have a rule on the server that says "send every HTTP request to HTTPS," the server responds telling Cloudflare "go to HTTPS," Cloudflare sends the same request back to the server over HTTP, and the loop is complete.

There are two ways out. Either change the SSL mode to Full (Strict) and install a valid certificate on the server, or disable the HTTPS redirect rule on the server and let Cloudflare do it itself with a Page Rule or Always Use HTTPS. I always choose the first option; because Flexible in practice means traffic between two points travels over the internet unencrypted, which contradicts the original purpose of SSL. Only if your server doesn't have a valid certificate and you can't install one today, the second option is temporarily acceptable.

The sign you see in curl

In this case, curl -I https://example.com returns a 301 with location: https://example.com/; that is, the same current address. This pattern is almost the signature of an SSL loop. If you also see server: cloudflare in the headers, it's almost certain.

Rewrite rules that create loops themselves

Sometimes the problem is neither www nor SSL, but an extra condition or a plugin. A few common patterns:

• Two redirect plugins are active at the same time and each considers the opposite version canonical.
• In WordPress, siteurl and home in the wp_options table differ; one has www and the other doesn't.
• A RewriteRule is written without [L] and sends the request back to itself.
• In Nginx, a return 301 inside a block that itself is subject to the same condition.

For WordPress, the fastest way to see the actual value is:

wp option get siteurl
wp option get home

If these two don't match, that difference can be the source of the loop. Fixing them is done with wp option update, but take a backup first.

When the site is on shared hosting

On shared hosting, your hands are tied for changing the Nginx or Apache config, and you only have .htaccess. Here order matters: .htaccess rules are executed from top to bottom, and the first rule that has [L] stops the rest. If you put the HTTPS redirect rule above the WordPress rule and its condition is correct, there's no problem; but if it's lower and after the WordPress rewrite rules, it may never run or, worse, conflict with them.

In Linux hosting there's usually a "Redirect Management" section in the panel that generates the same rules without touching the file. If you're a beginner, use it and then read the file to understand what was written.

A step-by-step method to find the loop

1. With curl -sIL, get the full chain for all four combinations (http/https and with/without www).
2. Write each location: on paper and see which address repeats twice.
3. If Cloudflare is active, temporarily set it to DNS Only mode and test again. If the loop goes away, the problem is the SSL settings.
4. Disable the redirect plugins one by one.
5. After each change, clear the browser cache and server cache and run curl again.

One point that wastes a lot of people's time: cache. If you use page caching at the server level or a CDN, an old response with a 301 header may still be served and you'll think the change hasn't been applied. Take the Cache-Control header on 301 responses seriously; if browser caching and Cache-Control headers aren't configured correctly, a wrong redirect can stay in users' browsers for hours.

Preventing the problem from coming back

After fixing it, write a simple test that checks all four combinations and counts the number of hops. If it's more than two hops, raise an alert. This prevents the loop from coming back after future changes.

for u in http://example.com http://www.example.com \
         https://example.com https://www.example.com; do
  n=$(curl -sIL "$u" | grep -c '^location:')
  echo "$u -> $n redirects"
done

If you see a number greater than 2, check that address manually. For high-traffic sites, put this test in your monitoring; because a redirect loop can zero out organic traffic in a few minutes and appear in Search Console reports as a sudden drop in clicks. If the site is still slow after fixing the loop, go to diagnosing a slow website; these two problems are separate and mixing them up just wastes time.

Frequently asked questions

Why does ERR_TOO_MANY_REDIRECTS only appear in some browsers?

Because each browser has a different limit for the number of redirects and some clear the cache later. If the loop is real, it repeats in Incognito mode too. If you only see it in one specific browser, the cache or an extension like an HTTPS redirector in that browser is probably to blame.

Does clearing the browser cache fix the redirect loop?

No. The cache only makes the old response change later, but the loop is created on the server. Until the redirect rule is fixed, every new request follows the same path. Clearing the cache is only needed to see the result of changes.

Should I fix the www loop with a redirect in DNS or in the web server?

In the web server. A redirect at the DNS level (Forwarding) gives you less control and can conflict with server rules. A clean 301 rule in .htaccess or the Nginx config can both be tested and be seen in the logs.

How do I tell whether the loop is from Cloudflare or from the server?

Temporarily set the record to DNS Only so traffic reaches the server directly. If the loop disappears, the problem is the SSL settings in Cloudflare. If it remains, the redirect rule on the server is to blame. After diagnosing, set the SSL mode back to Full (Strict).