ERR_TOO_MANY_REDIRECTS is one of those errors that can stop a site from loading entirely while giving you almost no useful information about what is actually wrong. The browser has followed a chain of redirects, each one pointing to another URL, and after hitting its limit it gives up and displays the error. The underlying problem is a configuration conflict somewhere in your stack that causes a redirect cycle rather than a redirect that resolves to a final page.
The frustrating part is that this error can come from several different places: Cloudflare, your .htaccess file, WordPress URL settings, a redirect plugin, or even a combination of multiple conflicts. This guide works through each cause in order from most to least common, with specific instructions for diagnosing and fixing each one.
Quick Summary
- The most common cause on Cloudflare-proxied sites is Cloudflare SSL mode set to Flexible combined with a server-side HTTPS redirect rule
- Conflicting redirect rules in .htaccess, WordPress URL settings, and redirect plugins are the next most common causes
- Clearing your browser cookies and cache eliminates locally stored redirect instructions that may be masking a resolved issue or complicating diagnosis
- Browser developer tools show the full redirect chain, which tells you exactly where the loop is happening
- The fix almost always involves either changing Cloudflare SSL mode to Full or correcting a .htaccess redirect rule
How a Redirect Loop Happens
A redirect is a server instruction that tells a browser to go to a different URL. When you visit an HTTP version of a URL and the server redirects you to the HTTPS version, that is a single redirect resolving correctly to a final destination. A redirect loop occurs when the final destination of one redirect is itself a URL that triggers another redirect back to where you started, or when the chain of redirects cycles through URLs indefinitely without ever reaching a page with a 200 OK status.
Browsers limit the number of redirects they will follow before giving up to prevent infinite loops from consuming resources. Chrome and Firefox typically stop after around 20 redirects and display the ERR_TOO_MANY_REDIRECTS error. The error does not mean 20 different destinations are involved. It usually means the same two or three URLs are being redirected to each other repeatedly until the limit is hit.
The redirect cycle is always caused by a configuration conflict somewhere. Two rules each try to enforce their own version of the correct URL, and each redirect triggers the other. Understanding where your redirects are being generated is the starting point for every fix in this guide.
Step 1: Clear Cookies and Test from Incognito
Before investigating server configuration, eliminate your local browser state as a variable. Some redirect loops persist in your browser after the underlying configuration issue has been resolved because cookies set during the loop are still present. These cookies can instruct the browser to follow a redirect on every request, even when the server is no longer generating the loop itself.
Open an incognito or private browser window and try loading your site. Incognito mode starts with no cookies or cached data. If the site loads correctly in incognito, the issue is in your browser's stored data rather than your server configuration. Clearing your cookies and browser cache for your domain should resolve it.
If the site still loops in incognito, the problem is in your server configuration and the remaining steps apply.
Step 2: Trace the Redirect Chain in Browser DevTools
Before changing anything, identify where the redirects are coming from. This takes two minutes and tells you exactly which part of your stack is generating each redirect, which prevents you from changing the wrong thing.
Open Chrome and press F12 to open DevTools. Navigate to the Network tab and check the Preserve log checkbox. Clear any existing entries, then type your domain into the address bar and press Enter. You will see a sequence of requests appear. Click on each one with a 301 or 302 status code and look at the Headers tab for the Location header, which shows where that redirect is pointing.
Trace the chain from start to finish. A typical Cloudflare Flexible SSL loop looks like this: your domain loads over HTTPS, Cloudflare connects to your server over HTTP, your server redirects HTTP to HTTPS, which goes back to Cloudflare, which connects to your server over HTTP again, and so on. A .htaccess loop might redirect from the www version to the non-www version while another rule redirects from non-www back to www.
Knowing exactly which URLs are in the loop and whether the redirects are coming from the same server on every step or alternating between different points tells you directly which configuration to fix.
Step 3: Check Your Cloudflare SSL Mode
If your site uses Cloudflare, this is the first server-side configuration to check because it is by far the most common cause of this specific error. The problem occurs when Cloudflare SSL mode is set to Flexible.
In Flexible mode, Cloudflare accepts HTTPS connections from visitors and then connects to your origin server over HTTP on port 80. If your server has an .htaccess rule or a server configuration that redirects all HTTP traffic to HTTPS, a loop is created: Cloudflare sends an HTTP request to your server, your server redirects it to HTTPS, Cloudflare receives the redirect, connects again over HTTP, gets another redirect, and the cycle continues.
The fix is to change your Cloudflare SSL mode. Log into Cloudflare, select your domain, navigate to SSL/TLS, and click Overview. Change the encryption mode from Flexible to Full. Full mode tells Cloudflare to connect to your origin server over HTTPS, which means the server's HTTP-to-HTTPS redirect is never triggered in the first place.
If you have a valid, properly signed certificate on your origin server from Let's Encrypt, Sectigo, or another trusted authority, use Full (Strict) instead, which additionally verifies the certificate's validity. If your origin server only has a self-signed certificate, use Full rather than Full (Strict).
After changing the SSL mode, wait a minute or two and test your site again. This fix resolves the loop immediately in most cases.
Step 4: Review Your .htaccess File
If you are not using Cloudflare, or if you have already fixed the Cloudflare SSL mode and the loop persists, the .htaccess file is the next place to look. This file controls URL rewriting and redirect rules for Apache-based servers, which includes most cPanel hosting environments.
Access your .htaccess file through cPanel's File Manager. Navigate to the root of your domain's public_html directory, enable Show Hidden Files in the settings (since .htaccess is a hidden file), and click on it to view its contents.
Look for any RewriteRule or Redirect directives. A clean WordPress .htaccess contains only this block for permalink handling:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
Any additional redirect rules beyond this are worth examining. A common problematic pattern is two redirect rules that conflict with each other: one redirecting from www to non-www, and another redirecting from non-www to www. Another common issue is an HTTP-to-HTTPS redirect that is not conditioned on whether the request is already HTTPS, causing it to redirect HTTPS requests back to HTTPS.
A correctly written HTTP-to-HTTPS redirect in .htaccess should check whether the connection is already using HTTPS before redirecting:
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
The RewriteCond %{HTTPS} off condition ensures the redirect only fires when the request is not already over HTTPS. Without this condition, an HTTPS request can trigger the redirect to HTTPS again, creating a loop.
If you are using Cloudflare and have this type of redirect in .htaccess, be aware that in Flexible SSL mode, Cloudflare's connection to your server is always over HTTP, so the %{HTTPS} off check will always be true from the server's perspective, causing the loop described in Step 3. The real fix is the Cloudflare SSL mode change, not the .htaccess rule.
If your .htaccess has become complex or contains rules you cannot trace, the safest approach is to rename it to .htaccess.bak temporarily, which effectively disables it, and test whether the loop resolves. If it does, rebuild the file from scratch with only the rules you actually need.
Step 5: Check WordPress URL Settings
If your site runs WordPress, the WordPress Address and Site Address settings in the admin dashboard generate redirects when they do not match the URL visitors are actually using. These settings are in Settings and then General.
WordPress Address is the URL where WordPress core files are installed. Site Address is the URL visitors use to access the site. Both should use the correct protocol and match your domain exactly. If WordPress Address is set to http://yourdomain.com while your server is serving the site over HTTPS, WordPress will generate a redirect from HTTPS to HTTP to match its own setting. If a different rule is simultaneously redirecting from HTTP to HTTPS, the loop is complete.
Update both fields to use https:// if your site is on HTTPS. Save and test. If you cannot access the WordPress admin because the loop prevents you from logging in, you can update these values directly in the database using phpMyAdmin. In the wp_options table, find the rows with option_name values of siteurl and home, and edit the option_value to the correct HTTPS URL.
Alternatively, you can set these values directly in wp-config.php by adding these lines before the comment that reads "That's all, stop editing!":
define('WP_HOME', 'https://yourdomain.com');
define('WP_SITEURL', 'https://yourdomain.com');
These constants override the database values and take effect immediately without needing to access the admin dashboard.
Step 6: Check Redirect Plugins and Platform Settings
If you have a redirect management plugin installed, check whether it contains any rules that create a cycle. Plugins like Redirection or Yoast SEO's redirect manager can generate conflicts with server-level redirects in .htaccess, particularly if both try to enforce the same HTTPS or www canonical redirect simultaneously.
Temporarily deactivating all plugins and testing whether the loop resolves is the quickest way to confirm whether a plugin is involved. If the loop clears after deactivation, reactivate plugins one at a time and test after each one until the loop returns. The most recently activated plugin before the loop reappears is the likely source.
For WooCommerce sites or sites using a reverse proxy or load balancer in front of the web server, HTTP_X_FORWARDED_PROTO headers may affect how the server detects whether a request is HTTP or HTTPS. If the server does not correctly interpret these headers, it may treat HTTPS requests as HTTP and redirect them, creating a loop. This is a less common scenario but worth investigating if the other steps do not resolve the issue.
Confirming the Fix
After making changes, test your site from a fresh incognito window to confirm the loop is fully resolved. Use an online redirect checker like httpstatus.io or redirect-checker.org to trace the full redirect chain and confirm it resolves to a single 200 OK status rather than a chain of 301s.
Also confirm that your intended redirects are still working correctly. If you rely on www to non-www canonicalization or HTTP to HTTPS redirection, verify these still redirect as expected rather than producing errors after your changes.
If you made changes to Cloudflare SSL mode, allow a few minutes for the change to propagate across Cloudflare's edge network before testing.
Managing Redirects Through WHMCS
If your hosting is managed through our client portal, you can access cPanel directly from your WHMCS account to edit your .htaccess file through the File Manager or to check SSL/TLS status. Navigate to My Services, click on your hosting package, and use the cPanel login link in the service details.
If you are unable to access your site due to the redirect loop and are having difficulty diagnosing the cause, open a support ticket from your WHMCS client area with your domain name, a description of when the issue started, and any recent changes you made to your Cloudflare settings, .htaccess, or WordPress configuration. Our team can review server-level logs and your current redirect configuration to identify the source of the loop.
Gotekky
Need help deciding what to do next?
Tell us what you are seeing and what outcome you need. We will identify whether a managed service, scoped project or paid technical assessment is the right next step.