How to Fix the ERR_TOO_MANY_REDIRECTS Error (and Why It Happens)

TL;DR: The Quick Recovery Checklist

If you need the site back online immediately, try these steps in order:

Nuke the site's cookies: Don't clear your whole history. Just delete the cookies for that specific domain and refresh.
Check your Cloudflare SSL toggle: If you use Cloudflare, change the SSL/TLS setting from "Flexible" to "Full". This fixes about 80% of redirect loops.
Kill the plugins: If you're on WordPress, rename your /wp-content/plugins folder to /plugins_old via FTP to see if the site loads.
Audit your .htaccess or Nginx config: Look for conflicting rules that force HTTP and HTTPS at the same time.

What exactly is a redirect loop?

Think of this error as a digital "he-said-she-said." The browser gets stuck in a loop where URL A tells it to go to URL B, but URL B points right back to URL A. Most modern browsers, like Chrome, will attempt this "ping-pong" match 20 times before giving up and throwing the ERR_TOO_MANY_REDIRECTS screen to save your CPU from a meltdown.

1. The "Flexible SSL" Trap

This is the leading cause of loops today. When using a CDN like Cloudflare with the "Flexible" setting, the CDN talks to your server over plain HTTP (Port 80). If your server is configured to automatically redirect all HTTP traffic to HTTPS, it sends the browser back to the CDN. The CDN, still thinking it should use HTTP, asks the server again. The loop repeats forever.

2. Conflicting Server Directives

Server configuration files like .htaccess (Apache) or nginx.conf are powerful but brittle. A single misplaced line can create a conflict between your www and non-www versions, or between HTTP and HTTPS protocols.

3. CMS Configuration Errors

WordPress stores your site's home and site URL in the database. If these are set to http://example.com but your server forces https://, the application and the server will fight over which protocol to use.

Step-by-Step Fixes

Fix 1: Inspect the Chain with Curl

Before you start changing settings, verify what the server is actually doing. You don't need a browser for this. Open your terminal and run:

curl -IL https://yourwebsite.com

Watch the output. If you see a long list of HTTP/1.1 301 Moved Permanently responses followed by the same URL over and over, you've confirmed the loop is on the server side, not your local machine.

Fix 2: Sync Cloudflare and Your Origin Server

If you use Cloudflare, the fix is usually a single click:

Log in to your Cloudflare dashboard.
Navigate to SSL/TLS > Overview.
Switch the encryption mode to Full or Full (Strict).

This tells Cloudflare to communicate with your server over HTTPS (Port 443). Just make sure you have an SSL certificate installed on your origin server—even a free Let's Encrypt or self-signed cert will work.

Fix 3: Clean Up Nginx Configs

Check your site's configuration file, typically found in /etc/nginx/sites-available/. A common mistake is placing a generic redirect inside a block that is already listening on port 443.

# THE WRONG WAY (Causes Loops)
server {
    listen 443 ssl;
    server_name example.com;
    return 301 https://example.com$request_uri;
}

Instead, keep your concerns separate. Use one block for the HTTP to HTTPS jump, and another for the actual site content:

# THE RIGHT WAY
server {
    listen 80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;
    # Your actual site logic goes here
}

Fix 4: Hardcode WordPress URLs

If you can't log in to the /wp-admin dashboard because of the loop, you can override the database settings manually. Add these two lines to your wp-config.php file, just above the "That's all, stop editing!" comment:

define('WP_HOME','https://example.com');
define('WP_SITEURL','https://example.com');

Prevention and Best Practices

When managing complex networks or VPCs, it is easy for traffic to get misrouted between load balancers and origin servers. I often use ToolCraft’s Subnet Calculator to double-check CIDR blocks when setting up firewall rules. Keeping your IP ranges organized ensures that your proxy layers aren't accidentally stripping SSL headers or routing traffic back to the wrong gateway.

Always test new redirect rules using 302 (Temporary) status codes. Browsers cache 301 (Permanent) redirects very aggressively. If you accidentally create a loop with a 301, your browser might keep redirecting you even after you've fixed the code on the server. Only switch to 301 once you've confirmed everything works in an Incognito window.

Final Verification

To make sure the ghost is truly gone, open your browser's Developer Tools (F12) and go to the Network tab. Check the "Disable Cache" box and reload the page. You should see a clean 200 OK status. If you see a single 301 redirect followed by a 200 OK, that is perfectly normal—it just means your HTTP-to-HTTPS redirect is working exactly as intended.