How to fix a “too many redirects” error

What “too many redirects” means

A browser follows a redirect only to receive another redirect. After enough repetitions it stops to prevent an endless loop. The simplest pattern is A → B → A, but a loop can include several URLs or alternate between two representations of the same page.

The error is often named ERR_TOO_MANY_REDIRECTS in Chromium-based browsers. Other browsers use similar wording. It is a routing problem rather than a problem with the visible page content.

Start with these checks

1. Copy the exact failing URL and trace it in the redirect checker. If the route repeats, note the first repeated URL.
2. Try a private browsing window. If the error disappears, cookies or a cached redirect probably influence the route.
3. Test both HTTP and HTTPS, then www and non-www forms. Differences reveal which normalization rule is involved.
4. If you control the site, check recent changes at every redirecting layer: CDN, load balancer, web server, CMS, application, and authentication provider.

HTTP and HTTPS redirect loops

A common setup has an edge proxy terminate HTTPS and forward the request to the application over HTTP. The application sees an HTTP connection and redirects to HTTPS. The edge receives that request, forwards over HTTP again, and the application redirects again forever.

The fix is to make the application aware of the original scheme through trusted proxy configuration, or to make the edge solely responsible for HTTPS normalization. Do not blindly trust forwarded headers from every client; accept them only from known proxies.

Another version has one layer forcing HTTPS while a legacy rule forces a specific path back to HTTP. Search server and application configuration for both directions, including environment-specific rules that may not exist on a developer machine.

www and non-www conflicts

If the CDN redirects example.com to www.example.com while the origin redirects www back to the bare domain, neither URL can win. Decide which hostname is canonical and configure every layer to agree.

Make the preferred hostname explicit in canonical tags, sitemaps, internal links, analytics settings, and certificate coverage. That consistency prevents the redirect layer from doing unnecessary cleanup on every request.

Reverse proxy and platform loops

Managed platforms often provide toggles for HTTPS, hostname, trailing slash, locale, or authentication. A CMS plugin may apply the same preference independently. Review features before writing lower-level rules, because the easiest loop to create is two systems each “correcting” the other.

Authentication adds another pattern: the protected page redirects to login, login believes the visitor is authenticated and redirects back, and the protected page still cannot read the session. Check cookie domain, path, Secure and SameSite settings, as well as whether the proxy forwards the required headers.

When cookies or cache cause the loop

A private window is a useful comparison because it starts without the site’s normal cookies and much of its stored state. If only the regular session fails, remove cookies for that site and sign in again. Avoid clearing all browser data unless necessary.

Browsers and CDNs may cache permanent redirects. After correcting the server, an old 301 can continue sending one client down the previous path. Test with a fresh profile or command-line client, purge the relevant CDN entry, and use temporary codes while validating a new rule if caching would make mistakes costly.

A safe repair process

1. Record the loop. Write down the repeating URLs, status codes, and which environment is affected.
2. Name the owner of each hop. Identify whether the CDN, server, CMS, application, or identity service generated it.
3. Choose one canonical result. Specify scheme, hostname, path style, and authentication state.
4. Remove the disagreement. Prefer one normalization layer, or make later layers recognize that the request is already canonical.
5. Test without stale state. Use a private session and purge only the caches involved.
6. Check neighboring paths. Test the homepage, a deep link, login and logout, query parameters, and both hostname variants.

After the loop is gone, inspect the route again. The goal is not merely to stay below the browser’s redirect limit. It is to reach the right page in the fewest intentional hops.