Fix Redirect Loop (ERR_TOO_MANY_REDIRECTS) on Hosting

You open your site and see "ERR_TOO_MANY_REDIRECTS" or "This page isn't working — redirected you too many times." This is a redirect loop, and it's extremely common after migrating a site, installing SSL, or enabling Cloudflare. This guide explains the causes and walks through each fix so you can solve it in one place.

What is a redirect loop

A redirect loop is when your browser is redirected back and forth between URLs without ever finishing — for example A sends you to B, then B sends you back to A, over and over. Browsers have a redirect limit (usually around 20), and once it's exceeded they stop and show ERR_TOO_MANY_REDIRECTS instead of loading the page. Almost every case comes from conflicting redirect rules at the server or application level.

The most common causes

• Overlapping .htaccess rules — forcing www and non-www at the same time, or duplicate HTTP→HTTPS rules.
• Wrong WordPress Site URL — siteurl and home set to HTTPS while the server doesn't actually serve HTTPS.
• Cloudflare Flexible SSL — Cloudflare talks to the server over HTTP, but the server redirects to HTTPS.
• HTTPS-forcing plugins — plugins like Really Simple SSL duplicating an .htaccess rule.
• Stale cookies — an old redirect cookie cached in the browser.

A closer look at each common cause

Before you start fixing things, it helps to understand why each cause happens, because nearly every redirect loop comes down to "two sides disagreeing" about whether the site should be served over HTTP or HTTPS, on www or non-www. When two layers — say Cloudflare and your server, or an .htaccess rule and a plugin — each try to redirect in a different direction, the request gets bounced back and forth forever. Here is how each case actually arises and how to spot it.

Cloudflare SSL in Flexible mode

This is the single most common cause we see. When SSL/TLS is set to Flexible, Cloudflare accepts the visitor's request over HTTPS but talks to your origin server over plain HTTP. If your server has a rule that says "if the request is HTTP, redirect to HTTPS," the server sees Cloudflare's HTTP request and tells it to go to HTTPS — but Cloudflare turns that back into HTTP and sends it again, looping endlessly. A telltale sign: the loop disappears when you pause Cloudflare (grey-cloud DNS) and returns when the proxy is on (orange cloud), which points straight at the SSL mode.

Overlapping .htaccess rules

Many sites accumulate several redirect blocks over time — one forcing www, another forcing non-www, or one forcing HTTPS but written loosely enough to collide with another rule. This is especially common after installing a plugin, migrating hosts, or copying a rule from another site without removing the old one. The result is A → B then B → A immediately.

A wrong WordPress Site URL

The siteurl and home values in the WordPress database tell the site which URL it should live at. If they are set to https:// while the server isn't actually serving HTTPS (or Cloudflare is on Flexible), WordPress tries to redirect every request to HTTPS while the server treats it as HTTP and bounces it back, producing a loop. A classic symptom is the front end loading fine while /wp-admin loops, or the reverse.

www and non-www colliding

If you set www.yourdomain.com to redirect to yourdomain.com while another rule (or a CMS setting) pushes yourdomain.com back to www, the two rules fight each other. The request ping-pongs between the two hostnames until the browser gives up. The fix is to pick one direction and delete the opposite rule.

Fixing it case by case

Case 1 — Check .htaccess first

Open File Manager in DirectAdmin and look at the .htaccess file in public_html. If you find rules forcing both www and non-www, keep only one direction. Here is a correct non-www + HTTPS rule that does not loop:

The key is to keep all conditions in a single rule rather than splitting them into multiple blocks that bounce requests back and forth.

Case 2 — WordPress

For WordPress sites, check the Site URL in the database. In phpMyAdmin open the wp_options table and make sure siteurl and home match (both https if you use SSL). Or hard-lock them in wp-config.php:

Case 3 — Cloudflare

If you use Cloudflare, go to SSL/TLS → Overview and change the mode from Flexible to Full or Full (strict). Flexible makes Cloudflare connect to your server over HTTP while the server forces HTTPS, causing the loop — Full mode makes both ends speak HTTPS consistently.

Case 4 — Clear cookies and cache

After fixing the server side, clear your browser's cookies and cache for that domain, or test in an Incognito window to confirm the loop is really gone.

Using Developer Tools and curl to read the redirect chain

The fastest way to find where the loop happens is to look at the redirect chain — the ordered list of where the request gets forwarded. Two tools give you that instantly.

Read it in browser Developer Tools

Press F12 to open Developer Tools, go to the Network tab, and tick Preserve log so the log isn't cleared when the page redirects. Type the URL and hit Enter. You'll see a list of requests stacked up; every row with a 301 or 302 status is one redirect. Click a row and look at the Location field in its Response Headers to see where it was sent. If the destination URL keeps coming back to the same value, that's where the loop lives.

Inspect with curl from the command line

If you prefer the command line, curl gives a clean redirect chain without browser cache getting in the way. Use -I to fetch only headers and -L to follow every redirect:

The output shows the status and Location: for each hop. In a loop you'll see the Location alternate between the same URLs forever, and curl stops by itself with Maximum (50) redirects followed. A looping example:

This clearly shows yourdomain.com and www.yourdomain.com pushing against each other, meaning two conflicting www/non-www rules — keep only one direction. To see the hop count and HTTP code at a glance, use:

Learning to read a redirect chain is the single most useful skill for this problem. Once you know which URL points to which, you can trace straight back to the offending rule instead of guessing and fixing one spot at a time.

How to prevent it from happening again

• Pick one canonical direction — www or non-www, HTTP or HTTPS — and combine the redirect into a single rule.
• Don't run an HTTPS-forcing plugin alongside an .htaccess rule that does the same job.
• Install a real server SSL certificate (Let's Encrypt) instead of relying on Cloudflare Flexible.
• Back up .htaccess before every change so you can roll back instantly if something breaks.
• After migrating a site or changing domains, recheck siteurl/home and your redirect rules every time — don't copy old rules over without reviewing them.
• When enabling Cloudflare, set SSL/TLS to Full (strict) from the start and install a real origin certificate; this prevents loops at the source.
• Test with curl -sIL after every redirect change before calling it done, to confirm the chain ends at 200 rather than looping.

Frequently asked questions