Guide Errors & Troubleshooting

How to fix ERR_TOO_MANY_REDIRECTS

Your browser gave up after looping between the same handful of URLs — here is how to find which one is sending you back.

iFastHosting Support Team Updated 26 August 2026 8 min read Intermediate

Chrome calls it ERR_TOO_MANY_REDIRECTS. Firefox says "The page isn't redirecting properly". Safari says "Safari can't open the page because too many redirects occurred". They are all describing the same thing: your browser followed a redirect, landed on a URL, was told to redirect again, and kept going until it hit an internal limit — usually around twenty hops — and gave up rather than loop forever.

Nothing is broken on the visitor's end and nothing has been lost. This is a configuration conflict, almost always between two rules that each think the other one should handle the request, and it is entirely fixable once you find which two rules are arguing.

See the loop for yourself

Run curl -IL https://yourdomain.com from a terminal, or open your browser's network tab with "preserve log" on and reload. Either shows you the actual chain of redirects — which URL sent you to which — instead of the browser's generic error page. That chain almost always makes the cause obvious immediately.

The causes, in the order worth checking

1. HTTPS is being forced by two layers at once

This is the single most common cause, and it happens when a CDN or proxy in front of your site is set to a mode often called "Flexible" SSL. In that mode, the CDN talks to visitors over HTTPS but talks to your actual server over plain HTTP. If your site also has a rule — in .htaccess, in WordPress, or in application code — that forces every HTTP request to redirect to HTTPS, you get a loop: the CDN forwards over HTTP, your server redirects back to HTTPS, the CDN receives that as another HTTP request, and it repeats forever.

The fix is to change the CDN or proxy's SSL mode to "Full" or "Full (strict)", so it talks to your server over HTTPS as well. If you don't control a CDN and the site connects to the server directly, check for the same conflict between an SSL rule in .htaccess and one added separately by a plugin.

2. WordPress thinks the site is HTTPS when the connection isn't

If your WordPress address and site address in Settings > General are set to https:// but the certificate isn't actually installed and serving correctly, WordPress redirects every HTTP request to HTTPS while the server has nothing to serve there, and the browser bounces straight back. Confirm the certificate is live by loading https://yourdomain.com directly in a new tab — if that itself fails to load cleanly, this is your cause and the fix is installing the certificate before enforcing it.

3. www and non-www rules point at each other

A rule that redirects www.yourdomain.com to yourdomain.com, sitting alongside a second rule — often added later, by a different tool — that redirects the other way, produces an infinite loop between the two hostnames. Open .htaccess and search for every line containing RewriteRule or Redirect that mentions www. Keep exactly one direction and remove the other.

4. A plugin or security tool is redirecting on top of a server rule

Security and SEO plugins commonly add their own "force HTTPS" or "force www" option. If that setting is switched on at the same time as an equivalent rule already sitting in .htaccess, the two can conflict in exactly the way described above, even though each one individually would work fine. Deactivate plugins one at a time — starting with anything related to security, redirects or SSL — and reload between each one.

5. A stale redirect is cached in your own browser

Once you believe you've fixed the underlying rule, test in a private/incognito window before concluding it didn't work. Browsers cache 301 (permanent) redirects aggressively, sometimes for the life of the browser session, so your own machine can keep looping on a rule that no longer exists anywhere on the server. Clearing cached images and files for that one site, or simply using a different browser, tells you immediately whether the fix worked.

Reading .htaccess for the actual conflict

If the causes above don't immediately match what you're seeing, the fastest route is to read the file directly. Open .htaccess in the root of your site and look for any line starting with RewriteCond or RewriteRule that mentions HTTPS, SERVER_PORT or a hostname. Comment blocks out one at a time by putting a # at the start of each line, reloading between each change, until the loop stops — the block you just disabled is the one to rewrite properly rather than delete outright.

Keep a copy before you edit

Download a copy of .htaccess before changing it. If a rule you remove turns out to have been doing something else useful — enforcing HTTPS everywhere is usually there for a reason — you want to be able to put it back rather than reconstruct it from memory.

If none of that clears it

Send us the output of curl -IL against the affected URL along with a note of any CDN or proxy service sitting in front of the site. That chain of redirects is the one piece of evidence that identifies the exact conflict, and with it support can usually confirm the fix in one exchange rather than several rounds of guessing.

Frequently asked questions

Is a redirect loop a sign my site has been hacked?

Rarely. Almost every redirect loop is a configuration conflict — two rules each sending the browser to the other. Malware-driven redirects usually send visitors to an unrelated third-party site rather than looping on your own domain, which is a useful way to tell the two apart at a glance.

Why does it work for me but not for a visitor, or the other way round?

Because a 301 redirect is cached aggressively by browsers. If you fixed the loop after your browser had already cached the bad redirect, you will keep looping until you clear that one site's data, even though a fresh visitor sees the fix immediately.