WordPress “Too Many Redirects” After SSL or Reverse Proxy Setup: The Real Root Cause

If this started right after you added SSL, put your site behind Cloudflare, or set up a reverse proxy/load balancer, you’re not dealing with a broken site — you’re dealing with two systems that disagree about what the correct URL actually is. Every layer between the visitor’s browser and your WordPress install is capable of independently deciding “this request is wrong, redirect it” — and when two of those layers disagree with each other, you get an infinite loop instead of a working page.

Most guides hand you a grab-bag of seven possible fixes and tell you to try them in order. Here’s the actual mental model for diagnosing this correctly the first time, plus the specific fixes for each real cause.

The Mental Model: A Redirect Chain Has Multiple Decision-Makers

A typical request to a WordPress site behind SSL and/or a proxy passes through several layers, and each one can independently issue a redirect:

1. The CDN/edge layer (Cloudflare or similar) — may enforce HTTPS, rewrite the host, or apply its own redirect rules
2. The reverse proxy or load balancer — terminates SSL and forwards the request to your actual server, sometimes changing the scheme or port in the process
3. The web server (Nginx or Apache) — has its own vhost-level rules that may redirect based on scheme or host
4. WordPress itself — checks its stored Site URL/Home URL values and is_ssl() logic, and will redirect if what it sees doesn’t match what it expects

A redirect loop happens when two of these layers each think they’re correcting a “wrong” URL, and their corrections point at each other. You’re not looking for “the one broken setting” — you’re looking for which two layers are fighting.

The Core Technical Problem: SSL Termination Hides HTTPS From WordPress

Here’s the mechanism specifically behind the SSL/proxy version of this error, which is the most common variant by far:

When a reverse proxy, load balancer, or CDN terminates SSL on your behalf, it accepts the secure HTTPS connection from the visitor — but then forwards the request to your actual WordPress server over plain HTTP internally. This is completely normal and by design. The problem is that WordPress has no way of knowing this happened unless it’s explicitly told.

WordPress decides whether a request is secure by checking $_SERVER['HTTPS']. Behind a proxy, that value is typically empty, even though the original visitor connection was genuinely encrypted. If anything tells WordPress to force HTTPS — a security plugin, an .htaccess rule, the FORCE_SSL_ADMIN constant — WordPress sees what looks like an insecure HTTP request and redirects to HTTPS. The proxy strips SSL again on the way back to your server. WordPress sees HTTP again. It redirects to HTTPS again. Loop.

Diagnose This Properly Before Touching Anything

Skip guesswork. Run this from a terminal:

curl -IL https://example.com

This shows you every hop in the redirect chain — the scheme, host, and status code at each step. What you’re looking for is the exact toggle point: does it flip between http:// and https://? Between www and the bare domain? That toggle point tells you precisely which two layers are disagreeing.

If you suspect your CDN or proxy is part of the problem, bypass it temporarily by editing your local hosts file to point directly at your origin server, then re-run the same request with the domain’s Host header. If the loop disappears when hitting the origin directly, the conflict is between your CDN/proxy and your origin. If the loop persists even hitting the origin directly, the problem is entirely within WordPress or your web server config — the CDN isn’t the cause.

Fix #1: Tell WordPress to Trust the Proxy’s Forwarded-Proto Header

This is the fix for the SSL-termination scenario described above, and it resolves the large majority of “too many redirects after adding SSL/reverse proxy” cases. Add this near the top of wp-config.php, above the line that says /* That's all, stop editing! */:

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

This tells WordPress: “if the proxy says the original connection was HTTPS, trust that and stop trying to force a redirect.” Your reverse proxy or load balancer needs to actually be sending this header in the first place — if it isn’t, this fix won’t do anything, because there’s nothing for WordPress to read.

Make Sure Your Proxy Is Actually Sending the Header

For an Nginx reverse proxy, confirm your config includes:

location / {
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_pass http://backend;
}

If you’re running Nginx with PHP-FPM directly (no separate reverse proxy layer, just FastCGI), the fix is slightly different — you need to pass the HTTPS parameter directly in your PHP location block, and this line needs to come after the standard fastcgi_params include, not before:

location ~ \.php$ {
    include fastcgi_params;
    fastcgi_pass unix:/run/php/php8.2-fpm.sock;
    fastcgi_param HTTPS on;
}

Fix #2: Check for a Mismatched Site URL / Home URL

WordPress stores two URL values — WP_HOME and WP_SITEURL — in the database (or as constants, if defined). If one is set to http:// and the other to https://, or one includes www and the other doesn’t, you get a loop independent of any proxy issue. Check both values directly; if you can’t get into wp-admin to fix them through Settings, define them directly in wp-config.php instead, which overrides the database values:

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

