HTTP Redirect Loop Fix: Diagnosing and Breaking ERR_TOO_MANY_REDIRECTS

A redirect loop is a cycle where request A causes a redirect to B, and B causes a redirect back to A, or to another URL that eventually cycles back to A. The browser follows each redirect automatically until it reaches its internal limit — Chrome stops after 20 redirects and shows ERR_TOO_MANY_REDIRECTS. The server's access logs tell the true story: you will see alternating status codes and URLs cycling through the same set of locations.

The most common redirect loop is the HTTPS enforcement loop behind a proxy. A load balancer or reverse proxy like nginx, AWS ALB, or Cloudflare terminates TLS and forwards decrypted HTTP requests to the application on a backend port. From the application's perspective, every request arrives over HTTP. If the application has an HTTP-to-HTTPS redirect rule that checks the direct connection protocol rather than the X-Forwarded-Proto header, it redirects every request to HTTPS. The load balancer receives the HTTPS request, forwards it as HTTP again, and the cycle repeats until the browser gives up.

Cached redirects are a secondary cause of redirect loops that is often overlooked. A 301 Moved Permanently response is cached by the browser until the cache is explicitly cleared. If you set up a redirect chain during a migration — HTTP to HTTPS, then old domain to new domain — and later remove one of the intermediate redirects, browsers that cached the 301 will continue following it. The cached redirect may now point to a URL that redirects back to the original, creating a loop that only appears for returning visitors, not in fresh browser sessions. Curl and incognito mode will not reproduce it because they do not use the cached redirect.

Authentication redirect loops are a third category where the login page redirects to the protected resource after authentication, but the protected resource redirects back to the login page because the session cookie was not set correctly. This happens when the cookie domain or path does not match the requested URL, when SameSite restrictions prevent the cookie from being sent on a redirect, or when the session store failed to save the session between the login POST and the subsequent GET redirect.

CORS interactions can also create loops. If a cross-origin request triggers an authentication redirect and the authentication server is on a different domain, the redirect does not carry the original credentials — the browser follows the redirect as an unauthenticated request, which is again redirected to authentication, creating a loop specific to cross-origin scenarios.

The fastest diagnostic tool for redirect loops is curl with verbose output. Run curl -L -v https://example.com 2>&1 | grep -E 'Location:|< HTTP' to follow all redirects and print only the status codes and Location headers. This shows the complete redirect chain without the noise of response bodies. If you see the same pair of URLs alternating, you have found your loop. Limit the redirect depth with curl --max-redirs 5 to stop curl before it exhausts the full chain and still see which URLs are involved.

In Chrome's DevTools, open the Network tab before visiting the URL. Check Preserve log at the top of the Network tab so Chrome does not clear the log when the page redirects. You will see each redirect as a separate network entry. Click on each one to see its Location header and status code. The pattern becomes clear when you see the same URLs cycling. The response headers on each redirect entry show exactly where the server is sending you.

Check the Cache-Control and Expires headers on redirect responses. If a 301 response has no Cache-Control header or has a long max-age, the browser may have cached it. Test in an incognito window with a fresh session to rule out cached redirects. If the loop does not reproduce in incognito, clear the browser cache for the affected domain and test again in a normal window.

For server-side investigation, tail your access logs while making a single request to the looping URL. Each redirect appears as a separate access log entry. You can identify the loop by seeing the same URL pair appear repeatedly in sequence. Add Cache-Control: no-store to redirect responses while debugging to prevent the browser from caching bad redirects and compounding the problem.

Use /tools/http-request-builder to send requests manually with specific headers like X-Forwarded-Proto: https and observe whether the server redirect fires. This lets you simulate what a load balancer would send to your application and confirm whether the redirect condition correctly reads the forwarded protocol. Compare the response when X-Forwarded-Proto is set to https versus http to confirm the fix is working before deploying it.

