ERR_TOO_MANY_REDIRECTS: How to Fix It (All Browsers)

What Is ERR_TOO_MANY_REDIRECTS?

ERR_TOO_MANY_REDIRECTS is a browser error that occurs when a website gets stuck in an infinite redirect loop. Instead of loading the page, the browser keeps bouncing between URLs — and after hitting its redirect limit, it gives up and shows this error.

Every browser has a built-in redirect limit to prevent infinite loops from consuming resources. When a page exceeds that limit, the connection is terminated with an error message.

The underlying HTTP status codes in a redirect loop are usually 301 (permanent redirect) or 302 (temporary redirect). A typical loop looks like this: your browser requests URL A, the server responds with a 301 to URL B, URL B responds with a 301 back to URL A, and the cycle repeats until the browser hits its limit.

What Causes Redirect Loops?

Redirect loops happen when two or more redirect rules conflict with each other. The server sends the browser to a URL, and that URL sends the browser right back. Here are the most common causes:

• SSL/HTTPS misconfiguration — The most common cause. Your server forces HTTP-to-HTTPS, but your CDN or load balancer connects to the origin over HTTP, creating a loop: CDN → HTTP → server redirects to HTTPS → CDN strips HTTPS → HTTP → loop

• Cloudflare Flexible SSL — Cloudflare's Flexible SSL mode sends requests to your origin over HTTP. If your origin also has an HTTP-to-HTTPS redirect, you get an infinite loop between Cloudflare and your server

• Conflicting .htaccess rules — Multiple redirect rules in .htaccess that contradict each other, such as one rule forcing www and another forcing non-www simultaneously

• WordPress URL mismatch — WordPress Address (URL) and Site Address (URL) in Settings > General don't match, or one uses HTTP while the other uses HTTPS

• Stale browser cookies — Old cookies containing redirect instructions or session data that force the browser to a URL that no longer exists or has moved

• CDN or proxy cached redirects — Your CDN cached an old 301 redirect that now conflicts with your current server configuration

• Server configuration conflicts — Nginx or Apache config files with competing redirect blocks, such as redirecting in both the server block and .htaccess simultaneously

How to Diagnose a Redirect Loop

Before trying fixes, identify the exact redirect chain. This tells you exactly which URLs are involved and which redirect rules are causing the loop.

Method 1: Use curl to Trace Redirects

The fastest way to see a redirect chain is with curl in your terminal. The -I flag fetches headers only, -L follows redirects, and --max-redirs limits how many to follow:

# Trace redirect chain (limit to 10 hops)
curl -ILs --max-redirs 10 https://example.com 2>&1 | grep -i 'HTTP/\|location:'

# Example output showing a redirect loop:
# HTTP/2 301
# location: http://example.com/
# HTTP/1.1 301 Moved Permanently
# Location: https://example.com/
# HTTP/2 301
# location: http://example.com/
# (repeats...)

If you see the same two URLs alternating in the Location headers, you have confirmed a redirect loop. Note the HTTP status codes — 301 means permanent redirect (cached by browsers), 302 means temporary (not cached).

Method 2: Browser DevTools Network Tab

You can also trace redirects visually in Chrome DevTools:

• Step 1 — Open Chrome DevTools with F12 or Ctrl+Shift+I (Mac: Cmd+Option+I)

• Step 2 — Go to the Network tab and check Preserve log (this keeps entries across redirects)

• Step 3 — Load the page that triggers the error

• Step 4 — Look at the sequence of requests. Each redirect shows as a separate entry with status 301 or 302. The Location column shows where each redirect points

The Network tab shows the full redirect chain chronologically. You will see the pattern — typically two or three URLs repeating in a cycle. Use DNS Robot's HTTP Headers Checker to inspect response headers from outside your browser cache.

Method 3: Online Redirect Checker

If you do not have terminal access, use DNS Robot's Redirect Checker to trace the full redirect chain. Enter the URL and it will show every hop, status code, and final destination — or confirm that a loop exists. This is useful because it checks from a neutral location without your browser cookies affecting the result.

Fix 1: Clear Browser Cookies and Cache

Start with the simplest fix. Stale cookies or cached redirects in your browser can cause loops even when the server configuration is correct. This is especially common after a site migrates from HTTP to HTTPS — old cookies may still reference HTTP URLs.

Clear Cookies in Chrome

Clear cookies for the specific site rather than all cookies — this preserves your logins on other sites:

• Step 1 — Click the padlock icon (or tune icon) in the address bar next to the URL

• Step 2 — Click Site settings

• Step 3 — Click Clear data to remove cookies and cached data for that site only

• Step 4 — Reload the page

# Chrome keyboard shortcut to open Clear Browsing Data:
# Windows/Linux: Ctrl + Shift + Delete
# macOS: Cmd + Shift + Delete

Alternatively, go to chrome://settings/clearBrowserData, select Cookies and other site data and Cached images and files, set the time range to All time, and click Clear data.

Clear Cookies in Firefox and Safari

