Fixing ERR_TOO_MANY_REDIRECTS (redirect loops)

ERR_TOO_MANY_REDIRECTS means two things are fighting over how a request should be handled, and they disagree. Most often it's a Force HTTPS redirect rule on the server plus a proxy or CDN (usually Cloudflare) that's also rewriting the connection, so each side keeps bouncing the request back to the other. Fix it by making sure only one layer owns the HTTPS decision, then check for a WordPress URL mismatch or a stacked .htaccess rule as the next most common cause.

The fastest way to confirm it's a loop and not something else: open the URL in an incognito window and watch the browser's network tab. If you see the same URL (or two URLs) repeating over and over with 301 or 302 status codes, that's a loop. A single redirect that lands somewhere unexpected is a different problem.

Cause 1: Cloudflare SSL mode conflicting with Force HTTPS

If your domain proxies through Cloudflare (orange-cloud DNS), Cloudflare has its own SSL/TLS encryption mode that controls how it talks to your origin server. The loop happens when Cloudflare is set to Flexible while your hosting also has Force HTTPS turned on:

• Flexible mode means Cloudflare connects to your origin over plain HTTP, even though the visitor's browser is talking to Cloudflare over HTTPS.
• Your server sees an HTTP request and, because Force HTTPS is on, redirects it to HTTPS.
• Cloudflare receives that redirect, but since it's already presenting HTTPS to the visitor, it loops the request back as HTTP again.
• Repeat, forever, until the browser gives up with ERR_TOO_MANY_REDIRECTS.

The fix: in the Cloudflare dashboard, go to SSL/TLS and change the mode from Flexible to Full (or Full Strict if your certificate is valid and trusted, which it will be since our plans auto-issue and auto-renew Let's Encrypt certificates). Full mode tells Cloudflare to connect to your origin over HTTPS too, so there's no protocol mismatch left to loop on. If you're not using Cloudflare's proxy at all (grey-clouded, DNS-only), this isn't your cause, skip to the next section.

Cause 2: WordPress URL settings pointing at the wrong protocol

WordPress stores its home and site URL in the database, not just in configuration. If those are set to http:// while everything else on the site (server redirect, Cloudflare, browser) expects https://, WordPress itself will redirect every HTTP request it receives to its stored URL, which can create a loop if that stored URL doesn't match what's actually being served.

Check it two ways:

• In wp-config.php, look for WP_HOME and WP_SITEURL constants. If they're defined and hardcoded to http://, change them to https://.
• If those constants aren't defined in wp-config.php, the values live in the database (wp_options table, siteurl and home rows). You can fix them from Settings → General in wp-admin, but if wp-admin itself is stuck in the loop you won't be able to reach it. In that case, add the two constants to wp-config.php temporarily to force the correct protocol and break the loop, then clean up the database values once you're back in.

A mismatched URL after a domain migration or a site copied from staging is the usual trigger here, not something that happens on its own.

Cause 3: Stacked or duplicate redirect rules in .htaccess

If you've added a Force HTTPS rule to .htaccess by hand and cPanel's Force HTTPS Redirect toggle is also on, or if an old redirect rule from a previous fix never got removed, you can end up with two rewrite rules both trying to redirect the same request, sometimes to slightly different targets (with vs. without www, for example). Each rule fires, changes the URL slightly, and hands it back to the other rule.

To check: open .htaccess via File Manager or FTP and look for more than one block containing RewriteCond %{HTTPS} off or similar HTTPS/www redirect logic. Keep one, delete the rest. If you're not sure which one is authoritative, delete all manual HTTPS rules and rely on the cPanel Force HTTPS Redirect toggle under SSL/TLS Status instead, it's simpler to manage and won't drift out of sync with itself.

Order matters too. A redirect rule placed after a rewrite rule that already changed the URL can end up redirecting the changed version somewhere the original rule then changes back. Keep HTTPS/www canonicalization rules at the very top of .htaccess, before any application-level rewrites (WordPress's permalink block, for example).

Confirming the fix

After changing anything, clear your browser cache or test in a fresh incognito window, browsers cache redirect chains aggressively and will keep showing you the loop even after the server-side cause is gone. If the loop clears for you but visitors still report it, the difference is almost always their browser or a corporate proxy holding onto an old cached redirect: ask them to clear cache or try a different device.

If you're still stuck, check the error log for the domain. Redirect loops don't always throw PHP errors, but access logs will show you the exact chain of URLs being requested, which makes it obvious which rule is firing.

When to contact support

If you've checked Cloudflare's SSL mode, WordPress URL settings, and .htaccess rules and the loop persists, or if you're not comfortable editing .htaccess and risking a 500 error while you troubleshoot, open a ticket from the portal under Support → New ticket. A real person can check the server-side redirect configuration directly and tell you within minutes whether the conflict is on our end or in your DNS/CDN setup.