All Posts
· URLsCheck

How to Find and Fix Redirect Loops

Diagnose ERR_TOO_MANY_REDIRECTS with a repeatable workflow covering HTTPS, www, trailing slashes, proxies, cookies, CDNs, and application rules.

Redirects Debugging CDN

A redirect loop happens when a request returns to a URL it has already visited. The browser keeps following instructions until it reaches its limit and displays an error such as ERR_TOO_MANY_REDIRECTS.

The visible error is simple; the cause often spans several layers. A CDN may force HTTPS while the origin believes the visitor used HTTP. A CMS may add a trailing slash while a framework removes it. Authentication middleware may bounce between login and callback URLs.

The fastest fix is to capture the exact loop before editing rules.

Confirm the loop and capture every hop

Run the failing address through the URL Redirect Checker. Start with the exact URL from the browser, not a cleaned or preferred version.

Look for a repeated pair or cycle:

https://example.com/page
→ 301 https://www.example.com/page
→ 301 https://example.com/page

or:

/account → 302 /login → 302 /account

Record the status code, hostname, protocol, path, query and redirect type at each step. The first repeated URL defines the loop. The differences between the two rules usually point toward the responsible layers.

The most common redirect-loop patterns

HTTP and HTTPS disagreement

This often appears behind a reverse proxy. The visitor connects to the CDN over HTTPS, but the CDN talks to the origin over HTTP. If the application trusts only its direct connection, it thinks every request is insecure and redirects to HTTPS again.

Verify that proxy headers such as Forwarded or X-Forwarded-Proto are set and trusted correctly. Do not blindly trust these headers from the public internet; configure trusted proxy boundaries.

www and non-www conflict

One layer redirects example.com to www.example.com, while another enforces the opposite. Choose one canonical host and configure the CDN, web server and application to agree.

Trailing-slash conflict

Framework A normalizes /docs to /docs/; framework B removes the slash. This can be hidden until a deployment changes which layer runs first. Define one path policy, update internal links and avoid running competing normalization rules.

Authentication and cookies

An application may redirect an unauthenticated visitor to /login, then immediately send that visitor back to a protected page without establishing a valid session. Causes include an incorrect cookie domain, Secure cookie on HTTP, SameSite restrictions, expired state or a callback URL mismatch.

Test in a private window and with cookies disabled only to isolate state. A server-side checker usually has no authenticated session, so compare its result with the browser’s network log.

Locale or device detection

Rules can bounce between /, /en/ and a geography-specific host when the cookie, Accept-Language header and URL prefix disagree. Redirect only when the selected destination is stable, and let an explicit URL or user choice override automatic detection.

A layer-by-layer debugging workflow

  1. Reproduce without cache. Use a fresh browser profile and a server-side check.
  2. Find the smallest repeating cycle. Two alternating URLs are easier to reason about than the entire history.
  3. Identify who emitted each redirect. Inspect response headers, server logs and CDN traces.
  4. Temporarily isolate layers. If safe in staging, bypass the CDN or disable one normalization rule at a time.
  5. Choose a single source of truth. Host, protocol and slash normalization should have one clear owner.
  6. Test variants. Check HTTP/HTTPS, www/non-www, slash/no-slash and important query strings.
  7. Purge caches and retest publicly. Cached redirects can outlive the rule that created them.

Be careful with permanent redirect caching

Browsers and intermediaries can cache permanent redirects. After fixing the server, one browser may continue showing the old route. Use a new profile, command-line client or online checker to distinguish a live loop from a cached one.

During risky rule development, temporary redirects can reduce the cost of mistakes. Change to a permanent status only after the mapping is verified and genuinely intended to persist.

Prevention checklist

  • Document the canonical protocol, host and trailing-slash policy.
  • Keep normalization rules in one layer when practical.
  • Configure trusted proxy headers explicitly.
  • Test redirects in staging using production-like CDN settings.
  • Add representative redirect checks to release QA.
  • Monitor 3xx counts and repeated destinations in logs.
  • Keep authentication callbacks and cookie scopes environment-specific.
  • Avoid broad regular expressions that can match their own destination.

For site migrations, combine targeted chain inspection with a bulk status-code audit so you catch both loops and destinations that terminate in errors.

Frequently asked questions

Is a redirect loop always server-side?

No. JavaScript, service workers and meta refresh can create client-side cycles. Browser extensions and cached permanent redirects can also affect one device while the live server is healthy.

Why does the loop happen only behind Cloudflare or another CDN?

The proxy may terminate TLS, rewrite the host, cache a redirect or send different connection metadata to the origin. Compare the edge response with a controlled origin request and review SSL mode and forwarding headers.

Can deleting cookies fix the underlying problem?

It can clear stale state, but it does not fix a rule that repeatedly creates invalid state. Treat cookie clearing as a diagnostic step, then correct the session or routing logic.

All Posts
URLsCheck