Firefox: Press Ctrl+Shift+Delete (Mac: Cmd+Shift+Delete), select Cookies and Cache, set time range to Everything, and click Clear Now.

Safari: Go to Safari > Settings > Privacy > Manage Website Data, search for the affected domain, select it, and click Remove. Then clear the cache with Cmd+Option+E.

Fix 2: Check SSL/HTTPS Configuration

SSL misconfiguration is the #1 cause of redirect loops. The most common scenario is a conflict between your CDN/proxy and your origin server about whether to use HTTP or HTTPS.

Here is what typically goes wrong: your CDN connects to the origin over HTTP (because it handles SSL termination), but the origin has an HTTP-to-HTTPS redirect. The origin sends the CDN back to HTTPS, the CDN strips it and sends HTTP again — infinite loop.

• Check your SSL certificate — Use DNS Robot's SSL Checker to verify your certificate is valid, not expired, and covers the correct domain

• Match protocols — If your CDN terminates SSL, either remove the HTTP-to-HTTPS redirect on your origin, or configure the CDN to connect to the origin over HTTPS

• Check force-HTTPS settings — If you have both a server-level redirect (Nginx/Apache) AND a CDN-level force-HTTPS, remove one of them

• Verify the X-Forwarded-Proto header — When behind a proxy, your origin should check this header instead of the raw connection protocol to determine if the original request was HTTPS

Fix 3: Fix Cloudflare Redirect Loops

Cloudflare is the most common trigger for ERR_TOO_MANY_REDIRECTS because of how its SSL modes work. The fix depends on which SSL/TLS encryption mode you are using.

The fix for 90% of Cloudflare redirect loops: change your SSL/TLS encryption mode from Flexible to Full or Full (Strict). This tells Cloudflare to connect to your origin over HTTPS, eliminating the HTTP-to-HTTPS loop.

Step-by-Step Cloudflare Fix

• Step 1 — Log in to the Cloudflare dashboard

• Step 2 — Select your domain

• Step 3 — Go to SSL/TLS > Overview

• Step 4 — Change encryption mode to Full (Strict) if you have a valid SSL certificate on your origin, or Full if you have a self-signed certificate

• Step 5 — Go to SSL/TLS > Edge Certificates and check if Always Use HTTPS is enabled. If your origin already redirects to HTTPS, disable this to avoid a double redirect

• Step 6 — Check Page Rules and Redirect Rules for any conflicting URL redirects

• Step 7 — Purge the Cloudflare cache: go to Caching > Configuration > Purge Everything

Fix 4: Fix .htaccess Redirect Rules (Apache)

On Apache servers, .htaccess is the most common location for redirect rules — and the most common place for redirect loops to originate. Conflicting rules, duplicate redirects, or missing condition checks can all create loops.

• Check for duplicate HTTPS redirects — If your hosting panel (cPanel, Plesk) forces HTTPS, remove the manual redirect from .htaccess

• Check RewriteCond conditions — Every RewriteRule that redirects should have a RewriteCond that prevents it from firing on URLs that already match. Without this, the rule fires on every request including the redirected one

• Watch the [L] flag — The [L] flag means 'last rule' but only for the current pass. If another .htaccess exists in a subdirectory, it runs again. Use [END] on Apache 2.4+ instead

• Check for proxy headers — Behind a CDN, use %{HTTP:X-Forwarded-Proto} instead of %{HTTPS} to detect the original protocol

# Correct HTTPS redirect behind Cloudflare/CDN:
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

If you are not sure which rule causes the loop, temporarily rename .htaccess to .htaccess.bak and test if the site loads. If it does, the problem is in your .htaccess file. Re-enable rules one at a time until you find the offending rule.

Fix 5: Fix WordPress Redirect Loops

WordPress redirect loops typically come from three sources: mismatched URLs in Settings, plugin conflicts, or incorrect wp-config.php values. If you cannot access the WordPress dashboard because of the redirect loop, you will need to fix it via the database or config files directly.

Check WordPress URL Settings

WordPress has two URL settings that must match: WordPress Address (URL) and Site Address (URL) in Settings > General. If one uses http:// and the other uses https://, or one has www. and the other does not, you will get a redirect loop.

If you cannot access the dashboard, hardcode the URLs in wp-config.php:

// Add these lines to wp-config.php (above "That's all, stop editing!"):
define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');

// If behind a reverse proxy (Cloudflare, Nginx proxy):
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

Disable Plugins to Find Conflicts

Redirect and caching plugins are frequent culprits. Plugins like Redirection, Yoast SEO, Really Simple SSL, WP Super Cache, and W3 Total Cache can all add redirect rules that conflict with your server or CDN settings.

If you cannot access the dashboard, disable all plugins via FTP or SSH:

# Rename the plugins folder to disable all plugins at once:
cd /var/www/html/wp-content/
mv plugins plugins.bak

# If the site loads, rename it back and disable plugins one by one:
mv plugins.bak plugins
# Then rename individual plugin folders to find the culprit:
mv plugins/really-simple-ssl plugins/really-simple-ssl.bak

