Cloudflare too many redirects errors occur when a browser gets stuck in an infinite loop between your origin server and Cloudflare’s proxy, typically triggered by SSL/TLS mismatches, misconfigured page rules, or conflicting .htaccess redirects. In 2026, the most common fix remains switching Cloudflare’s SSL mode from Flexible to Full or Full (Strict) to match your server’s encryption settings.
According to Cloudflare’s own support data, redirect loops account for roughly 18% of all SSL-related configuration errors reported by new users. The error halts your entire site, turning away visitors and tanking search rankings within hours. Google’s crawlers treat redirect loops as critical failures, which means your pages drop from the index fast.
I’ve seen staging environments accidentally pushed to production with Flexible SSL still active, breaking e-commerce checkouts at peak traffic. One misconfigured rule can cost you real money.
The error message varies by browser. Chrome shows “ERR_TOO_MANY_REDIRECTS.” Firefox says “The page isn’t redirecting properly.” Safari tells you the page has too many redirects.
What’s happening under the hood is simple: your browser requests a page, the server sends a 301 or 302 redirect back to the same URL (or a chain that circles back), and the cycle repeats until the browser gives up after 20 hops. Cloudflare sits in the middle as a reverse proxy, so any conflict between Cloudflare’s rules and your origin server’s configuration will trigger the loop.
The ERR_TOO_MANY_REDIRECTS code specifically fires when the browser’s internal redirect counter maxes out. It’s a safety mechanism to prevent infinite resource consumption.
Start by bypassing Cloudflare entirely. Edit your local hosts file to point your domain directly at your origin IP:
203.0.113.45 example.com
203.0.113.45 www.example.comFlush your DNS cache, then test the site. If it loads fine, the problem lives in Cloudflare’s configuration. If the loop persists, your origin server has the issue—check your .htaccess, nginx.conf, or WordPress redirect plugins.
Next, inspect the HTTP headers with curl:
curl -I https://example.comLook for chains of 301/302 responses. A healthy response shows one 200 OK. A redirect loop shows multiple Location headers pointing back and forth.
Cloudflare’s dashboard logs can pinpoint the exact rule causing trouble. Navigate to Analytics → Traffic, filter by status code 301 or 302, and trace the pattern. In support tickets I handled, the usual culprit was a page rule set to “Always Use HTTPS” combined with Flexible SSL.
SSL/TLS mode mismatch tops the list. When Cloudflare uses Flexible SSL (HTTP to your origin) but your server forces HTTPS, the loop begins. Your server redirects HTTP to HTTPS, Cloudflare converts HTTPS back to HTTP, repeat forever.
Page rules that conflict with origin redirects come second. If you enable “Forwarding URL” or “Always Use HTTPS” in Cloudflare while your .htaccess already redirects www to non-www, you create a circular path.
Third: WordPress plugins like Really Simple SSL or Rank Math that force HTTPS at the application level. They rewrite URLs after Cloudflare’s proxy has already made its decision, causing double-redirects.
Fourth: mixed www and non-www canonical settings. Cloudflare’s “Automatic HTTPS Rewrites” might canonicalize to www while your origin prefers non-www, or vice versa.
Fifth: stale browser cache or cookies storing old redirect instructions. This one’s less common in 2026 but still catches people off guard.
Log into your Cloudflare dashboard, select your domain, and click SSL/TLS in the sidebar. You’ll see four encryption modes.
If your origin server has a valid SSL certificate (Let’s Encrypt, commercial CA, anything trusted), switch to Full (Strict). This forces end-to-end encryption and validates your certificate. Most production sites should use this.
If your origin has a self-signed certificate or no certificate at all, use Full. Cloudflare encrypts the connection but skips certificate validation. Not ideal for security, but it breaks the loop.
Never use Flexible SSL on a server that redirects HTTP to HTTPS. Flexible means Cloudflare connects to your origin over plain HTTP, which your server will immediately redirect back to HTTPS, triggering the cycle.
According to the Cloudflare Community forums, roughly 70% of redirect loop threads resolve with this single fix. Change the setting, wait 60 seconds for propagation, then clear your browser cache and test.
Check your Cloudflare page rules under Rules → Page Rules. Delete or disable any “Forwarding URL” rules temporarily to isolate the problem. Also disable “Always Use HTTPS” if your origin already handles that.
On the server side, open your .htaccess file (Apache) or nginx.conf (Nginx) and look for redirect directives. A common Apache pattern looks like this:
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]That’s fine if Cloudflare is set to Full or Full (Strict). But if Cloudflare uses Flexible, the %{HTTPS} variable will always be “off” because Cloudflare sends HTTP to your server, so the redirect fires forever.
The fix: check Cloudflare’s CF-Visitor header instead.
RewriteEngine On
RewriteCond %{HTTP:CF-Visitor} '"scheme":"http"'
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]Now your server sees the original visitor’s protocol, not Cloudflare’s proxy protocol.
For Nginx, use the $http_cf_visitor variable:
if ($http_cf_visitor ~ '{"scheme":"http"}') {
return 301 https://$host$request_uri;
}Test the config syntax before reloading:
nginx -t
systemctl reload nginxDeactivate any SSL or redirect plugins temporarily: Really Simple SSL, WP Force SSL, Rank Math’s HTTPS redirect, and similar tools. Check if the loop stops.
If your site works without the plugin, the plugin was duplicating Cloudflare’s work. You can usually leave it disabled—Cloudflare handles HTTPS enforcement at the edge, so forcing it again in WordPress is redundant.
Some plugins let you exclude Cloudflare proxy IPs from their redirect logic. Really Simple SSL has a “Do not fix the site URL” option. Enable it if you want to keep the plugin active for other features.
Also check your wp-config.php for manual HTTPS enforcement:
if ($_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https')
$_SERVER['HTTPS']='on';That snippet tells WordPress to trust Cloudflare’s X-Forwarded-Proto header. It prevents WordPress from thinking it’s over HTTP when Cloudflare is serving HTTPS to the visitor.
Selective loops usually point to page-specific rules or URL patterns in your redirects. Check Cloudflare’s page rules for wildcard patterns that might catch only certain paths, like example.com/blog/*.
In your .htaccess, look for conditional redirects tied to specific REQUEST_URI values. A rule that redirects /old-page/ to /new-page/ while another rule redirects /new-page/ back to /old-page/ will loop those URLs while leaving the rest of the site alone.
WordPress permalinks can also cause partial loops if you change the structure (from /?p=123 to /post-name/) without flushing rewrite rules. Go to Settings → Permalinks and click Save Changes to regenerate the rules.
Sometimes, yes. Browsers cache 301 redirects aggressively, so an old loop instruction can persist even after you fix the server. Clear cache and cookies for your domain, or test in incognito mode to rule out client-side caching.
Technically yes, but Off disables all Cloudflare proxy features—no caching, no WAF, no DDoS protection. You lose the entire point of using Cloudflare. Fix the SSL mode properly instead of disabling the proxy.
Different user agents can trigger different server-side redirect logic. Check your .htaccess or nginx.conf for RewriteCond statements that test HTTP_USER_AGENT. Some setups redirect mobile users to a separate subdomain, which can loop if the subdomain also redirects back.
Cloudflare’s documentation states SSL mode changes apply globally within five minutes, but edge caches can hold old settings for up to an hour. Purge your Cloudflare cache manually under Caching → Configuration → Purge Everything to speed it up.
Workers run after page rules but before origin requests. If your Worker script issues a Response.redirect() that points back to a URL already handled by a page rule, you create a loop. Review your Worker code for circular redirect logic and test with the Workers editor’s preview tool.