ERR_TOO_MANY_REDIRECTS: How to Fix It (All Browsers)

What Is ERR_TOO_MANY_REDIRECTS?

ERR_TOO_MANY_REDIRECTS means the page sent your browser to another address more than 20 times without ever loading: a redirect loop. Chrome says "This page isn't working. example.com redirected you too many times", Edge shows a similar page with the same code, Firefox says "The page isn't redirecting properly", and Safari says "too many redirects occurred".

If you are visiting the site, delete that site's cookies and reload: a stale cookie is the usual cause when the site works for everyone else. If it is your site, the loop is almost always HTTPS (or www) being forced in two places at once, most often Cloudflare's Flexible SSL mode plus an HTTPS redirect on the server.

The limit is the same everywhere because the Fetch Standard browsers implement says so: "If request's redirect count is 20, then return a network error." The loop itself is usually two 301 or 302 responses pointing at each other: URL A sends you to URL B, URL B sends you back to A, and the browser stops counting at 20.

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
• App login loops — a sign-in page that redirects signed-out visitors to itself, or a session cookie the browser refuses to store (OAuth, Supabase Auth, NextAuth). See Fix 8

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 status codes: 301 is a permanent redirect that browsers cache, and 302 is a temporary redirect that is not cached unless the response says so.

Watch the scheme in each Location header: a loop between the http:// and https:// versions of the same URL is the most common pattern, and it points straight at an SSL setting.

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 Header Checker to inspect response headers from outside your browser cache.

Method 3: Online Redirect Checker

If you do not have a terminal, paste the URL into DNS Robot's Redirect Checker. It follows every hop from our server, shows each status code and Location header, and says when the chain loops back on itself. It runs without your browser's cookies, so it tells you at once whether the loop is the site's or your browser's.

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 Delete data to remove cookies and cached data for that site only
• Step 4 — Reload the page

# Chrome keyboard shortcut to open Delete browsing data:
# Windows/Linux: Ctrl + Shift + Delete
# macOS: Cmd + Shift + Delete

Or clear everything for all sites: press Ctrl+Shift+Delete (Mac: Cmd+Shift+Delete) to open Delete browsing data, tick Cookies and other site data and Cached images and files, choose All time, and click Delete data.

Clear Cookies in Firefox and Safari

Firefox: Press Ctrl+Shift+Delete (Mac: Cmd+Shift+Delete), tick Cookies and site data and Temporary cached files and pages, set the time range to Everything, and click Clear.

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.

If deleting cookies fixes it, a redirect rule on the server changed recently and your browser still carried the old state. Visitors with fresh sessions may never see the error.

Gmail, Google Drive or accounts.google.com Redirected You Too Many Times

When the message names accounts.google.com, mail.google.com or drive.google.com, the loop is between Google's sign-in pages and your browser's cookies, not a broken website. Google sign-in only works when the browser keeps Google's cookies, so anything that blocks or rewrites them sends you round in circles:

• Delete Google's cookies only — open chrome://settings/content/all, search for google.com, delete its data, and sign in again: Google's help notes you'll have to sign in to your Google Account again in that browser
• Allow cookies for Google — remove google.com from any list of sites not allowed to use cookies, and if you block third-party cookies, add [*.]google.com to the sites allowed to use them (Chrome: Settings → Privacy and security → Third-party cookies)
• Sign out of every account, then sign in with one — several signed-in accounts, or a work account that hands sign-in to the company's own login page, can bounce between the two
• Turn off cookie and privacy extensions — extensions that delete or rewrite cookies during sign-in are a common trigger. Chrome keeps extensions off in Incognito unless you allow them, so try an Incognito window first

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.

A broken certificate behind the same setup shows a different error instead; see ERR_SSL_PROTOCOL_ERROR and "Your connection is not private".

• 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 because its encryption mode decides whether it reaches your server over HTTP or HTTPS. Cloudflare's troubleshooting page (updated September 2026) lists five settings that loop, each against something your origin server does:

The usual fix for a Cloudflare redirect loop: 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 the encryption mode to Full (strict) if your origin has a valid certificate (a free Cloudflare Origin CA certificate counts), or Full only if it is self-signed
• 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;
    }
}

Run nginx -t after editing to catch syntax errors, then systemctl reload nginx to apply the change without downtime.

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 (more ways in how to flush DNS)
• 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 check it's 20 (the default). A lower value, set by hand or by an enterprise policy, makes redirects fail sooner. Also try clearing site data: Settings > Privacy & Security > Manage Data > search the domain > Remove Selected.

Safari: Safari shows "Safari Can't Open the Page" with "too many redirects occurred"; its Web Inspector console says "Load cannot follow more than 20 redirections". Go to Safari > Settings > Privacy > Manage Website Data, find the domain, and remove its data. If it still loops, test in a Private window: if that loops too, the site is misconfigured.

Fix 8: Login Redirect Loops in Web Apps

In a web app the loop is often your own code: a page that needs a signed-in user redirects to /login, and something sends /login (or the sign-in callback) straight back. The browser console shows it as net::ERR_TOO_MANY_REDIRECTS on the failing request.

• The login page is protected too — auth middleware that runs on every route also redirects /login and the callback route to /login. Exclude them from the check
• The session cookie never sticks — a cookie set with SameSite=None must also be Secure, or the browser drops it; a cookie set for the wrong domain is never sent back. Either way every request still looks signed out
• The callback URL doesn't match — the provider (Google, GitHub, Supabase Auth) sends users to a callback your app doesn't handle, and that route redirects to login again
• HTTP vs HTTPS behind a proxy — the app builds its redirect URLs with http:// because it ignores X-Forwarded-Proto: Fix 2's loop, one layer up

// Next.js: proxy.ts (middleware.ts before Next.js 16).
// Never run the sign-in check on the sign-in pages themselves.
export const config = {
  matcher: ["/((?!login|auth/callback|_next/static|_next/image|favicon.ico).*)"],
};

Test the fix with the Redirect Checker or curl -IL while signed out: a healthy chain ends at the login page with a 200, not another redirect.

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 Header 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

A healthy chain has one or two hops at most (for example HTTP → HTTPS → 200 OK). Three or more usually means a redirect you no longer need.

SEO Impact of Redirect Loops

Redirect loops take pages out of search. Google's crawling documentation says its crawlers "follow up to 10 redirect hops"; a loop never reaches content, so Search Console reports a redirect error and the URL drops out of the index until the loop is fixed.

Long chains cost even when they end: every hop is another request the browser and Googlebot must make before the page can load, so point links and redirects straight at the final URL.

• 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
• Slower pages — every hop is one more request and round trip before any content loads, and a hop to another host needs a new connection too