Fix #3: Check Your CDN’s SSL Mode (Cloudflare Specifically)

If you’re using Cloudflare, this is one of the single most common causes of this exact error. Cloudflare’s SSL/TLS mode determines how Cloudflare connects to your actual origin server:

• Flexible — Cloudflare accepts HTTPS from visitors but connects to your origin over plain HTTP. If your WordPress install also forces HTTPS, this creates the textbook loop: origin redirects HTTP→HTTPS, Cloudflare strips SSL again on the way back, origin redirects again.
• Full or Full (strict) — Cloudflare connects to your origin over HTTPS too, which avoids this specific conflict entirely (assuming your origin has a valid SSL certificate, which Full Strict specifically requires).

Check this under Cloudflare’s dashboard at SSL/TLS → Overview. If you’re on Flexible and you have a working SSL certificate on your actual server, switching to Full (or Full Strict) resolves this immediately in most cases.

Fix #4: Remove Duplicate Redirect Enforcement

A frequent, avoidable cause: more than one layer is trying to enforce the same HTTPS redirect simultaneously. If Cloudflare’s “Always Use HTTPS” is switched on, but you also have a WordPress SSL plugin (Really Simple SSL and similar are common culprits) and/or a server-level redirect rule all doing the same job, they can interfere with each other rather than cooperating. Pick exactly one layer to own this — ideally the edge (Cloudflare) or the web server config, not WordPress plus multiple plugins — and disable the redundant enforcement everywhere else.

If you’re keeping the redirect at the web server level, make sure the rule only fires when the proxy header confirms the request truly isn’t HTTPS, rather than firing unconditionally:

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

Fix #5: Rule Out Plugins and Cached Redirects

If none of the above resolves it, a plugin may be issuing its own conflicting redirect logic. Test via WP-CLI or by renaming your plugins folder over FTP/SFTP (WordPress automatically deactivates all plugins if it can’t find the folder):

mv wp-content/plugins wp-content/plugins.disabled

Reload the site. If the loop disappears, rename the folder back and reactivate plugins one at a time — security plugins, SSL plugins, and redirect-management plugins (Really Simple SSL, Redirection, and various caching plugins) are the most common offenders. Also purge any cached redirects at every layer (browser, plugin cache, CDN cache) before retesting, since a stale cached 301 can make a fix look like it didn’t work even after the actual cause is resolved.

Why This Is More Common — and More Avoidable — on Some Hosting Setups Than Others

This entire category of error exists because HTTPS enforcement and proxy header handling are split across multiple independently-configured layers: your CDN, your web server, your WordPress install, and any plugins managing SSL. The more of those layers you’re personally responsible for wiring together correctly, the more opportunities there are for two of them to disagree.

Hosting platforms that handle SSL termination and proxy header configuration at the infrastructure level — rather than leaving it to a mix of .htaccess rules and third-party SSL plugins — eliminate an entire category of this problem before it can happen. If you’re evaluating hosts specifically on how cleanly they handle SSL and reverse proxy configuration, WP Host Finder’s hosting comparison covers which providers manage this at the platform level versus which leave it entirely to you.

For a closer look at one host that handles HTTPS enforcement and proxy headers server-side by default, see the full Kinsta review here.

Frequently Asked Questions

Why did this only start after I added SSL or Cloudflare, when the site worked fine before?

Because before SSL/proxy was added, there was only one scheme (HTTP) and one layer making decisions about it. Adding HTTPS and/or a proxy introduces a second layer with its own opinion about the canonical scheme — and if those two layers aren’t explicitly told to agree, they conflict.

Is this WordPress’s fault?

Not really — WordPress is behaving correctly based on what it can see. It can’t know a connection was originally HTTPS if the proxy strips that information before forwarding the request. The fix is making sure that information actually gets passed through, not “fixing” WordPress itself.

I fixed the redirect loop on the homepage, but wp-admin still loops. Why?

The admin area often has separate, stricter HTTPS enforcement (via FORCE_SSL_ADMIN or plugin-specific admin rules) than the rest of the site. Apply the same proxy-header fix, but double check it’s also being respected specifically on admin-path requests, not just the public-facing pages you tested first.

Final Thoughts

“Too many redirects” isn’t one bug with seven possible causes — it’s always the same underlying problem: two systems disagreeing about the canonical URL. Once you map the actual redirect chain with curl -IL and identify exactly where the toggle happens, the fix is almost always obvious. Diagnose first, then fix the one layer that’s actually wrong — don’t disable things at random and hope.