A redirect loop is what happens when URL A redirects to URL B and URL B redirects, directly or eventually, back to URL A. The browser follows the bouncing sequence until it hits its own limit — usually around twenty hops — and then gives up with ERR_TOO_MANY_REDIRECTS or a 508 Loop Detected. The page becomes completely unreachable. Loops are almost never a single broken rule; they are two correct-looking rules that disagree about what the canonical URL should be.
www versus non-www conflicts
The most common loop comes from two systems each insisting on a different canonical host. Suppose your CMS is configured to force the bare domain — it redirects www.example.com to example.com. Meanwhile your CDN or a redirect rule is configured to force www — it redirects example.com to www.example.com. Now a request for either host ping-pongs forever: example.com → www.example.com → example.com → …. Each rule is individually reasonable. Together they are a loop. The fix is to pick one canonical host and make sure every layer agrees on it; delete or reverse whichever rule disagrees.
HTTP and HTTPS rules fighting
A subtler version happens between schemes, and it often involves a reverse proxy or load balancer terminating TLS. Your application redirects any request it thinks is HTTP to HTTPS. But the proxy in front of it has already terminated TLS and forwards the request to the origin over plain HTTP. The application only sees the inbound HTTP connection, decides the visitor is on HTTP, and issues another redirect to HTTPS — which comes back through the proxy as HTTP again. The result is an HTTPS request that loops trying to reach HTTPS. The cause is that the application is not reading the X-Forwarded-Proto header the proxy sets, so it never learns the original request was already secure. Configure the app to trust that header, and the loop clears.
CDN and origin both redirecting
Put a CDN or edge platform in front of an origin that already has its own redirect logic and you have two independent places that can issue redirects — a classic loop factory. A common pattern: the CDN is set to "flexible" or "full" TLS and rewrites or forwards in a way the origin does not expect, while the origin has a rule forcing HTTPS or a canonical host. Each redirects, each undoes the other. The same happens when both the edge and the origin try to enforce a trailing-slash convention in opposite directions, or when a caching layer serves a stored redirect that no longer matches current origin behaviour. The principle for fixing it is to own redirects in exactly one layer. Decide whether the edge or the origin is responsible for scheme, host and slash normalisation, implement it there, and make the other layer pass through untouched.
Trailing slashes and case
Two smaller culprits round out the list. A trailing-slash loop appears when one rule adds a slash (/page to /page/) and another strips it (/page/ to /page). A case loop appears when one layer lowercases a path and another does not normalise it consistently. Both are the same underlying mistake — two rules with opposite opinions about the canonical form — and both are found the same way: by reading the chain.
How to read the chain and find the offending rule
You cannot debug a loop from the browser's error page, because it only tells you a loop exists, not where. You need the full hop-by-hop trace: each URL requested, the status code returned, and the Location header it redirected to. Lay those out in order and the loop reveals itself as the point where a URL you have already seen reappears. Look at the two hops on either side of that repeat — those are the two rules in conflict. Note the exact scheme and host at each step, because the difference between the looping URLs (one adds www, one removes it; one forces HTTPS, one drops to HTTP) names the rule you need to change.
Once you have identified the pair, decide the single canonical form — say https://www.example.com/page — and ensure only one layer enforces it while every other layer passes matching requests straight through. Then re-run the trace and confirm the request now reaches a 200 in one or two clean hops with no repeats. This site's checker prints every hop and status code for exactly this purpose, so you can see the loop instead of guessing at it.
Prevent them coming back
One trap catches almost everyone testing a fix: browsers cache 301 responses aggressively, sometimes indefinitely. If a loop was ever served as a permanent redirect, your browser may keep replaying the cached loop even after you have corrected the rule on the server, making it look as though your fix did nothing. Always test loop fixes in a private window, with a cleared cache, or with a command-line tool that does not reuse a browser cache, so you are seeing the server's current behaviour rather than a stored memory of the broken one.
Loops tend to reappear after infrastructure changes — a new CDN, a TLS mode switch, a migrated proxy. Two habits prevent most of them. First, keep a written record of which layer owns canonicalisation, so no one adds a well-meaning duplicate rule elsewhere. Second, make sure proxies pass X-Forwarded-Proto and your application trusts it, so scheme detection is never based on the already-terminated inner connection. If you also serve HSTS, verify it with HSTS Studio, and check that certificates are valid on every host in the path with TLS Studio — a loop that only appears over HTTPS is sometimes a certificate or TLS-mode problem wearing a redirect's clothes.