ERR_TOO_MANY_REDIRECTS: what it is, how to fix redirect loops on WordPress and Cloudflare

Anyone managing a website eventually sees this screen: ERR_TOO_MANY_REDIRECTS (or "This page isn't redirecting properly"). The site isn't down, there's no attack in progress: two different systems are bouncing the same request back and forth because both want to decide whether the page should be served over HTTP or HTTPS. This guide explains how to reproduce the error from the terminal and how to find the culprit, step by step, on WordPress and Cloudflare.

What is a redirect loop

A redirect is a server response with status 301 or 302 and a Location header that tells the browser "go elsewhere". A loop forms when two components in the chain send the request back and forth: A says "go to HTTPS", B says "go to HTTP", A redirects back to HTTPS again, and so on infinitely until the browser gives up and shows the error.

Reproducing the error with curl

First rule: don't guess, measure. From the terminal:

curl -IL https://yoursite.com

-I requests only headers (no page body), -L follows every redirect. The output shows a block of headers for each hop: read the status line (HTTP/1.1 301 Moved Permanently) and the Location line just below. If the site is truly in a loop, curl will continue following redirects up to the default limit (50) and stop on its own, or you can force a lower limit to see the repeating pattern immediately:

curl -IL --max-redirs 10 https://yoursite.com

To isolate only the useful lines in a long chain:

curl -sIL https://yoursite.com | grep -iE '^(HTTP|location)'

If the sequence alternates between http:// and https:// on the same domain, the problem is almost certainly an HTTP/HTTPS conflict between two components in the chain (proxy, control panel, application).

The most common causes

Cause	Where it appears	Typical symptom
Cloudflare in Flexible mode + site forcing HTTPS	Sites behind Cloudflare	Loop immediately after activating the proxy or a certificate
Cloudflare Full/Strict + origin still forcing HTTP	Sites behind Cloudflare after a mode change	Loop after "fixing" the SSL mode
.htaccess rules or redirect plugins that pile up	WordPress on Apache	Loop after installing an SEO or SSL plugin
WordPress Address different from Site Address	WordPress	Loop after a domain transfer or migration
Corrupted session cookie in browser	Client-side	The loop disappears in a private window or another browser

Checks on WordPress

1. Settings > General: WordPress Address (URL) and Site Address (URL) must have the same scheme and the same host, both https:// and both without www or both with www. A misalignment here generates a canonical redirect that conflicts with any other rule.
2. Redirect or SSL plugins: plugins that force HTTPS, manage SEO redirects or clean up mixed content are among the most common causes of loops when they pile up with a rule already present on the server or proxy. Deactivate them one at a time from Plugins > Installed Plugins to isolate the culprit.
3. File .htaccess: if you're locked out of the admin panel, access via FTP or your hosting file manager, rename .htaccess (for example to .htaccess-old) and reload the site. If the loop disappears, the file contained a conflicting rule; WordPress will recreate a standard one the first time you save permalinks from Settings > Permalinks.
4. If none of the three points above fix it and you clear the domain cookies (or try in a private window) and the site becomes accessible again, the problem is a corrupted session cookie on the browser side, not a server configuration issue.

Checks on Cloudflare

The official Cloudflare documentation lists three families of causes: SSL/TLS encryption mode, Edge Certificates page settings and conflicting redirect rules.

The most frequent case: if the domain has encryption mode set to Flexible, Cloudflare sends unencrypted requests to the origin server via HTTP, and redirect loops are generated if the origin automatically redirects all HTTP requests to HTTPS. Fix this from SSL/TLS → Overview: change the mode from Flexible to Full or Full (Strict) (the latter requires a valid certificate installed on the origin).

There's also the opposite case, less well known: if the mode is already Full or Full (Strict) but an old rule remains active on the origin that redirects from HTTPS to HTTP, the loop forms anyway, this time in the opposite direction. In this case the fix isn't in Cloudflare mode but on the origin: remove the residual HTTPS→HTTP redirect from the server.

Also check in SSL/TLS → Edge Certificates: the Always Use HTTPS toggle generates the same type of loop if the origin in turn redirects to HTTP, and the same applies to HSTS, which in that case needs to be deactivated or requires the encryption mode to be at least Flexible. Finally, anyone who has set up Redirect Rules or Page Rules on the domain must verify they don't overlap with those already present on the origin: this is the most common cause when the loop involves www and non-www or different subdomains.

For those who want to force HTTPS without touching the origin server, Cloudflare offers an edge-side mechanism (Enforce HTTPS) that avoids having to manage a server-side redirect, eliminating one of the two halves of the conflict at the root.