Building useful websites
Too many redirects? Trace the loop before changing settings
Find the repeating transition, identify the rule behind it, and check that readers reach the intended page.
1. Record the redirects before changing settings
ERR_TOO_MANY_REDIRECTS means the browser stopped following redirects. Start with one failing published URL. Record the complete address, whether you are signed in, and whether the problem also occurs in a fresh browser session. A redirect limit can be reached by a loop or by a long chain; the message alone does not identify the rule that caused it.
In desktop Chrome, open DevTools → Network, enable Preserve log, and navigate to the failing address. Select each document request and inspect Request URL, status and the Location response header in Headers. Keep the request order. An HTTP redirect points to another address; compare that destination with the next request. A relative Location is resolved against the request URL.
Write a short trace: requested URL → status → destination. Look for the first repeated address, including scheme, host, path and query. A repeated address is a clue; check that the sequence continues repeating rather than completing after session state changes. Do not include cookies or login tokens in a public bug report.
2. Compare a browser trace with a small curl GET
In a Linux or macOS terminal, the following command for a public page prints the first response headers and discards the body. Replace the example address with the failing URL. It makes a GET request; adding -I would instead request HEAD, which can behave differently.
curl -q -sS --max-time 20 -D - -o /dev/null 'https://example.com/start'
To follow a bounded number of redirects and print the response headers along the way, run:
curl -q -sS --max-time 20 -L --max-redirs 5 -D - -o /dev/null 'https://example.com/start'
Here -L follows HTTP redirects, --max-redirs 5 limits the number followed, -D - writes headers to the terminal, and -o /dev/null discards the response body. -sS suppresses the progress meter while retaining error messages. Headers can include private session data; keep the raw output private. The first option, -q, skips curl’s default configuration file; --max-time 20 sets a 20-second total time limit. A timeout is different from exceeding the redirect count.
This command does not copy your browser cookies or execute JavaScript. Treat it as a separate request context. A successful curl request does not prove that a signed-in browser works. In our local test, exceeding the redirect limit produced curl exit code 47 both for an actual loop and for a long chain that eventually reached 200 with a higher limit. Raising the limit is useful for inspecting that distinction, not for repairing a repeating rule.
3. Use the repeated change to locate the conflicting rules
Coru tested a deliberately configured loopback server on 21 October 2026. These are controlled examples, not measurements of your host. The finite trace /finite-start (301) → /finite-middle (302) → /article (200) reached its intended page. The loop /loop-a (302) → /loop-b (302) → /loop-a repeated until curl stopped. A separate slash loop alternated 308 and 301 responses. The useful evidence was the repeated URL change, not merely the final error.
For example, /guide → /guide/ → /guide repeats a path normalization decision. Find the rule that adds the slash and the rule that removes it. Keep one intended public URL and make the participating layers agree. Changing a 301 into a 302 does not resolve two contradictory destinations.
The same method applies when the repeated change is example.com ↔ www.example.com or http ↔ https. Inspect rules in the CDN or proxy, web server, application and CMS. Work from the observed transition; do not turn off every redirect. An old URL should still lead to its useful replacement.
- Slash or host alternates: compare normalization rules at each layer and the application’s configured public address.
- HTTP and HTTPS alternate, or the same HTTPS URL repeatedly redirects to itself: inspect how the proxy connects to the origin and how the application determines the original request scheme.
- Login and account addresses alternate: compare the same route with and without the affected session, then inspect authentication and cookie handling.
4. Check the proxy’s HTTPS view and the session separately
Cloudflare documents one specific example: in Flexible mode the edge connects to the origin over HTTP; an origin that forces that request back to HTTPS can create a loop. Other SSL modes can loop when the origin forces HTTPS back to HTTP. Apply the documented remedy for the actual mode and origin capabilities. Disabling public HTTPS is not a general solution.
Behind a reverse proxy, the connection seen by the application may differ from the visitor’s original connection. X-Forwarded-Proto can convey the original scheme. Check your framework’s trusted-proxy configuration and what the trusted proxy actually supplies; do not blindly trust a header sent directly by an arbitrary client. We did not test a production CDN or framework in the local experiment.
Our separate session example used a deliberately invalid cookie: the clean request reached the login page, while the affected session repeated login and account redirects. A fresh browser context also reached the page. This established dependence on that cookie in our fixture; it did not establish a universal cookie fix.
On your site, compare the recorded traces first. If only an existing session fails, inspect cookie expiry, path and domain, and the application’s login/logout rules. Clearing that site’s cookies can test the hypothesis, but may sign you out; it does not repair a server rule that recreates the broken session. Avoid clearing all browser data as the first diagnostic step.
5. If curl ends at 200 but the browser moves again
An HTTP redirect trace is only part of browser navigation. A page can return 200 and then navigate through a script or an HTML refresh directive. In our JavaScript example, curl ended at the first 200 response, while Chromium navigated to a second page that also returned 200. No HTTP Location chain connected them.
Keep Preserve log enabled and inspect the next document request and its initiator. Check the previous response for a script or refresh instruction. Also compare cookies and the exact starting URL before deciding that JavaScript is the cause. MDN distinguishes HTTP redirects from HTML and JavaScript navigation. A browser-specific result needs its own evidence.
6. Verify the repair from the original entry address
Change the smallest rule supported by the trace, then repeat the original public URL in the affected browser session and in a fresh one. Confirm the intended page content and final address, not just status 200: a login or error page can return 200 too. Recheck relevant HTTP/HTTPS, host and trailing-slash entry variants, plus a real old link that should still redirect.
Keep a repair record: entry URL → session condition → repeating transition → responsible rule → change → final address and page content. A useful result is that the reader reaches the intended page without a repeating navigation, and legitimate old links still work.
If a browser still uses an old redirect after the configuration is fixed, compare a fresh context and inspect caching before changing another rule. The related stale-page guide helps separate old responses from current configuration. Our lab covers prescribed local routes, one curl build and one Chromium build; it does not certify your cache, authentication system or proxy.