ERR_TOO_MANY_REDIRECTS: what causes a redirect loop and how to fix it

What ERR_TOO_MANY_REDIRECTS means

A redirect tells the browser "the page you want is somewhere else, go there instead." A single redirect, or even two or three in sequence, is normal: a bare domain forwarding to www, or an old URL forwarding to its replacement. A loop happens when a URL redirects to a second URL that redirects back to the first, or to itself. Because the browser never reaches a page that actually returns content, it cuts the chain off and shows the error instead of hanging forever.

How the error appears

Chrome and Edge show "This page isn't working - redirected you too many times" with the error code ERR_TOO_MANY_REDIRECTS. Firefox shows "The page isn't redirecting properly." Safari says "Safari can't open the page because too many redirects occurred."

curl with the -L flag follows redirects the same way a browser does, and printing each hop shows exactly where the loop repeats:

curl -sIL https://example.com/ | grep -E "^(HTTP|location)"
HTTP/1.1 301 Moved Permanently
location: http://example.com/
HTTP/1.1 301 Moved Permanently
location: https://example.com/
HTTP/1.1 301 Moved Permanently
location: http://example.com/

That pattern, http to https and back to http, is the single most common shape this error takes. curl stops on its own default limit (50 redirects) rather than following it forever, and the repeating location lines make the loop obvious without needing to open a browser at all.

What causes a redirect loop

• An HTTP-to-HTTPS mismatch between a proxy or CDN and the origin. This is the classic case. If Cloudflare's SSL/TLS mode is set to Flexible, Cloudflare terminates TLS at the edge and connects to the origin over plain HTTP. If the origin server also has a rule that redirects every HTTP request to HTTPS (a common security default), the origin sends the browser back to HTTPS, Cloudflare downgrades to HTTP again on the next hop, and the two settings fight forever.
• www and non-www rules pointing at each other. One rule redirects the bare domain to www, and a separate rule, often added later by a different admin or plugin, redirects www back to the bare domain.
• A WordPress siteurl or home mismatch. If the site's configured URL in the database does not match the URL visitors actually use (a leftover staging URL, a scheme mismatch after adding SSL), WordPress keeps redirecting toward the configured value.
• Cookies the server expects but never receives, or a login redirect that fails silently. A page that redirects unauthenticated visitors to a login step, which then redirects back to the same page because the session cookie was never set (often blocked by a browser's third-party cookie rules or a missing Secure/SameSite attribute), loops indefinitely.
• Trailing-slash or language-prefix rules that conflict. One rule adds a trailing slash, another strips it; one rule adds a language prefix based on browser locale, another strips it for canonical URLs, and the two cancel each other out.
• A caching layer serving a stale redirect. A CDN or reverse proxy cached an old 301 that pointed at a URL which, since changed, redirects back to the original.

How to tell whose fault it is

If the loop happens for every visitor on every network, it is a server or CDN configuration problem, not something local. If it happens only for you, clear cookies for the site first since a bad or expired session cookie causes a large share of single-visitor loops. Running an HTTP check from several locations settles it in one request: if the same redirect chain (or the same failure) shows up from every location, the fix is on the server side.

How to fix ERR_TOO_MANY_REDIRECTS

If you are a visitor

1. Clear cookies for the site. In Chrome, click the padlock or tune icon next to the address bar, open site settings, and clear cookies and site data for that domain only.
2. Try an incognito or private window. This rules out a browser extension or a stored cookie as the cause without touching your regular profile.
3. Try a different network, such as mobile data instead of Wi-Fi. Some corporate or ISP-level proxies rewrite requests in ways that create a loop only on that network.
4. Clear the browser's cache in case a redirect response itself was cached from before the site was fixed.

If you run the site

1. Check your CDN's SSL mode against your origin's redirect rule. In Cloudflare, open SSL/TLS and set the mode to Full or Full (strict), not Flexible, whenever the origin redirects HTTP to HTTPS. Full still lets the origin use a self-signed certificate; Full (strict) requires a valid one.
2. Trust the forwarded protocol header instead of redirecting blindly. When a proxy sits in front of your app, the origin needs to redirect based on X-Forwarded-Proto, not on the raw connection, which always looks like HTTP from behind the proxy. In nginx:

   if ($http_x_forwarded_proto = "http") {
       return 301 https://$host$request_uri;
   }

   and make sure the CDN or load balancer is actually setting that header on every request.
3. Check your redirect rules in order, including .htaccess, nginx server blocks, application-level middleware, and any CDN page rules, for two rules that point at each other. A common Apache pattern that loops behind a proxy:

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

   fails the same way as the nginx case above, since %{HTTPS} reads the connection the proxy makes, not the one the visitor made; check %{HTTP:X-Forwarded-Proto} instead.
4. Fix the WordPress site URL if that applies: in wp-admin > Settings > General, confirm both the WordPress Address and Site Address match the URL visitors actually use, protocol included. If the admin panel itself is inaccessible because of the loop, set WP_HOME and WP_SITEURL directly in wp-config.php.
5. Pick one canonical form and redirect everything else to it once, not in a chain: www or non-www, trailing slash or not, one rule per decision rather than several rules layered by different tools over time.
6. Purge the CDN cache after fixing the rule, since a cached 301 or 302 keeps sending the old response until it expires or is purged.

Related errors

• 3xx redirect status codes explains what 301, 302, 303, 307 and 308 each mean.
• 301 vs 302 covers when a redirect should be permanent versus temporary, which matters for search engines and caching, not just loops.

How to prevent ERR_TOO_MANY_REDIRECTS

A redirect loop is almost always introduced by a config change: a new CDN, a new SSL certificate, a plugin update, or a migration that touched the site URL. An HTTP check that watches the response code and follows redirects on a schedule catches a loop the moment it appears, from 300+ checkpoints in 158 cities, rather than waiting for a support ticket. HostTracker has monitored websites since 2004 and can alert by email, SMS, voice call, Slack, Telegram and more the moment a check starts failing.

Frequently asked questions

How many redirects does a browser allow before giving up?

Chrome and Chromium-based browsers stop at around 20. curl's default limit with -L is 50. The exact number varies by client, but any of them will eventually stop rather than follow a loop forever.

Why does the loop only happen right after I moved to Cloudflare (or another CDN)?

Almost always the SSL/TLS mode. Flexible mode talks plain HTTP to the origin; if the origin insists on HTTPS, the two sides redirect each other indefinitely. Switching to Full or Full (strict) usually resolves it immediately.

Can a browser extension cause this?

Yes, particularly extensions that force HTTPS, rewrite requests, or manage cookies. Testing in an incognito window with extensions disabled rules this out quickly.

Does this affect SEO?

Yes. Search engine crawlers give up on a redirect loop the same way a browser does, and a looping URL will not get indexed or will drop out of the index if it used to work.

I only see the error on one specific page, not the whole site. What's different about it?

Check for a page-specific rule: a login-required page, a cached old redirect for that one URL, or a trailing-slash mismatch that only exists on that route. Compare the exact redirect chain for that URL against a working page with curl -sIL.

Is a single redirect (like non-www to www) something to fix?

No, one redirect on its own is normal and expected. Only a repeating chain that never reaches a final 200 response is the problem this error describes.