Start by tracing the redirect chain
Do not begin by clearing caches or changing several settings at once. First run the failing URL through the Redirect Checker. Smart Web Utility follows HTTP 301, 302, 303, 307 and 308 responses, records each Location target, and stops when it reaches a non-redirect response, detects a repeated URL, or reaches its ten-step safety limit.
The goal is to identify the first repeated state. If the chain alternates between http://example.com and https://example.com, the conflict is scheme handling. If it alternates between www.example.com and example.com, host canonicalization rules disagree. A larger cycle can point to application routes, locale rules or proxy behavior.
Common redirect-loop patterns
HTTP ↔ HTTPS
A proxy or CDN reaches the origin over HTTP while the origin forces HTTPS, then another layer converts the request back to HTTP. Cloudflare documents this as a classic loop when Flexible encryption conflicts with an origin HTTPS redirect.
www ↔ non-www
One layer redirects www to the apex while another redirects the apex back to www. Only one canonical hostname policy should win.
CDN ↔ origin
The edge normalizes a URL one way while the origin or application rewrites it back. This commonly happens when forwarded scheme/host headers are not interpreted consistently.
Application/CMS loop
WordPress, frameworks, authentication middleware, locale rules or plugins can redirect based on state that another layer immediately reverses.
Step 1: separate the browser symptom from the HTTP evidence
A browser error tells you that too many redirects occurred, but it does not tell you which rule created the cycle. Use the redirect chain to record the sequence of status codes, URLs and Location headers. The HTTP Header Checker is useful when you need to inspect the response headers for a particular hop.
Be careful with cached permanent redirects. A browser may remember a previous 301 and appear to behave differently from a fresh server-side request. Compare the live HTTP chain with a private browser session or developer tools before assuming the current origin still sends the same redirect.
Step 2: check HTTP/HTTPS ownership
Choose where HTTPS enforcement belongs and avoid contradictory rules. If a CDN or reverse proxy terminates TLS, make sure the origin can tell that the original visitor connection was HTTPS—typically through trusted forwarded-protocol information—and does not blindly redirect because the proxy-to-origin connection itself is HTTP.
Cloudflare's current SSL/TLS documentation specifically warns that Flexible mode can create a loop when the origin redirects every HTTP request to HTTPS. In Full or Full (strict), the edge connects to the origin over HTTPS instead. The exact fix depends on the platform, but the principle is the same: the edge and origin must agree about the scheme.
Step 3: choose one canonical hostname
If both www and non-www are public entry points, select one canonical destination and make every redirect rule point in that direction. Do not configure an edge rule for www → apex while the application has apex → www.
Test four starting URLs independently when relevant: HTTP apex, HTTPS apex, HTTP www and HTTPS www. The intended setup usually converges all four to one canonical HTTPS URL without cycling.
Step 4: inspect proxy and application assumptions
Reverse proxies, load balancers and CDNs often pass the original hostname and scheme through headers. An application that does not trust or interpret those headers correctly may think every request arrived on the wrong scheme or hostname and issue another redirect.
Authentication and session middleware can create a different class of loop: protected page → login → callback → protected page → login. That loop may depend on cookies, SameSite behavior, hostnames or session state rather than a static web-server rule.
Step 5: change one redirect layer at a time
Once the repeated pair or cycle is visible, disable or correct the conflicting rule and test again. Avoid changing CDN settings, web-server rewrites and CMS configuration simultaneously. A single-variable test preserves evidence and reduces the chance of creating a second problem.
What the Redirect Checker can and cannot prove
The checker sends server-side header requests and follows supported HTTP redirect status codes for up to ten request steps. It can identify a repeated URL visible to that client and show the Location chain. It does not execute JavaScript and does not reproduce every browser cookie, authentication state, user agent, geography, experiment bucket or bot-protection rule.
Because some applications respond differently to HEAD and GET, a browser can occasionally see a redirect path that differs from this checker. When results disagree, use browser developer tools or an application-aware client to capture the exact session-specific requests.
Diagnostic patterns
| Observed chain | Likely conflict | Check next |
| http → https → http | Proxy/CDN and origin disagree on scheme. | TLS mode, HTTPS enforcement, forwarded-proto handling. |
| www → apex → www | Conflicting canonical-host rules. | CDN redirect rule, web server, CMS site URL. |
| /login → /app → /login | Authentication/session loop. | Cookie domain, callback URL, session persistence. |
| /a → /b → /c → /a | Multiple rewrite rules form a cycle. | Trace the rule responsible for each hop. |
| Checker is clean, browser loops | Client/session-specific redirect or cached redirect. | Browser network panel, cookies, private session, service worker. |
Frequently asked questions
Does clearing cookies fix ERR_TOO_MANY_REDIRECTS?
Sometimes, when the loop depends on authentication or session state. It will not fix a deterministic server/CDN redirect conflict. Trace the chain first so you know whether cookies are relevant.
Can HSTS cause a redirect loop?
HSTS makes compliant browsers upgrade HTTP to HTTPS before the HTTP request is sent. A conflicting origin or proxy rule that tries to force HTTPS traffic back to HTTP can then create repeated scheme changes or make the site inaccessible.
Can two 301 rules loop forever?
Yes. Status code permanence does not prevent a cycle. If URL A permanently redirects to B and B redirects back to A, clients still have no stable destination.
Should I remove all redirects?
No. Redirects are useful for HTTPS enforcement, canonical hostnames and moved URLs. The goal is to remove conflicting rules and keep the path to the final destination as direct as practical.
Related tools and guides
Technical references