For HTTPS enforcement loops behind a proxy, the fix is to read X-Forwarded-Proto instead of the local connection protocol. In Express, set app.set('trust proxy', 1) and then check req.headers['x-forwarded-proto'] before redirecting. In nginx, use the scheme variable which automatically uses X-Forwarded-Proto when available. In PHP and WordPress, check $_SERVER['HTTP_X_FORWARDED_PROTO'] and set $_SERVER['HTTPS'] = 'on' when it equals 'https' so that PHP's own HTTPS checks work correctly through the proxy.

For Cloudflare-specific loops, change the SSL mode from Flexible to Full or Full (Strict) in the Cloudflare dashboard under SSL/TLS. Flexible SSL is a common default that sends HTTP to the origin, which conflicts with any application-level HTTPS enforcement. Full SSL sends HTTPS to the origin if a certificate is installed. Full (Strict) additionally verifies the certificate against a trusted CA. If your origin has a valid certificate, use Full (Strict) for the best security and no redirect loop risk.

For mod_rewrite loops, always add RewriteCond %{HTTPS} off before the HTTPS redirect rule. Add a second condition RewriteCond %{HTTP:X-Forwarded-Proto} !https for proxy environments. Both conditions together prevent the rule from firing when HTTPS is already established either directly or through a proxy. After editing .htaccess, test with curl --max-redirs 3 to confirm the redirect only fires once before reaching the final HTTPS destination.

For cached 301 redirect loops where the target URL has changed, serve the affected URL with a 302 Found instead of 301 Moved Permanently while you sort out the correct destination. Browsers do not cache 302 responses, so future requests will re-evaluate the redirect on every visit. Once the correct redirect chain is established and tested, switch back to 301. This strategy avoids forcing users to clear their browser cache manually.

For authentication redirect loops, add explicit checks that prevent the login page from redirecting to itself. After a successful POST to the login endpoint, only redirect to the intended destination if the session was successfully saved and the session ID is correctly scoped for the cookie domain. If the session is not persisted before the redirect, the GET that follows the POST will see no session and redirect back to login. Use /tools/http-request-builder to manually send the login POST, capture the Set-Cookie header, and replay a GET request with that cookie to verify the session is accepted before the redirect fires.

Multi-layer proxy architectures create redirect loops that only appear in production because local development typically has no load balancer or CDN. When a request passes through three layers — browser, Cloudflare, AWS ALB, then the application — the X-Forwarded-Proto header may be overridden or duplicated at each layer. The application might see X-Forwarded-Proto: https,http (a list) instead of a single value. Code that does a strict equality check will fail when the header contains multiple comma-separated values. Parse the first value from the list rather than checking the raw header string directly.

Trailing slash redirects interact badly with HTTPS enforcement. If nginx redirects /path to /path/ and the application redirects HTTP to HTTPS, a request to http://example.com/path can trigger two redirects: one for trailing slash and one for HTTPS. If these redirects are served separately instead of combined, some proxy configurations create a loop by applying the trailing slash redirect after the HTTPS redirect has already fired. Fix this by combining both normalizations into a single redirect using the $scheme variable in nginx.

Mobile apps that use in-app browsers or custom HTTP clients often do not handle redirects the same way as Chrome or Firefox. A redirect loop that Chrome stops at 20 iterations may cause a mobile app to loop indefinitely, consuming battery and data. When debugging mobile-specific redirect loops, use Charles Proxy or the iOS/Android network inspector to trace the exact redirect chain your app is following.

Some hosting platforms like Heroku automatically redirect HTTP to HTTPS at the platform level. If your application also has an HTTPS redirect, and the platform redirect adds the X-Forwarded-Proto header while the application's redirect condition does not check it, you get a loop at the Heroku routing layer. Check the platform documentation to confirm whether the platform already handles HTTP-to-HTTPS redirection. If it does, remove the application-level redirect entirely.

