Too Many Redirects: How to Find and Fix a Redirect Loop

1. Record the address that starts the problem

Save the full public address and the time of the error. Keep the scheme, hostname and path: http://example.com, https://example.com and https://www.example.com are different starting addresses. A homepage may work while a particular login or moved page fails.

Run Redirect checker with the affected public URL. NetLuma follows supported HTTP redirects and shows the response code and destination at each step. It makes at most six requests in a trace. A shorter trace may end earlier because of a connection error, unsupported destination or another safety limit.

2. Look for the same address coming back

Read the addresses in order. A normal move can pass through an old hostname and finish at the intended new page. A repeated address with a continuing redirect is evidence of a loop in that trace.

This simplified example shows conflicting hostname rules. The first rule sends visitors to www, while the second sends them back to the root domain. These are illustrative addresses, not a live test result.

On a small screen, scroll the table sideways to see both columns.

3. Separate an incomplete trace from a confirmed loop

If NetLuma stops at its six-request limit without showing a repeated address, it has not established a loop. The website could have a long chain, or a loop could exist beyond the part inspected. Review the visible destinations and continue the investigation through your browser’s network tools or your provider.

NetLuma does not execute JavaScript, follow HTML refresh instructions or carry your browser login session. A trace ending at an HTTP 200 can therefore differ from what happens after a browser runs the page. If the browser still loops, investigate those additional navigation or session conditions.

4. Review the rules that disagree

If you own the site, decide which public HTTPS hostname and page should be the destination. List where redirects are configured: the hosting dashboard, server rewrite rules, CDN settings and the application itself. Use the observed chain to find which layer controls each move.

Look for opposite instructions such as root to www followed by www to root, or HTTPS to HTTP followed by HTTP to HTTPS. Rules can also send a moved page back to its old path. Keep a backup, adjust one conflicting instruction and repeat the same trace before making another change.

If you cannot identify the layer returning a particular redirect, give your host the starting URL, ordered destinations, response codes and observation time. This is more specific than reporting only the browser’s “too many redirects” message.

5. Check the origin connection if Cloudflare is involved

Cloudflare’s Flexible mode uses HTTP between Cloudflare and the origin. If that origin redirects its HTTP requests back to HTTPS, the same cycle can repeat. Review the selected encryption mode together with the origin’s redirect behavior.

When the origin is intended to receive HTTPS, configure a valid origin certificate and an appropriate verified HTTPS setup before choosing Full (strict). Cloudflare documents the certificate requirements for that mode. Also review any origin rule that redirects HTTPS back to HTTP. Match the settings across both ends rather than disabling certificate validation.

6. Retest the page and the browser session

After repairing the rule, repeat the original trace and open the final page in a fresh browser session. Confirm that the destination is the intended page, not just an error or sign-in screen returning 200. Check the homepage and the affected path separately.

If the trace is now stable but one browser still fails, compare a private window and the affected site’s cookies or cached redirects. Clear only the relevant site data when needed, remembering that this can sign you out. A server-side loop still needs its configuration fixed; clearing a visitor’s data does not repair conflicting rules.

NetLuma reports one observation from its hosting server. Keep the before-and-after chain when asking for further help, especially if different networks or signed-in sessions still behave differently.