How to Fix ERR_TOO_MANY_REDIRECTS (Complete Guide)

Summarize with:

ERR_TOO_MANY_REDIRECTS is one of those errors that takes a site completely offline while telling you almost nothing about what’s wrong. Your browser followed a chain of redirects — each one pointing to another URL — until it gave up. The root cause is always a configuration conflict that creates a loop instead of resolving to a real page. The tricky part: it can come from several places — Cloudflare, your .htaccess, WordPress URL settings, a plugin, or a combination. This guide works through every cause, in order from most to least common, with a specific fix for each.

What ERR_TOO_MANY_REDIRECTS means

A redirect is a server instruction telling the browser “go to a different URL instead.” Normally a redirect resolves: you visit the HTTP version of a page, the server sends you to the HTTPS version, and you land there. That’s one clean redirect.

ERR_TOO_MANY_REDIRECTS happens when redirects never resolve — URL A sends you to URL B, which sends you back to URL A, forever. Browsers follow a limited number of hops (usually about 20), then stop and show the error. Different browsers word it differently: Chrome says “This page isn’t working — redirected you too many times,” Firefox says “The page isn’t redirecting properly,” but the underlying loop is identical.

It affects all site types — WordPress, static sites, custom apps — though the causes below skew toward the setups where it appears most.

💡
First, a 30-second test

Before changing anything, open the site in an incognito/private window or a different browser. If it loads there, the problem is your browser’s cookies or cache (see the cookies fix below) — not the server. If it fails everywhere, it’s a server, Cloudflare, or WordPress configuration issue.

Cause #1: Cloudflare “Flexible” SSL (the most common)

If your site uses Cloudflare, check this first — it’s responsible for the large majority of cases. The culprit is Cloudflare’s SSL/TLS encryption mode set to Flexible.

Here’s why it loops: in Flexible mode, visitors connect to Cloudflare over HTTPS, but Cloudflare connects to your origin server over plain HTTP. Meanwhile, your server (correctly) tries to force HTTPS, so it redirects that request back to HTTPS. Cloudflare receives the redirect, connects again over HTTP, gets redirected again — and the loop is born.

The fix: In your Cloudflare dashboard, go to SSL/TLS → Overview and change the encryption mode from Flexible to Full or, ideally, Full (Strict). Full (Strict) requires a valid SSL certificate on your origin server — which any good host provides free. Then purge the Cloudflare cache (Caching → Configuration → Purge Everything) and wait a couple of minutes for the change to propagate.

⚠️
Never use Flexible SSL

Beyond causing redirect loops, Flexible mode is insecure — the connection between Cloudflare and your server is unencrypted. Always use Full (Strict) with a valid certificate on your origin. Every Copahost plan includes free SSL, so there’s no reason to run Flexible.

Cause #2: Conflicting HTTPS redirects (.htaccess or plugins)

The second most common cause is duplicate redirect rules — two different systems both trying to force HTTPS, bouncing the request back and forth. This happens when, for example, Cloudflare’s “Always Use HTTPS” is on and your .htaccess also forces HTTPS, or when an SSL plugin duplicates a rule already in the server config.

The fix — pick one redirect authority. Decide whether Cloudflare, your server (.htaccess), or a plugin handles the HTTP-to-HTTPS redirect, and remove it from the others. If you manage redirects in .htaccess, check for a force-HTTPS block like this and make sure it isn’t duplicated elsewhere.

One specific Cloudflare trigger to check: the Always Use HTTPS toggle (under SSL/TLS → Edge Certificates). When it’s on, Cloudflare redirects every HTTP request to HTTPS — which is fine on its own, but if your server also forces HTTPS, the two stack into a loop. Turn off one of them: let Cloudflare handle it with Always Use HTTPS, or let your server handle it in .htaccess, but not both.

RewriteEngine On RewriteCond %{HTTPS} off RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

SSL plugins like Really Simple SSL or WP Force SSL add their own HTTPS enforcement — if Cloudflare or your server already handles it, deactivate the plugin’s redirect to break the loop. The rule of thumb: one system forces HTTPS, the others stay out of it.

Cause #3: Wrong WordPress URL settings

On WordPress, a mismatch between your two site URLs is a classic trigger. If the WordPress Address (URL) and Site Address (URL) don’t match — one has www and the other doesn’t, or one is http and the other https — WordPress redirects between them endlessly.

