The site sat behind a CDN, with the origin server handling the actual application logic. Adding HTTPS enforcement at the origin — a simple rule redirecting any HTTP request to HTTPS — seemed like the obvious, correct move, and had worked identically on two previous projects using the same hosting setup.
The immediately obvious problem
Within minutes of deploying the redirect rule, the site became completely unreachable — browsers reporting "too many redirects." The cause was the well-known, classic version of this problem: the CDN was configured in a mode where it terminated HTTPS at its own edge and talked to the origin over plain HTTP, meaning every request the origin actually saw looked like an HTTP request, regardless of what protocol the original visitor used. The origin's new redirect rule saw that "HTTP" request, dutifully redirected to HTTPS, the CDN received that redirect and made a fresh request to the origin — still over its own HTTP-to-origin connection — and the loop repeated indefinitely.
This part matched a pattern the developer had actually read about before starting the migration, and the fix seemed obvious: switch the CDN's connection mode to one that preserved HTTPS all the way to the origin, rather than terminating and re-originating over plain HTTP.
The part that wasn't in the article they'd read
Making that change fixed the loop — mostly. A small percentage of requests, seemingly random, still occasionally hit a redirect loop, intermittently, in a way that made it hard to even confirm the first fix had fully worked. This took considerably longer to track down than the original, textbook loop had.
The actual cause turned out to be a secondary caching layer within the CDN's own edge network, caching a small number of the old-mode HTTP-origin responses from before the configuration change, and serving those stale cached redirects to a subset of visitors even after the underlying configuration was corrected. The fix wasn't a configuration change at all this time — it was a manual cache purge across the CDN's edge network, clearing out the specific cached redirect responses left over from before the mode switch.
Why the second problem was harder than the first
The first redirect loop was a known, well-documented pattern with an obvious fix once correctly diagnosed. The second one was harder specifically because it looked like a partial, incomplete version of the first problem — leading to a good deal of wasted time re-checking the same CDN mode setting repeatedly, assuming the first fix simply hadn't taken effect, before considering that a completely separate caching layer might be holding onto stale state from before the fix. Our redirect loop guide covers the primary CDN-mode cause in detail; the caching wrinkle here is a good reminder that a fix which resolves "most" but not "all" of a symptom is worth treating as a different, second problem, not an incomplete version of the first.
This case study is written to illustrate a genuine, common troubleshooting pattern. It is not a direct quotation or a verified account tied to a specific, identifiable individual or company. For the underlying technical reference, see: Fixing Redirect Loops After HTTPS Migration
Loading comments…