Fix WordPress ERR_TOO_MANY_REDIRECTS Behind StackPath CDN

You update your DNS to point at StackPath, open your site in Chrome, and immediately get slapped with ERR_TOO_MANY_REDIRECTS. Chrome gives up after 20 hops, and your origin server access logs are spinning out with identical 301 responses hitting the same URL over and over.

I ran into this exact loop migrating a client’s WooCommerce store onto StackPath edge caching last week. It took ten minutes to fix once I caught the SSL miscommunication between Nginx at the origin and the edge proxy. Here is how to trace the loop from your terminal, patch wp-config.php to read reverse proxy headers, align your StackPath origin pull settings, and dump the poisoned redirects sitting in edge cache memory.

Why the Redirect Loop Happens Behind StackPath

Redirect loops behind a reverse proxy CDN almost always boil down to an SSL identity crisis. A visitor hits your site over HTTPS on port 443. StackPath terminates that SSL connection right at their edge node nearest the visitor.

Next, StackPath turns around and requests the uncached page from your origin server. If your StackPath Site Delivery settings are configured to fetch from your origin over plain HTTP on port 80, the request lands on Apache or Nginx completely unencrypted. Your web server sees raw HTTP, and WordPress does what it always does when configured for HTTPS: it immediately fires a 301 Moved Permanently redirecting back to https://yourdomain.com.

StackPath takes that 301 from your origin, hands it straight to the browser, and the browser dutifully requests the HTTPS address again. StackPath calls the origin over HTTP again, the origin fires another 301, and you are trapped in an infinite ping-pong match. To break it, WordPress needs to know the visitor was on HTTPS all along via proxy forwarding headers, or StackPath needs to pull from your origin over port 443.

Inspecting the Loop with cURL

Before editing any config files or clicking around in dashboards, replicate the loop in your terminal. Chrome and Safari cache 301s aggressively on disk, which makes debugging in a browser a nightmare—you will think you haven’t fixed the issue when you actually have.

Run a trace with cURL to follow the redirect trail cleanly:

curl -ILs https://example.com | grep -E "HTTP/|Location:"

If you are stuck in the loop, you will see output like this scrolling past over and over:

HTTP/2 301 location: https://example.com/
HTTP/2 301 location: https://example.com/
HTTP/2 301 location: https://example.com/

When you see the exact same URL bouncing back on itself, or toggling infinitely between http:// and https://, you have confirmed the proxy mismatch. You can read more about how clients handle these status codes in the MDN documentation on 301 redirects.

Fix 1: Configure wp-config.php for Reverse Proxy Headers

When StackPath fetches content from your origin server, it forwards an industry-standard HTTP header: X-Forwarded-Proto: https. That header tells your origin that the original visitor connected via an encrypted SSL session.

WordPress does not look for this header out of the box. By default, it looks at whether $_SERVER['HTTPS'] is set to on or if the connection arrived on local port 443. Because StackPath connected to your server on port 80, WordPress assumes the request is insecure and tries to force a canonical redirect.

Open your site’s wp-config.php via SSH or SFTP. Paste this block near the top, right above the line that reads /* That's all, stop editing! Happy publishing. */:

// Recognize SSL termination behind StackPath CDN
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') { $_SERVER['HTTPS'] = 'on';
}
if (isset($_SERVER['HTTP_X_FORWARDED_PORT']) && $_SERVER['HTTP_X_FORWARDED_PORT'] === '443') { $_SERVER['SERVER_PORT'] = 443;
}

This tells WordPress: “If StackPath sent X-Forwarded-Proto: https, treat the connection as an active SSL session.” That single snippet immediately stops WordPress core from issuing canonical HTTPS redirects on proxy requests. For deeper context on how reverse proxies interact with WordPress internals, check the WordPress documentation on Administration over SSL as well as the spec for X-Forwarded-Proto headers on MDN.

Fix 2: Match Origin Connection Protocol in StackPath

Patching wp-config.php stops the loop if StackPath talks over port 80, but sending unencrypted traffic between the CDN edge and your host isn’t ideal. The cleaner, more secure fix is telling StackPath to connect to your origin over HTTPS on port 443.

Assuming you have a working SSL cert on your hosting origin (like a standard free Let’s Encrypt certificate), configure StackPath to use HTTPS end-to-end:

1. Log in to the StackPath Control Portal.
2. Select your Site Delivery CDN site from your dashboard.
3. Click the Origin tab in the sidebar.
4. Find your Origin Server and click the Edit (pencil) icon.
5. Under Origin Protocol, switch from HTTP to HTTPS Only (or Match Client).
6. Make sure the Origin Port is set to 443.
7. If your hosting server uses Server Name Indication (SNI)—which almost every modern shared host or VPS does—toggle on Enable SNI and make sure the origin hostname matches your domain.
8. Save your changes.

If you haven’t wired up SSL across your domain registrar, CDN, and hosting platform yet, walk through our guide on how to configure end-to-end SSL with Namecheap, StackPath, and Hostinger to ensure your certificates are valid all the way through the pipeline.

Fix 3: Remove Conflicting Rules in .htaccess and Nginx

Sometimes the loop isn’t WordPress core at all—it’s an aggressive rewrite rule sitting in your web server config. A very common blunder is adding Apache .htaccess directives that force HTTPS without accounting for reverse proxies.

Here is an example of an .htaccess rule that breaks every time behind StackPath:

# BROKEN: Will loop behind a reverse proxy connecting over HTTP
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Because the connection from StackPath’s edge to Apache is HTTP on port 80, %{HTTPS} evaluates to off on every incoming request. Apache keeps firing 301 redirects, ignoring the fact that the visitor is already on an HTTPS URL in their browser.

Swap that out for a proxy-aware rewrite condition in your .htaccess file:

# FIXED: Checks for both native SSL and proxy forwarding headers
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

If you are running Nginx directly instead of Apache, inspect your server block (typically under /etc/nginx/sites-available/) and verify you handle the forwarded proto variable properly:

# Nginx proxy header check
if ($http_x_forwarded_proto != "https") { return 301 https://$host$request_uri;
}

If your host uses LiteSpeed, you can run into similar headaches with asset paths or mixed content right after sorting out the base URL. See our troubleshooting notes on how to resolve WordPress mixed content with LiteSpeed and .htaccess on Hostinger to ensure all stylesheets and scripts load cleanly over HTTPS.

Fix 4: Correct WordPress Site URL and Home Values

Another classic trigger is a protocol mismatch in your database’s wp_options table. If your visitors hit https://example.com, but your database has http://example.com stored as the site URL, WordPress will continually try to bounce users down to plain HTTP.

Check your current database values with WP-CLI:

wp option get siteurl
wp option get home

Both strings must start with https:// and match domain structures (either both use www or both don’t). If either shows plain http://, update them immediately via WP-CLI:

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

If you do not have SSH or WP-CLI access on your server, hardcode both constants into your wp-config.php file directly above the proxy snippet we added earlier:

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

This overrides whatever stale strings are in the database and ensures WordPress calculates internal links and canonical targets with HTTPS from the jump.

Fix 5: Purge Cached 301 Redirects from the Edge

This is the step that trips up almost everyone: StackPath caches HTTP 301 responses by default.

You can update wp-config.php, fix your .htaccess, and sanitize your database—and still see ERR_TOO_MANY_REDIRECTS. That happens because while your site was looping, StackPath edge nodes requested your homepage, got a 301 Moved Permanently response from your broken origin, and cached that redirect at the edge with a long TTL.

You have to purge the edge cache to get rid of the poisoned responses:

1. Head into your CDN site inside the StackPath console.
2. Click the Overview or Cache tab.
3. Hit the Purge Cache button in the top right corner.
4. Select Purge All.
5. Confirm the purge.

StackPath invalidates edge cache across all its global PoPs in under a second. Once that purge completes, run your terminal checks again to verify the origin is serving live responses.

If you run a membership site or WooCommerce store behind StackPath, double-check your edge cache bypass rules so session cookies don’t accidentally cache dynamic user states. Check our walkthrough on how to bypass StackPath CDN cache for logged-in WordPress users so auth cookies never get trapped in edge nodes.

Verifying the Fix with cURL

With proxy headers configured, origin protocols matched, rewrites cleaned up, and the edge cache purged, test the site directly from your command line.

Run a clean cURL inspection against your domain:

curl -ILs https://example.com | grep -E "HTTP/|Location:|x-hw:"

You should see a clean response with an immediate HTTP/2 200 status code and zero intermediate hops:

HTTP/2 200 x-hw: 1683419201.d01.nyc.1, 1683419201.c01.nyc.1

If you deliberately query an insecure URL like http://example.com, you should see exactly one clean 301 hop directly to https://example.com, followed immediately by an HTTP/2 200. That confirms the loop is broken, canonical enforcement is intact, and StackPath is serving pages without tripping over origin redirects.

FAQ: WordPress Redirects Behind StackPath

Why does clearing my browser cache not fix ERR_TOO_MANY_REDIRECTS immediately?

Browsers treat HTTP 301 redirects as permanent cache directives. When Chrome sees a 301, it saves that route directly to disk and won’t even query the network next time you visit the URL. Always verify fixes using an incognito window, open DevTools with “Disable cache” enabled, or run curl -IL in terminal so you bypass local storage entirely.

Can I fix this without editing wp-config.php?

Yes. If you go to Site Delivery > Origin Settings in StackPath and set the Origin Protocol to “HTTPS Only” on port 443, StackPath will talk to your server over native SSL. Because the origin receives the request directly over port 443, WordPress naturally populates $_SERVER['HTTPS'] = 'on' without needing helper code in wp-config.php. That said, keeping the proxy check in wp-config.php is good defensive insurance if origin settings ever revert to port 80.

What if I get a 502 Bad Gateway after changing Origin Protocol to HTTPS?

A 502 error immediately after switching origin protocol to HTTPS means StackPath tried connecting to your origin on port 443 and the TLS handshake failed. This happens if your origin server doesn’t have an active SSL cert installed, if your host’s firewall is blocking port 443, or if you forgot to turn on SNI in StackPath’s Origin settings. Make sure your origin has a valid cert before forcing HTTPS between the edge and your server.

Will Cloudflare Flexible SSL work alongside StackPath?

Don’t stack multiple CDNs with conflicting SSL termination modes. If Cloudflare handles DNS or proxying ahead of StackPath, running “Flexible SSL” on one and “Match Client” on the other creates conflicting proxy headers that almost always cause redirect loops. Point DNS straight to StackPath, or set up full end-to-end encryption across every proxy in your path.

Next Steps

Now that the redirect loop is gone and your edge cache is working properly, focus on reducing the request load hitting your origin. Read our walkthrough on how to configure Origin Shield in StackPath CDN to reduce origin server load so edge nodes consolidate cache misses and keep your origin server running fast.