Docker compose environments where the application container runs on HTTP and an nginx container handles HTTPS termination are a common source of development-only redirect loops. If the nginx container forwards X-Forwarded-Proto but the application code is not configured to trust it, the developer sees the same HTTPS loop as in production, even though the environment is completely different from the local machine.

Using 301 Moved Permanently before the redirect destination is confirmed stable is the most costly mistake because 301 redirects are cached by the browser and CDNs. If you redirect http://example.com to https://example.com with a 301 and later discover that https://example.com redirects back to http, every browser that cached the initial 301 will loop without any server involvement. Use 302 Found when testing redirect configurations so that the redirect is re-evaluated on each request.

Not setting Cache-Control: no-store on error pages that redirect to authentication is a common authentication loop trigger. When a protected page returns a 302 to the login page and the response has no Cache-Control header, some aggressive caches store the 302. Future requests to the protected page are served the cached 302 pointing to login, regardless of whether the user is authenticated. Set Cache-Control: no-store on all authentication-related redirects.

Relying on redirect behavior to normalize URLs instead of applying normalization before routing creates chains. If one middleware redirects to add a trailing slash, another redirects to lowercase the URL, and a third redirects HTTP to HTTPS, three sequential redirects fire before the request is handled. While not technically an infinite loop, this chain hurts performance and is fragile. Combine URL normalization into a single middleware or a single nginx rewrite rule that handles all transformations at once.

Ignoring the X-Forwarded-Proto header when configuring WordPress FORCE_SSL options is the single most common WordPress redirect loop cause. The correct pattern is to set $_SERVER['HTTPS'] = 'on' when X-Forwarded-Proto is 'https' and place this code before any WordPress core files are loaded in wp-config.php. WordPress derives the current URL scheme from this server variable, so setting it correctly prevents the HTTPS redirect from firing on already-HTTPS requests.

Not testing redirect behavior with curl before deploying to production means loop bugs reach users before they are caught. Add a curl redirect check to your deployment script: curl -L --max-redirs 5 -w '%{num_redirects}' -o /dev/null -s https://example.com. If the number of redirects exceeds 2, investigate before completing the deployment.

Consolidate all redirect logic into a single authoritative layer. Choose either the application layer or the infrastructure layer, not both. If nginx handles HTTPS enforcement, remove all application-level HTTPS redirects. If the application handles it, configure nginx to pass requests through without adding its own redirect rules. Duplicate redirect logic in multiple layers is the leading cause of production redirect loops.

Always use 302 Found during initial setup and testing of new redirect rules. Once the redirect chain is confirmed correct with at least 48 hours of monitoring in production, switch to 301. The 48-hour window allows CDN caches to warm with the new 302 responses, giving you time to catch any edge cases before they are cached as permanent redirects that require cache purging to fix.

Add redirect count monitoring to your application or infrastructure. Log a warning when a request triggers more than two redirects before reaching the final handler. Most legitimate redirect chains are one or two hops at most — HTTP to HTTPS is one redirect, old domain to new domain is one redirect. More than three redirects in a chain is a signal that something is wrong. Use this metric as a deployment health check rather than waiting for users to report ERR_TOO_MANY_REDIRECTS.

Document every redirect rule in your system with its purpose, source URL pattern, destination, and status code. Include the date it was added and the expected duration — some redirects are temporary (domain migrations) while others are permanent (slug changes). When redirect loops appear in production, a map of redirect rules is much faster to reason about than digging through nginx configurations, .htaccess files, application middleware, and CDN settings simultaneously.

Use /tools/http-request-builder to test redirect behavior by sending requests with specific headers like X-Forwarded-Proto and observing the response status and Location header. This is faster than setting up curl with the right flags and is useful for confirming that your application responds correctly to both forwarded and non-forwarded protocol headers. Test with X-Forwarded-Proto: http and X-Forwarded-Proto: https separately to confirm the redirect fires in exactly the right conditions. Pair this with /tools/cors-tester if authentication redirects interact with CORS configuration.