Fix redirect loop: break circular 301/302 chains

What's happening

A redirect loop is a chain that points back at itself: A → B → A → B forever, or a longer cycle. Browsers detect this after 20-30 hops and abort with ERR_TOO_MANY_REDIRECTS (Chrome) or "redirected too many times" (Firefox). The page never loads. Search crawlers detect it earlier and drop the URL from the index.

Curl is the fastest diagnostic: curl -ILv https://yoursite.com follows redirects and shows every hop. A loop appears as the same URL recurring in the chain. CheckFast's /redirects tool, Screaming Frog, and online redirect checkers visualize the same.

Loops usually emerge when multiple layers each apply a redirect rule that conflicts: HTTPS termination at the load balancer, app-level www-vs-non-www logic, and a CDN page rule all pointing in different directions. Each layer thinks it's correct; together they cycle.

Why it matters

Users hit a broken page that returns ERR_TOO_MANY_REDIRECTS — the worst possible UX. Bounce is 100% on a looping URL. Search engines drop the URL from the index, so any rankings disappear within days.

Loops also rarely fail in the lab and only manifest in production when multiple infra layers interact. They tend to happen at deploys, after migrations, or when changing CDN settings — exactly the worst times for an outage.

Common causes

• Conflicting redirect rules in nginx and the application layer.
• CDN page rule redirecting back to a path that the origin redirects forward.
• HTTPS terminated at the load balancer; the app sees HTTP and redirects to HTTPS, which terminates again.
• Trailing-slash normalization disagreement between framework and infrastructure.
• X-Forwarded-Proto header not respected by the app, causing infinite HTTPS redirect.
• www-to-non-www rule layered on a non-www-to-www rule from a different config file.
• Auth middleware redirecting unauthenticated users to /login that also requires auth.

Detect this on your site

Run a quick scan with the Redirect Checker. The tool surfaces this exact issue with the records and context needed to apply the fix below.

How to fix it

1. 1

   Trace the loop with curl

   Run curl -ILv https://yoursite.com 2>&1 | grep -E 'Location|HTTP/'. Each line shows a status code and the next URL. A loop appears as the same URL recurring. Note the exact URLs and headers — these tell you which layer is redirecting.

2. 2

   Check the X-Forwarded-Proto header

   If your app is behind a load balancer or CDN that terminates HTTPS, the origin sees HTTP requests with X-Forwarded-Proto: https. Ensure your framework respects this header (Express: trust proxy, Rails: SSL middleware). Otherwise the app redirects to HTTPS, which the LB terminates, which the app sees as HTTP, infinitely.

3. 3

   Audit all redirect layers

   List every layer that can issue a redirect: DNS (rare), CDN page rules, load balancer rules, web server (nginx/Apache), application middleware, framework defaults. Pick one layer to own canonical-URL logic and remove redirect rules from the others.

4. 4

   Pick a single www/non-www canonical

   Decide on https://www.example.com or https://example.com as canonical. Configure all redirect logic at one layer (typically the CDN or web server). Verify with curl that the chosen canonical doesn't itself redirect anywhere.

5. 5

   Disable framework auto-redirects when CDN handles it

   Many frameworks auto-redirect HTTP to HTTPS, trailing slashes, www-vs-non-www. If your CDN already handles these, disable the framework versions to avoid layer conflicts. Next.js: trailingSlash setting. Express: trust proxy + remove redirect middleware.

6. 6

   Test in production after deploy

   Deploy with a single canary route, run curl -ILv against it, and verify no loop before flipping the rule for the whole site. The smaller the redirect rule blast radius at deploy, the easier to roll back if a loop emerges.

7. 7

   Set up monitoring for redirect chains

   Configure an uptime monitor that follows redirects and alerts on chain length over 2 hops. CheckFast's /redirects tool runs scheduled checks. Once a loop forms, you want to know within minutes, not when users start tweeting.

Example

# Bad: app redirects to HTTPS, but app sees X-Forwarded-Proto wrong
server {
    listen 80;
    return 301 https://$host$request_uri;
}
# (LB terminates HTTPS, forwards HTTP to origin → app redirects to HTTPS → LB terminates → infinite loop)

# Good: trust the proxy header, redirect only on real http
server {
    listen 80;
    server_name www.example.com;
    if ($http_x_forwarded_proto = "https") {
        # already HTTPS at the LB; serve the app
        proxy_pass http://app;
        break;
    }
    return 301 https://$host$request_uri;
}

# In Express:
app.set("trust proxy", true);
app.use((req, res, next) => {
    if (req.protocol !== "https" && process.env.NODE_ENV === "production") {
        return res.redirect(301, `https://${req.host}${req.url}`);
    }
    next();
});

Trust the proxy's X-Forwarded-Proto to break the HTTPS termination loop.

Related fixes