Chrome shows "This page isn't working — example.com redirected you too many times." Firefox calls it "The page isn't redirecting properly." Either way, the browser gave up after chasing the same URL through 20-something redirects, and your site never actually loaded. The good news: ERR_TOO_MANY_REDIRECTS almost always traces back to one of four causes, and none of them need a rebuild — just the right fifteen minutes.
Symptom: What You're Actually Seeing
The error shows up differently depending on where the loop is happening:
- Every page on the domain loops — including wp-admin. This points to a server-level or CDN-level redirect fighting itself.
- Only the front end loops, wp-admin loads fine — usually a WordPress URL setting or a plugin doing the redirecting.
- It loops for some visitors but not others (or only after a recent SSL install) — classic Cloudflare SSL mode mismatch.
- It started right after you "fixed" something else — forced HTTPS, added www, installed a security plugin — that change is almost certainly the trigger.
Before touching config files, confirm what the server is actually sending. Run this from your own machine, not from the server (you want to see what a real visitor's browser sees):
curl -IL https://example.comRead the chain of HTTP/1.1 301 or 302 lines and their Location headers top to bottom. If you see the same URL reappearing, or it keeps flipping between http:// and https://, you've found the loop.
Cause 1: Cloudflare SSL Mode Doesn't Match the Origin
This is the single most common cause we see, and it's almost always introduced the day someone turns on Cloudflare in front of a site that also has its own SSL rules (WordPress force-HTTPS, or a hosting-panel HTTPS redirect).
Here's the mechanic: Cloudflare terminates SSL for the visitor, then talks to your origin server over whatever protocol its SSL mode says. If that mode is set to Flexible, Cloudflare connects to your origin over plain HTTP — even though the visitor sees HTTPS. If your server (or WordPress, or an .htaccess rule) then redirects any HTTP request to HTTPS, Cloudflare receives that redirect, reconnects over HTTP again per its Flexible setting, and the whole thing repeats forever.
| Cloudflare SSL Mode | What It Does | Requires On Origin |
|---|---|---|
| Flexible | Visitor ↔ Cloudflare is HTTPS; Cloudflare ↔ origin is HTTP | Origin must NOT autossl-failures-not-secure-browser-warnings" class="auto-link">force HTTPS — causes the loop |
| Full | Visitor ↔ Cloudflare and Cloudflare ↔ origin are both HTTPS | Any valid certificate on origin (self-signed OK) |
| Full (Strict) | Same as Full, but validates the origin cert against a trusted CA | Valid, non-expired, CA-signed certificate (e.g. AutoSSL) |
Fix: in the Cloudflare dashboard, go to SSL/TLS → Overview and switch to Full (Strict) if your origin has a proper AutoSSL/Let's Encrypt certificate in cPanel (it almost certainly does). That lets your origin keep forcing HTTPS without Cloudflare undoing it on every hop.
Cause 2: WordPress Site URL Mismatch
If wp-admin loads but the front end loops, check Settings → General in wp-admin. If WordPress Address (URL) and Site Address (URL) are set to http:// while a plugin or server rule forces https://, WordPress and the server disagree on every request and keep handing it back and forth.
When the dashboard itself won't load because of the loop, fix it directly in wp-config.php instead — add these two lines above the line that says /* That's all, stop editing! */:
define('WP_HOME','https://example.com');
define('WP_SITEURL','https://example.com');Also check the database directly through phpMyAdmin in cPanel if you'd rather not edit config files — the values live in wp_options under siteurl and home.
Cause 3: Conflicting Force-SSL Plugins or Rules
It's common to end up with two things trying to force HTTPS at once — say, a security plugin like Really Simple SSL and a manually-added rule in .htaccess. Each one redirects, the other one's condition still isn't satisfied from its own point of view (often because it's checking $_SERVER['HTTPS'] directly instead of respecting a proxy header), and they bounce the request back and forth.
Open .htaccess in cPanel's File Manager and look for a block like this near the top:
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]If you're behind Cloudflare or any reverse proxy, %{HTTPS} can read as "off" even on a secure connection, because the proxy terminated SSL upstream. Replace the condition with one that checks the forwarded header instead:
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]Then disable any redundant force-SSL plugin so only one layer is doing the redirect. Two layers doing the same job is exactly how loops start.
Cause 4: A Stale Cached Redirect (HSTS) in Your Own Browser
Fixed the server, but the loop persists only for you? Your browser may have cached an old redirect via HSTS (HTTP Strict Transport Security) or a plain 301 it isn't rechecking. Test in an incognito/private window or with curl -IL first — if that comes back clean, it's local caching, not your server.
To clear it in Chrome: visit chrome://net-internals/#hsts, enter your domain under "Delete domain security policies," and click Delete. Then hard-refresh with Ctrl+Shift+R (or Cmd+Shift+R on Mac).
Prevention
- Whenever you add a CDN or reverse proxy in front of a site that already forces HTTPS, check the SSL mode on day one — don't wait for a ticket.
- Keep exactly one layer responsible for the HTTP-to-HTTPS redirect: either the CDN, the server, or one plugin. Not two.
- Any redirect rule you write should check
X-Forwarded-Protoif there's any chance of a proxy sitting in front — checking%{HTTPS}alone only works for direct connections. - After migrating a site or changing hosting, always test with
curl -ILbefore declaring it done — it catches loops that a normal browser might mask with cached state.
Frequently Asked Questions
Why does the redirect loop only happen for some visitors and not others?
Browser-side caching is the usual reason. One visitor's browser cached an old HSTS policy or 301 response and keeps replaying it, while a visitor who's never been to the site gets a fresh set of requests and sees the current (fixed or still-broken) behavior. Always test in an incognito window before assuming a fix worked or failed.
Is ERR_TOO_MANY_REDIRECTS the same as a 500 error?
No. A 500 error means the server tried to process the request and failed. A redirect loop means the server (or a CDN in front of it) keeps successfully responding with "go to this other URL instead," and that URL points right back to where you started. The browser cuts it off after a set number of hops, usually around 20.
I don't use Cloudflare — can this still happen?
Yes. Any setup with more than one layer trying to enforce HTTPS — a load balancer plus a WordPress plugin, or an .htaccess rule plus a hosting-panel force-HTTPS toggle — can cause the same loop. Cloudflare is just the most common case because so many sites add it after their SSL is already configured.
Will switching Cloudflare SSL mode break anything else?
Moving to Full or Full (Strict) only requires that your origin server present a valid certificate over HTTPS on port 443, which any cPanel account with AutoSSL already has. It doesn't change anything visitors see; it only changes how Cloudflare talks to your origin. Skip Flexible mode entirely once you have AutoSSL running.
How many redirects is "too many"?
Chrome and Firefox both give up after roughly 20 redirects in the same chain. A legitimate redirect chain (say, an old URL to a new one, then to HTTPS) is normally 1-3 hops; anything cycling past a handful of hops back to a URL you've already seen is a loop, not a chain.