If disabling plugins fixes the error, re-enable them one at a time to identify the conflicting plugin. The most common offenders are SSL plugins that add HTTP-to-HTTPS redirects when your server or CDN already handles this.

Fix 6: Fix Server-Level Redirects (Nginx & Apache)

Server configuration files can contain redirect rules that conflict with application-level redirects (WordPress, .htaccess) or CDN settings.

Nginx: Check for Redirect Conflicts

Nginx redirect loops typically happen when the HTTP server block redirects to HTTPS, but something in the HTTPS block redirects back to HTTP. Check your site configuration:

# Correct Nginx HTTPS redirect (separate server blocks):
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;
    # SSL certificate configuration here
    # DO NOT add another redirect to HTTPS here
}

# If behind Cloudflare/proxy, check real protocol:
server {
    listen 80;
    server_name example.com;
    if ($http_x_forwarded_proto != 'https') {
        return 301 https://example.com$request_uri;
    }
}

Apache: Check VirtualHost Redirects

On Apache, check both the VirtualHost configuration and .htaccess. A redirect in the VirtualHost config plus a redirect in .htaccess creates a double redirect that can loop:

# Check Apache config for redirect rules:
grep -r 'Redirect\|RewriteRule' /etc/apache2/sites-enabled/
grep -r 'Redirect\|RewriteRule' /etc/httpd/conf.d/

# Check .htaccess:
cat /var/www/html/.htaccess | grep -i 'rewrite\|redirect'

Remove duplicate redirects — keep the redirect in only one place. Best practice is to handle HTTPS redirects in the VirtualHost config (not .htaccess) because VirtualHost rules are processed once per request while .htaccess is processed on every request.

Fix 7: Browser-Specific Troubleshooting

If the error only appears in one browser, the issue is likely a cached redirect or extension conflict rather than a server problem.

Chrome: Clear HSTS and Socket Pool

Chrome caches HSTS (HTTP Strict Transport Security) policies that force HTTPS. If a site previously sent an HSTS header but no longer uses HTTPS correctly, Chrome will keep redirecting to HTTPS even after you clear cookies.

• Clear HSTS cache — Go to chrome://net-internals/#hsts, enter the domain under Delete domain security policies, and click Delete

• Flush socket pools — Go to chrome://net-internals/#sockets and click Flush socket pools to clear any cached connections

• Clear DNS cache — Go to chrome://net-internals/#dns and click Clear host cache

• Test in Incognito — Open an Incognito window (Ctrl+Shift+N) and try the URL. If it works in Incognito but not in the normal window, a cached redirect or extension is the cause

Firefox and Safari Fixes

Firefox: Type about:config in the address bar, search for network.http.redirection-limit, and verify it is set to 20 (default). If an extension changed this to a very low number, redirects may fail prematurely. Also try clearing site data: Settings > Privacy & Security > Manage Data > search the domain > Remove Selected.

Safari: Safari shows "too many redirects occurred" and offers a less detailed error than Chrome. Go to Safari > Settings > Privacy > Manage Website Data, find the domain, and remove its data. If the issue persists, try Safari > Clear History (choose all history).

How to Prevent Redirect Loops

Once you have fixed the immediate error, follow these practices to prevent redirect loops from happening again:

• Redirect in one place only — Choose one layer for your HTTPS redirect: either the CDN, the web server, or the application. Never redirect at multiple layers simultaneously

• Use 302 during testing — While debugging, use 302 (temporary) redirects instead of 301 (permanent). Browsers cache 301s aggressively, making it hard to test changes. Switch to 301 once you confirm the redirect works correctly

• Always test with curl — After adding a redirect rule, run curl -ILs https://yoursite.com | grep -i 'HTTP/\|location:' to verify the redirect chain resolves to a final 200 response

• Monitor with tools — Use DNS Robot's HTTP Headers Checker regularly to verify your site returns a clean 200 response without unexpected redirects

• Document your redirects — Keep a record of all redirect rules across your server config, .htaccess, CDN rules, and application settings. When multiple team members manage a site, undocumented redirects are the #1 cause of loops

• Purge CDN cache after changes — After modifying any redirect rule, purge your CDN cache immediately. Stale cached 301s can persist for days

SEO Impact of Redirect Loops

Redirect loops directly harm your search rankings. Google's crawler (Googlebot) follows up to 10 redirects per URL before giving up. If Googlebot encounters a redirect loop, it marks the page as a crawl error and stops indexing it.

According to Google's documentation on redirects, redirect chains should be as short as possible. Each extra redirect hop adds approximately 100-500ms of latency and wastes your crawl budget — the number of pages Google will crawl on your site per day.

• Lost indexing — Pages stuck in redirect loops are not indexed and disappear from search results entirely

• Wasted crawl budget — Googlebot spends its limited crawl budget following redirects instead of crawling actual content

• Page speed penalty — Each 301 redirect adds a full round-trip (100-500ms). Three redirects can add over a second to load time

• Link equity dilution — Backlinks pointing to a redirecting URL lose approximately 1-5% of their PageRank value per hop