ERR_TOO_MANY_REDIRECTS

What this error means & how to recognize it

• The browser displays “This page isn’t working — [domain] redirected you too many times” or the error code ERR_TOO_MANY_REDIRECTS.
• The address bar repeatedly switches between HTTP and HTTPS, or between www and non-www hostnames, before the browser stops loading.
• The entire site may fail, or the problem may be limited to one URL, the admin area, logged-in sessions, or particular devices.
• The issue often begins after enabling HTTPS, adding a CDN or reverse proxy, changing the canonical hostname, or installing a redirect or SSL plugin.
• Clearing cookies may temporarily change the behavior when authentication or session logic is involved, but it does not fix a server-side redirect conflict.

Root causes, ordered by likelihood

1. Conflicting HTTP/HTTPS rules — one layer redirects HTTP to HTTPS while another incorrectly redirects HTTPS back to HTTP. This commonly occurs when a proxy or CDN terminates TLS but the origin does not recognize that the original request was secure.
2. CDN SSL/TLS mode mismatch — a CDN may use HTTP to connect to an origin that forces HTTPS. The origin redirects to HTTPS, but the CDN repeats the HTTP-to-origin request, creating a loop.
3. Competing www and non-www canonical rules — the CDN, web server, CMS, or a plugin may disagree about which hostname is canonical.
4. Incorrect proxy or forwarded-protocol handling — the application may not trust the configured proxy or correctly process X-Forwarded-Proto or an equivalent header, so it repeatedly treats a secure request as HTTP.
5. Stale redirect caching — a browser, CDN, reverse proxy, or page cache may still serve a redirect from before the configuration was corrected.
6. Duplicate application or plugin rules — force-SSL, login, maintenance, or redirect plugins may conflict with server-level rules.
7. Cookie or session configuration problems — incorrect Secure, domain, or path settings can cause authentication redirects for only some users, especially logged-in visitors.

How to fix it

1. Capture the redirect chain first

Use a read-only request from a terminal, replacing the placeholder with the affected hostname:

curl -IL https://[your-hostname]

This requests headers and follows redirects. Record every Location: value and HTTP status code. Test the exact failing URL, the HTTP version, and both www and non-www forms where relevant. A browser’s Network panel provides similar evidence.

Look for patterns such as:

• HTTPS → HTTP → HTTPS
• non-www → www → non-www
• one URL repeatedly redirecting to itself
• a redirect to a login or canonical URL that immediately redirects back

Do not begin by clearing caches or changing several settings at once. The chain helps identify which layer needs attention.

2. Fix an HTTP/HTTPS or CDN loop

If a CDN or reverse proxy handles the public HTTPS connection, inspect its SSL/TLS mode and the origin’s certificate and HTTPS configuration. The CDN-to-origin mode must match what the origin supports. With Cloudflare, an origin that correctly supports HTTPS generally requires Full or Full (strict) rather than Flexible when the origin itself forces HTTPS.

Before changing the mode, confirm that you are authorized to modify the CDN and that the origin has a valid certificate for the hostname when strict certificate validation is used. Changing CDN TLS settings can affect live traffic, so follow the approved change process or maintenance-window requirements.

3. Correct proxy HTTPS detection

If the application forces HTTPS while running behind a proxy, configure the application or framework to trust the intended proxy and recognize the forwarded protocol. Depending on the platform, settings may be called trust proxy, trusted proxies, or force-SSL settings.

Only trust forwarded-protocol headers from a known, controlled proxy path. Do not blindly trust client-supplied headers on a directly exposed origin. Check the platform’s documentation for the correct setting, then retest the redirect chain.

4. Resolve www versus non-www disagreement

Choose one canonical hostname and document it. Inspect the CDN, web-server configuration, .htaccess rules where applicable, CMS URL settings, and redirect plugins.

Keep one authoritative hostname redirect—for example, non-www to www or www to non-www—and remove duplicate or opposing rules. Check all HTTP and HTTPS variants after the change. A canonical URL setting that differs from the web server’s target can recreate the loop even when HTTPS is configured correctly.

5. Review application, login, and cookie behavior

If anonymous users can load the page but logged-in users cannot, compare the redirect chain with and without the session cookie using an authorized test account or a private window. Inspect force-SSL, login, membership, and redirect plugins, along with the application’s configured site URL.

Check that session cookies use the correct Secure attribute, domain, and path for the chosen HTTPS hostname. Disable or change one suspected plugin at a time under the change-control process. Do not remove authentication or security controls on a production site without a rollback plan.

6. Purge stale redirects and retest

After correcting the configuration, purge relevant CDN, reverse-proxy, and page-cache entries if you are authorized to do so. Browser redirects can also persist, so retest with curl, a private window, and, if needed, a separate network or device.

A successful test should reach the intended page without a repeating Location sequence. Check the canonical hostname, HTTP-to-HTTPS behavior, login flow, and representative internal URLs rather than testing only the home page.

Prevention & how to verify the fix

• Document the canonical hostname and intended HTTP-to-HTTPS behavior before adding a CDN, reverse proxy, CMS plugin, or server rule.
• Keep each redirect decision authoritative in one layer where possible, and ensure other layers do not issue an opposing rule.
• When placing a site behind a proxy, configure trusted-proxy and forwarded-protocol handling deliberately; do not accept client-supplied forwarding headers indiscriminately.
• Test the full redirect chain after HTTPS, hostname, CDN, CMS, or plugin changes using the exact URLs users access.
• Include anonymous, logged-in, www, non-www, HTTP, and HTTPS tests in deployment checks when those paths are supported.
• Purge or version relevant caches after redirect changes, then verify from a private window or clean client.

Frequently asked questions