What Is a Redirect Loop?

A redirect loop is when URL A redirects to URL B, which redirects back to URL A (or through a longer chain that eventually circles back). The browser follows the redirects in an infinite circle until it gives up and shows an error.

You have seen the error message. In Chrome it says ERR_TOO_MANY_REDIRECTS. In Firefox it says "The page isn't redirecting properly." In Safari it says "Too many redirects occurred." They all mean the same thing: your server is sending the browser in circles. For a step-by-step fix, see How to Fix ERR_TOO_MANY_REDIRECTS. For background on all redirect types, see our HTTP Redirect Guide.

How a redirect loop works

The simplest loop is two URLs pointing at each other:

https://example.com/page-a
  --> https://example.com/page-b
    --> https://example.com/page-a
      --> https://example.com/page-b
        --> (infinite loop)

But loops can be longer and harder to spot:

/page-a --> /page-b --> /page-c --> /page-d --> /page-a
                                                 ^
                                          back to start

Browsers typically follow 20 redirects before giving up. [1] The user sees nothing but an error page.

Loops vs chains

A redirect chain eventually reaches a final destination. A loop never does. Chains are a performance problem. Loops are a total failure: the page never loads at all.

Common causes

1. HTTP/HTTPS conflict

This is the number one cause of redirect loops in the wild. It happens when one rule forces HTTPS and another rule forces HTTP.

# Rule 1 (in .htaccess): Force HTTPS
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]

# Rule 2 (in application or CDN): Force HTTP
# (misconfigured load balancer terminating SSL and redirecting back)
if (protocol == "https") redirect to "http://..."

The server says "go to HTTPS." The load balancer strips SSL and the app sees HTTP, so it says "go to HTTPS." Forever.

2. WWW vs non-WWW conflict

Similar to the HTTPS issue. One rule redirects to www, another redirects away from it.

# Server config: redirect to www
example.com --> www.example.com

# CDN config: redirect to non-www
www.example.com --> example.com

# Result: infinite loop

The fix is always the same: pick one canonical version and configure it in exactly one place.

3. Circular .htaccess or Nginx rules

Overlapping rewrite rules that match each other's output. For more on getting these rules right, see .htaccess Redirect Rules Guide or Nginx Redirect Configuration Guide.

# Rule 1: Add trailing slash
RewriteRule ^(.+[^/])$ /$1/ [R=301,L]

# Rule 2: Remove trailing slash
RewriteRule ^(.+)/$ /$1 [R=301,L]

# Result: /page --> /page/ --> /page --> /page/ --> ...

4. CMS plugin conflicts

WordPress is notorious for this. A security plugin forces HTTPS while a caching plugin or CDN plugin has its own redirect rules. Two plugins fighting over the same redirect creates a loop. See How to Fix Too Many Redirects in WordPress for the debugging process.

5. CDN and origin server disagreement

Your CDN (Cloudflare, Fastly, CloudFront) has redirect rules. Your origin server also has redirect rules. If they disagree about where traffic should go, loops happen.

CDN rule:      http://example.com --> https://example.com (good)
Origin rule:   Force redirect to http://example.com (bad)

CDN: "Go to HTTPS"
Origin: "Go to HTTP"
CDN: "Go to HTTPS"
(loop)

How to diagnose a redirect loop

Step 1: Use curl to see the chain

curl -v -L --max-redirs 10 https://example.com/problem-page 2>&1 | grep -E "^< HTTP|^< [Ll]ocation"

This shows each hop with its status code and destination. When you see the same URL appear twice, you have found your loop. For more curl techniques, see How to Trace Redirects with cURL.

Step 2: Check each layer independently

The loop usually involves two different systems. Check each one:

# Check what the origin server does (bypass CDN)
curl -I -H "Host: example.com" https://your-origin-ip/problem-page

# Check what the CDN does
curl -I https://example.com/problem-page --max-redirs 0

Step 3: Inspect headers

Look for X-Forwarded-Proto, X-Forwarded-For, and Via headers. These reveal whether a proxy or load balancer is involved in the loop.

Step 4: Check all redirect sources

Redirects can come from multiple places. Check all of them:

How to fix common loops

Fix: HTTP/HTTPS loop with load balancer

Trust the X-Forwarded-Proto header from your load balancer instead of checking the connection protocol directly:

# Nginx: check the forwarded protocol, not the connection
map $http_x_forwarded_proto $redirect_to_https {
    default 0;
    http    1;
}

server {
    if ($redirect_to_https) {
        return 301 https://$host$request_uri;
    }
}

Make sure your SSL certificate is valid on both the CDN and origin. An expired cert at either end can compound redirect issues.

Fix: WWW vs non-WWW loop

Pick one canonical version and configure it in exactly one place. Remove all conflicting rules.

# Pick non-www as canonical. Configure in ONE place only.
server {
    listen 80;
    listen 443 ssl;
    server_name www.example.com;
    return 301 https://example.com$request_uri;
}

Fix: Trailing slash loop

Choose one convention and apply it consistently:

# Add trailing slash (pick ONE approach)
rewrite ^([^.]*[^/])$ $1/ permanent;

Fix: WordPress plugin loop

1. Deactivate all plugins via the database or file rename
2. Reactivate one at a time
3. Test for the loop after each activation
4. The plugin that triggers the loop is your culprit

Prevention

1. Configure redirects in one place. Do not split redirect logic between your server config, .htaccess, application code, and CDN. Pick one authoritative source.
2. Test after every change. After modifying any redirect rule, immediately test the affected URLs. See How to Check URL Redirects for methods.
3. Monitor continuously. Redirect loops can appear when a third party (CDN, hosting provider, CMS update) changes their behavior. Redirect monitoring catches these before users do.

References

1. Google, "Redirects and Google Search," Google Search Central, 2024. https://developers.google.com/search/docs/crawling-indexing/301-redirects