ERR_TOO_MANY_REDIRECTS: how to fix a redirect loop

Trace the loop first

Before changing settings, see the loop. The redirect checker lists every hop with its status code, its Location target and its timing, and flags when the chain loops. The pattern of the hops points straight at the cause:

• http:// and https:// alternating: two layers disagree about HTTPS, often a CDN and the origin server.
• www and non-www alternating: two layers disagree about the canonical hostname.
• The same URL with and without a trailing slash, or with different capitalisation: conflicting rewrite rules.
• The same URL redirecting to itself: a rule that does not realise the request already arrived over HTTPS, typical behind a proxy.

Cloudflare Flexible SSL and an origin HTTPS redirect

This is a classic loop. In Cloudflare's Flexible encryption mode, visitors connect to Cloudflare over HTTPS, but Cloudflare connects to your server over plain HTTP. If your server redirects every HTTP request to HTTPS, it sends Cloudflare a redirect, which Cloudflare passes to the browser, which requests HTTPS from Cloudflare again, which fetches over HTTP again, forever.

The durable fix is to set Cloudflare's SSL/TLS encryption mode to Full (strict) and give the origin server a valid certificate, either from Let's Encrypt or a Cloudflare Origin CA certificate. Cloudflare's documentation also lists the opposite case: in Full modes, an origin that redirects HTTPS back to HTTP loops as well, as does the Always Use HTTPS setting combined with such an origin redirect.

WordPress URL settings

WordPress stores two addresses, the WordPress Address (siteurl) and the Site Address (home), and redirects requests to match them. If they disagree with the server's or CDN's redirects, for example WordPress set to http:// while the server forces https://, or WordPress set to www while the host redirects to non-www, the two sides bounce the visitor back and forth.

When the dashboard is unreachable because of the loop, set the values in wp-config.php with define('WP_HOME', 'https://example.com') and define('WP_SITEURL', 'https://example.com'), using your real canonical address. Alternatively, update the home and siteurl rows in the wp_options table with phpMyAdmin, or run wp option update home and wp option update siteurl with WP-CLI.

Behind a proxy or CDN that terminates HTTPS, WordPress may not realise the visitor is on HTTPS and keep redirecting to it. The WordPress documentation for wp-config.php describes the fix: when the HTTP_X_FORWARDED_PROTO server variable equals https, set $_SERVER['HTTPS'] to 'on' near the top of wp-config.php.

www, non-www and conflicting rules

Redirects can be set in many places at once: the CDN's redirect rules, the hosting control panel, .htaccess or the nginx configuration, the application's own settings, and plugins. When two of them pick different canonical hostnames, they loop.

Pick one canonical form, such as https://example.com or https://www.example.com, and enforce it in one place, ideally at the edge or the web server. Then make every other layer agree with it or stop redirecting. Check the DNS too: both names need to point at the same site before a hostname redirect can work.

Plugins, cookies and other causes

If the loop started after installing or changing a plugin, the plugin is the first suspect:

• SSL and HTTPS plugins that add their own HTTP-to-HTTPS redirect on top of an existing one at the server or CDN.
• Redirect manager plugins with a rule that matches its own target.
• Security, login and membership plugins that redirect to a login page that itself requires a login.
• Language, currency or location redirects that send visitors between versions based on a cookie or IP address.
• Caching plugins or CDN caches that stored a redirect response and keep serving it after the underlying rule changed.

Step-by-step fix

Work through these in order, rechecking with the redirect checker after each change:

1. 1Clear cookies for the site, or open it in a private window. If the loop disappears, it depends on a cookie, typically a login, consent or language cookie.
2. 2Run the redirect checker on the http, https, www and non-www versions and write down which hosts and protocols alternate.
3. 3If the site is on Cloudflare, check the SSL/TLS encryption mode. Move from Flexible to Full (strict) once the origin has a valid certificate.
4. 4Check the WordPress Address and Site Address, or the equivalent base URL setting in other applications, against your chosen canonical address.
5. 5Review redirect rules at each layer (CDN rules, control panel, .htaccess or nginx, plugins) and remove duplicates so only one layer handles each redirect.
6. 6Deactivate recently added plugins. On WordPress, renaming the plugins folder over SFTP disables all of them when the admin area is unreachable.
7. 7Purge the page cache and the CDN cache, then retest.

After the fix: cached redirects

A fixed loop can keep appearing for some visitors. Browsers cache permanent (301 and 308) redirects, sometimes for a long time, so anyone who received a looping 301 may keep following the cached hop until their browser cache is cleared. CDN and page caches can hold redirect responses too, which is why purging them is part of the fix.

To confirm the configuration itself is fixed, test from a clean environment: a private window, a different browser, or the redirect checker, which requests the URL fresh each time. If the clean test is fine, the remaining reports come from caches and will clear on their own, or after visitors clear site data. While setting up new redirect rules, a temporary 302 avoids this caching problem until the rules are confirmed.