The fix: In the dashboard, go to Settings → General and make both fields identical, using your canonical form (e.g. both https://yoursite.com). If the loop locks you out of the dashboard, you can set them in your wp-config.php file instead:

define( 'WP_HOME', 'https://yoursite.com' ); define( 'WP_SITEURL', 'https://yoursite.com' );

Cause #4: The loop only happens on wp-admin

A very specific WordPress case: the site loads fine, but logging in to /wp-admin triggers the loop. The usual culprit is the FORCE_SSL_ADMIN constant in wp-config.php, especially combined with a proxy like Cloudflare. When set to true behind a proxy that connects over HTTP, WordPress keeps trying to force the admin to HTTPS in a loop.

The fix: find this line in wp-config.php and, if the loop is admin-only, try removing it or ensuring your proxy passes the correct HTTPS header:

define( 'FORCE_SSL_ADMIN', true );

For a full account-access walkthrough, see our WordPress login guide.

Cause #5: Browser cookies and cache

Redirect loops can be cached, both in your browser and on the server. Sometimes the underlying problem is already fixed, but a stale cookie or cached redirect keeps showing you the error.

The fix — clear every cache in the chain, in order. A redirect loop can be cached at several layers, so clear them from the visitor’s side inward:

  • Browser: clear cookies and cache for the affected domain, or test in an incognito window to confirm this is the cause.
  • Caching plugin: if you can reach wp-admin, clear the cache in your caching plugin (WP Rocket, LiteSpeed Cache, W3 Total Cache). See our guide to cache plugins.
  • Hosting cache: clear any server-level cache from your hosting panel.
  • Cloudflare: if you use it, purge everything under Caching, Configuration, Purge Everything.

Because a cached redirect keeps looping even after the real fix, always clear these caches after changing any SSL or redirect setting — otherwise you’ll think the fix failed when it actually worked.

How to diagnose which cause you have

If you’re not sure where the loop is coming from, your browser’s developer tools show the full chain. Open DevTools (F12), go to the Network tab, reload the page, and watch the sequence of requests: you’ll see the URLs bouncing back and forth, which tells you exactly which two points are looping (HTTP↔HTTPS, www↔non-www, or a specific path). Knowing the pattern points you straight to the cause.

If you use Cloudflare, there’s a quick diagnostic trick: temporarily enable Development Mode (under the Caching tab). This bypasses Cloudflare’s cache and serves your origin directly for three hours. If the loop disappears with Development Mode on, the problem is Cloudflare’s cache or edge settings; if it persists, the loop is coming from your origin server or WordPress. Either way, it narrows down where to look.

The pattern you seeLikely cause
Loop right after enabling Cloudflare or changing SSLCloudflare Flexible SSL (Cause #1)
HTTP bouncing to HTTPS and backDuplicate HTTPS redirects (Cause #2)
www bouncing to non-www and backWrong WordPress URLs (Cause #3)
Loop only on /wp-adminFORCE_SSL_ADMIN (Cause #4)
Works in incognito, fails in normal windowBrowser cookies/cache (Cause #5)

Other, less common causes

If none of the above fits, check these:

  • A redirect loop after an SSL certificate renewal. Some hosting panels re-enable HTTPS redirection automatically when a certificate renews, recreating a duplicate rule. Recheck your panel’s redirect settings.
  • A Cloudflare Page Rule or Redirect Rule pointing a URL to itself, or conflicting with a server rule on a specific path. Review any rules scoped to the looping URL.
  • Malware. If redirects send visitors to random spammy sites rather than a clean HTTP↔HTTPS loop, your site may be compromised — scan it with a security plugin.
  • A domain pointing to itself in a forwarding rule. Check your DNS and any forwarding configuration.
  • HSTS forcing the loop. If you have HSTS (HTTP Strict Transport Security) enabled, the browser is told to always use HTTPS for your domain and remembers it. If your origin then redirects HTTPS back to HTTP, you get a loop that’s hard to clear — because the browser enforces HTTPS even after you fix the server. Make sure your origin never redirects HTTPS to HTTP, and if you recently enabled HSTS by mistake, you may need to clear the HSTS setting for the domain in your browser (chrome://net-internals/#hsts in Chrome).
  • A subdomain with different SSL settings. If the loop happens on a subdomain (like shop.yoursite.com) but not the main domain, the subdomain may have its own SSL configuration in Cloudflare or a separate server setup. Check the SSL/redirect settings scoped to that specific subdomain.
SSL done right, from the start

Most redirect loops trace back to SSL misconfiguration. Copahost includes free SSL on every plan, with cPanel and support to help you set HTTPS up correctly — so loops like this never take your site offline.

See web hosting plans

Frequently asked questions

What does ERR_TOO_MANY_REDIRECTS mean?
It means your browser got stuck in a redirect loop — one URL redirects to another, which redirects back, endlessly. After about 20 hops the browser gives up and shows the error. It’s caused by a configuration conflict, not a problem with your browser itself.

What is the most common cause of ERR_TOO_MANY_REDIRECTS?
On sites using Cloudflare, it’s the SSL/TLS mode set to “Flexible” while the origin server forces HTTPS. Switching Cloudflare to “Full” or “Full (Strict)” fixes the majority of cases. Outside Cloudflare, duplicate HTTP-to-HTTPS redirect rules are the top cause.

How do I fix ERR_TOO_MANY_REDIRECTS in WordPress?
Check three things in order: your Cloudflare SSL mode (set it to Full), your WordPress Address and Site Address under Settings, General (make them identical), and your .htaccess for duplicate HTTPS redirects. Clear all caches after any change.

Why does the error only appear when I try to log in to wp-admin?
That’s usually the FORCE_SSL_ADMIN constant in wp-config.php conflicting with a proxy like Cloudflare that connects over HTTP. Correcting that constant or your proxy’s HTTPS headers resolves the admin-only loop.

Can I fix ERR_TOO_MANY_REDIRECTS on a site I don’t own?
Only partially. If it’s caused by your browser’s cookies or cache, clearing them (or using incognito) may let you access the site. If the loop is in the site’s server configuration, only the site owner can fix it.

Related guides

This error connects to several others — see our guides on WordPress login and wp-admin, the .htaccess file, the wp-config.php file, and our hub of common WordPress errors.

Conclusion

ERR_TOO_MANY_REDIRECTS looks alarming but almost always comes down to one thing: two systems disagreeing about how to redirect a request. Work through the causes in order — start with Cloudflare’s SSL mode (set it to Full), then check for duplicate HTTPS redirects, then your WordPress URLs, then cookies. Use your browser’s Network tab to see exactly where the loop happens, pick a single system to handle redirects, and clear every cache after the fix. Follow that order and you’ll resolve the loop quickly — and know how to prevent it next time.

Share the Post:
Picture of Gustavo Gallas

Gustavo Gallas

Graduated in Computing at PUC-Rio, Brazil. Specialized in IT, networking, systems administration and human and organizational development​. Also have brewing skills.