How to Fix Too Many Redirects in WordPress With Cloudflare

You put a WordPress site behind Cloudflare and the browser now says This page isn't working. example.com redirected you too many times. with ERR_TOO_MANY_REDIRECTS (Firefox calls it “The page isn’t redirecting properly”). Something is sending the browser in a circle, usually between HTTP and HTTPS. Here is how to find the loop and fix too many redirects in WordPress with Cloudflare properly, not by turning random settings off.

Quick fix

The most common cause is Cloudflare’s Flexible SSL mode combined with a server or WordPress that forces HTTPS. With Flexible, Cloudflare talks to your origin over plain HTTP. Your origin sees an HTTP request and redirects to HTTPS, the browser follows, Cloudflare fetches over HTTP again, and the loop never ends.

1. Make sure your origin server has a valid SSL certificate: a free Let’s Encrypt certificate from your host, or a Cloudflare Origin CA certificate (SSL/TLS, Origin Server, Create Certificate) installed on the server.
2. In the Cloudflare dashboard, go to SSL/TLS, Overview and set the encryption mode to Full (strict).
3. Purge the Cloudflare cache (Caching, Configuration, Purge Everything) and test in a private window, because browsers cache 301 redirects.

Full (strict) means Cloudflare connects to your origin over HTTPS and validates its certificate. The origin sees HTTPS, stops redirecting, and the loop is gone. Avoid plain “Full” as a long-term setting: it encrypts the connection but accepts any certificate, including an expired or self-signed one.

Common causes, most likely first

1. Flexible SSL plus forced HTTPS at the origin

Covered above. The forcing can come from several places: an .htaccess rule, a “Force HTTPS” toggle in your hosting panel, a plugin such as Really Simple SSL, or WordPress itself when home and siteurl start with https://. Full (strict) fixes all of them at once.

2. siteurl and home don’t match your real URL

WordPress redirects requests to the host and scheme stored in the home option. If home is https://www.example.com but a Cloudflare redirect rule sends www to the bare domain, the two bounce visitors back and forth forever. The same applies to http vs https. Check and correct both values:

wp option get home
wp option get siteurl
wp option update home 'https://example.com'
wp option update siteurl 'https://example.com'

If you cannot run WP-CLI, hard-code the values in wp-config.php, which overrides the database:

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );

If old http:// URLs remain in content, run a search-replace with a dry run first: wp search-replace 'http://example.com' 'https://example.com' --skip-columns=guid --dry-run. Leftover HTTP assets cause mixed content warnings rather than loops; see my guide to fixing mixed content.

3. WordPress doesn’t know the request was HTTPS

Behind some proxies and load balancers, PHP never sees $_SERVER['HTTPS'], so is_ssl() returns false and wp-admin keeps redirecting to HTTPS. This shows up as a loop only on /wp-admin/ or the login page, especially with FORCE_SSL_ADMIN on. Tell WordPress to trust the forwarded scheme by adding this to wp-config.php above the “stop editing” line:

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] )
    && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https' ) {
    $_SERVER['HTTPS'] = 'on';
}

Cloudflare sends X-Forwarded-Proto with the visitor’s scheme. Only rely on this header if the origin is reached through Cloudflare or your own proxy, since a client hitting the origin directly can set it to anything.

4. Conflicting redirect rules in .htaccess or plugins

Two layers each enforcing a different canonical URL will loop: a hosting rule forcing www, a plugin forcing non-www, a trailing-slash rule fighting WordPress’s own canonical redirect. Open .htaccess and look for RewriteRule lines with R=301 above the # BEGIN WordPress block. A proxy-aware HTTPS rule looks like this:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

With Full (strict) and Cloudflare’s “Always Use HTTPS” enabled, you usually don’t need an origin HTTPS rule at all. Pick one place to own each redirect and remove the rest, including redirect plugins with overlapping rules.

5. Cloudflare rules you forgot about

