Guide Errors & Troubleshooting

How to trace and fix a redirect loop

Two redirects are fighting over the same request, and the browser is caught between them — here is how to work out which one is wrong.

iFastHosting Support Team Updated 26 August 2026 8 min read Intermediate

The browser gives up with a message along the lines of "This page isn't redirecting properly" or ERR_TOO_MANY_REDIRECTS. Nothing is actually broken in the sense of crashed code — the server is working exactly as instructed, and the instructions it has been given send the visitor back and forth between two addresses forever, with the browser eventually refusing to follow any further.

Fixing it means finding which of two or more rules disagrees with the others about where a request should land, and that is almost always one of a small number of places.

Where redirects actually live

A single request can pass through several layers before it reaches your site, and any one of them can issue a redirect:

Your DNS or a domain-level forwarding setting at the registrar.
A CDN or proxy in front of your hosting, if you use one.
Rules in your site's .htaccess file.
A setting inside your CMS itself — WordPress's Site Address and Home URL fields, for example.
A redirect plugin, or code added to a theme's functions file.

A loop happens when two of these disagree — one insists on https://www.yourdomain.com, another insists on https://yourdomain.com without the www, and each undoes what the other just did.

Trace the actual chain first

Guessing which rule is wrong wastes time. Seeing the exact sequence of redirects tells you immediately. Use an online redirect checker tool, or check it yourself from the command line:

curl -IL https://yourdomain.com

This prints every redirect in order, with the address it moved to at each step. A genuine loop shows the same two or three URLs repeating. That pattern is the answer to "which rule is fighting which" — whichever two addresses keep alternating are the ones in conflict.

Browser dev tools work too

Open the Network tab, tick "Preserve log", and reload. Every redirect hop appears as its own row with a 301 or 302 status, in the exact order the browser followed them.

The usual causes, in order

1. A CMS setting and a server rule both forcing the same redirect

This is the most frequent cause of an HTTPS loop. Your CMS is configured to force HTTPS — through a setting or a plugin — while a CDN or proxy in front of the server is set to "flexible" SSL, meaning it talks to your server over plain HTTP even though the visitor sees HTTPS. The server sees an HTTP request, redirects to HTTPS as instructed, the CDN receives that and passes it on as HTTP again, and the loop repeats indefinitely. If you use a CDN, check its SSL mode is set to "full" rather than "flexible" so the whole chain speaks HTTPS consistently.

2. Conflicting www / non-www rules

One rule redirects the non-www version to www; another, somewhere else, redirects www back to non-www. Check .htaccess for both a RewriteCond testing ^www\. and one testing !^www\., and check your CMS's own URL settings for the version it expects. Only one direction should be enforced, in one place.

3. A redirect plugin and a manual .htaccess rule doing the same job

It is easy to add a redirect through a plugin, forget about it, and later add the equivalent rule directly into .htaccess — or the reverse. Two rules performing the same redirect rarely loop on their own, but a plugin rule and a manual rule that each add or strip a trailing slash, or each add or remove www, will fight indefinitely. Check your redirect plugin's rule list and compare it line by line against .htaccess.

4. A stale cached redirect

Browsers cache 301 permanent redirects aggressively — sometimes even after the server-side rule causing them has been removed. If you have just fixed the underlying rule and the loop persists, this is very likely why. Test the fix in a private or incognito window before concluding it has not worked; that rules out your own browser's cache as the cause.

5. A domain-level forward pointing at itself

If your domain has a forwarding rule set at the registrar level — separate from anything in your hosting — check that it is not pointing the domain back at itself, or at a URL that in turn redirects back to the original domain.

Fixing it safely

Change one rule at a time

When two rules are in conflict, removing both and adding a single clean replacement is safer than trying to edit each one to agree with the other. Comment out one candidate rule with a # at a time, retest with curl -IL, and keep the version of the redirect that produces a single, direct hop.

Once you've identified the conflicting rule, decide which single layer should own that redirect — normally the CMS or a redirect plugin, not both — and remove the duplicate from the other. Retest with the same curl -IL command until the chain shows one clean redirect, or none at all if the address was already correct.

If you can't get past the loop

Send us the output of curl -IL against the affected URL, or a screenshot of the Network tab with "Preserve log" ticked. That sequence of hops tells support exactly which layer is issuing the conflicting redirect, which is usually enough to resolve it without back-and-forth. Contact support with that detail included.

Frequently asked questions

Why did the loop start right after I installed an SSL certificate?

This is the single most common trigger. A plugin or setting forces HTTPS at the same time a server-level rule is also forcing it, or forcing it back to HTTP, and the two disagree about where the request should end up. Section three below covers it directly.

Does a redirect loop affect only one browser?

If it does, clear that browser's cache first. Browsers cache redirect responses aggressively, so a loop that has already been fixed on the server can keep reappearing in one browser until its cached copy expires or is cleared.