ERR_TOO_MANY_REDIRECTS

Error ERR_TOO_MANY_REDIRECTS appears when a browser is caught in a redirect loop: a server, or a chain of servers, keeps pointing the browser to a new address, which points it straight back again, until the browser gives up after roughly twenty hops. Chrome, Edge and Safari all report it when the same URL bounces between locations without ever returning a page. The message is the browser protecting itself from an endless round trip rather than a fault inside your machine.

What it means

A redirect is a normal server response: an HTTP status such as 301, 302, 307 or 308 that carries a Location header telling the browser to load a different URL. Browsers follow these automatically for convenience, but they cap the chain. When the count exceeds that cap — about twenty hops in Chrome — the browser stops and shows ERR_TOO_MANY_REDIRECTS.

The key fact is that the browser is not broken. Every individual redirect is a valid answer; the problem is the pattern. Address A redirects to B, and B redirects back to A, so the loop never terminates. The fix is almost always a server or proxy configuration change, and it is usually found by looking at where the chain goes rather than at the browser.

Loops can also be partly on your side. A cookie that a script expects to find, but which your browser rejects because of privacy settings or a stale value, can send a login or consent page back to itself. That is why clearing cookies for one site, and testing in a private window, is a quick way to separate a site misconfiguration from a local cookie problem.

Common causes

• An HTTP-to-HTTPS redirect loop, often from a reverse proxy or CDN that terminates TLS while the origin still forces HTTPS (for example, Cloudflare in “Flexible” SSL mode).
• Two rules fighting each other: the www version redirects to the bare domain while the bare domain redirects back to www.
• A consent, login or language page that redirects to itself because the cookie it depends on is blocked or never set.
• Conflicting application or CMS plugins, each forcing its own canonical redirect, that together form a loop.
• A path or rule that redirects a URL to itself, such as a catch-all rule matching the destination it points to.

How to fix it

1. Clear cookies and cache for the site, then retry in a private window. If the loop disappears there, a stale or blocked cookie was the cause and clearing it for that domain resolves it. Allow cookies for the site if a privacy extension is blocking them.
2. Check the CDN SSL/TLS mode. If the site sits behind Cloudflare, set SSL/TLS to Full or Full (strict), not Flexible. Flexible makes the edge talk to the origin over plain HTTP while the origin forces HTTPS, which is a textbook loop.
3. Make sure only one canonical redirect exists. Pick either www or the bare domain as canonical, and make the other redirect to it in a single hop. Remove any second rule that redirects back.
4. Inspect the chain from the command line. Follow the Location headers to see where it bounces:

   curl -sIL https://example.com/ | grep -i "^HTTP\|^location"

5. Disable conflicting redirect plugins or server rules. In WordPress and similar CMSs, turn off extra SEO or redirect plugins, and check .htaccess or nginx return rules for a duplicate that points back.

How to prevent it

Keep one source of truth for redirects. Decide early whether your canonical host is www or the bare domain, redirect the other to it once, and never add a second rule elsewhere that reverses it. When you change hosting, a CDN, or a TLS certificate, walk through the full chain yourself before publishing, because that is when split rules are most likely to appear.

Match your TLS setup end to end. If the edge talks HTTPS to the origin, give the origin a certificate the CDN trusts and use a strict mode. Avoid mixing modes between a proxy and the server behind it — a mismatch is the most common way a working site turns into a loop overnight. Test with a real request after every change.

Keep plugins and server rules lean. Each extra redirect plugin is another chance to create a cycle, so remove the ones you do not use and give the job to a single, understood rule. A five-minute check of curl output after a deployment is far cheaper than a broken site discovered by visitors.