This is the cause experienced developers miss, because nothing on the server changed. Check Rules in the Cloudflare dashboard: old Page Rules with “Forwarding URL”, newer Redirect Rules, and Configuration Rules that override the SSL mode for one hostname or path. A Configuration Rule setting SSL to Flexible for www recreates the original loop even though the zone says Full (strict). Also check whether a redirect response was cached at the edge by a “Cache Everything” rule, and purge it.

Step-by-step diagnosis with curl

The browser hides the chain. curl shows every hop:

curl -sIL --max-redirs 10 https://example.com/ 
  | grep -iE '^(HTTP/|location:|server:|cf-cache-status:|x-redirect-by:)'

1. Read the Location headers. If they alternate between http:// and https://, it is an SSL mode or forced-HTTPS problem. If they alternate between www and non-www, or with and without a trailing slash, it is a canonical URL conflict.
2. Look for X-Redirect-By. When WordPress itself issues a redirect through wp_redirect(), it adds X-Redirect-By: WordPress (plugins can set their own value). If the header is missing, the redirect came from the web server, the host or Cloudflare.
3. Bypass Cloudflare. Hit the origin directly to see what it does on its own:

curl -sIk --resolve example.com:443:203.0.113.10 https://example.com/

Replace 203.0.113.10 with your origin IP. If the origin returns 200 over HTTPS, the loop lives in Cloudflare settings or rules. If it redirects to itself, the problem is on the server.

4. Check the SSL mode and rules in Cloudflare, including Configuration Rules per hostname.
5. Check home and siteurl and any WP_HOME constants.
6. Disable plugins with wp plugin deactivate --all if the chain shows X-Redirect-By values from a plugin.
7. Clear caches: Cloudflare, any page cache plugin, and your browser. A fixed loop can look broken because a cached 301 is still served.

Prevention

• Use Full (strict) from day one, with a real certificate on the origin. Never use Flexible on a site that has its own SSL.
• Decide on one canonical URL (scheme, www or not) and set it in home, siteurl and Cloudflare before going live.
• Let one layer own each redirect. I prefer Cloudflare for HTTPS and host canonicalisation, and WordPress for content redirects.
• Document every Cloudflare rule and review them when you change hosts or domains.
• Test with curl -IL after any DNS, SSL or plugin change.

Key takeaways

• Flexible SSL plus any HTTPS enforcement at the origin is the classic Cloudflare redirect loop.
• The fix is Full (strict) with a valid origin certificate, such as a Cloudflare Origin CA cert.
• home and siteurl must match the exact canonical URL that Cloudflare redirects to.
• Map X-Forwarded-Proto to $_SERVER['HTTPS'] when WordPress can’t detect HTTPS behind a proxy.
• curl -sIL shows every hop; the Location pattern tells you which layer is looping.

Frequently asked questions

Why does Cloudflare cause too many redirects on WordPress?

Usually because the SSL mode is Flexible, so Cloudflare connects to your server over HTTP while your server or WordPress redirects every HTTP request to HTTPS. Switching to Full (strict) with a valid origin certificate stops the loop.

Should I use Full or Full (strict) SSL in Cloudflare?

Use Full (strict). Both encrypt the connection to your origin, but only Full (strict) checks the origin certificate is valid, which protects against interception between Cloudflare and your server.

Why do I only get a redirect loop on wp-admin?

WordPress forces HTTPS for the admin and doesn’t detect that the request was already HTTPS behind the proxy. Setting $_SERVER['HTTPS'] = 'on' when HTTP_X_FORWARDED_PROTO is https in wp-config.php usually fixes it.

I fixed the settings but still see ERR_TOO_MANY_REDIRECTS. Why?

The redirect is probably cached in your browser or at Cloudflare. Purge the Cloudflare cache and any page cache, then test in a private window or with curl -IL.

Still stuck in a loop? Contact me and I can untangle your Cloudflare, server and WordPress redirect setup. Once HTTPS is working, my WordPress security hardening checklist is a good next step.

• #Cloudflare
• #Redirects
• #SSL
• #Troubleshooting
• #WordPress