A significant share of HTTPS migration problems — redirect loops especially — trace back to a misunderstanding of how TLS termination and redirect logic interact once a CDN or reverse proxy sits between visitors and your actual origin server, rather than any single misconfigured setting.
The architecture that causes the confusion
The core fix: trust the forwarded-protocol header, not a raw check
Every reverse proxy and CDN sets a header (most commonly X-Forwarded-Proto) indicating the protocol the original visitor actually used, specifically so the origin server can make correct decisions despite TLS having already terminated upstream. Origin-level redirect logic — whether in .htaccess, an Nginx config, or application middleware — needs to check this header rather than a raw "is this connection HTTPS" check, which will always read as false behind a proxy that's terminating TLS.
CDN-specific settings worth knowing
Cloudflare's SSL/TLS mode setting is the most commonly encountered version of this issue: "Flexible" mode explicitly keeps the CDN-to-origin hop as plain HTTP, which is fine on its own, but breaks badly if the origin also tries to force HTTPS without checking the forwarded header. Switching to "Full" or "Full (Strict)" (encrypting the CDN-to-origin hop too, provided your origin has its own valid certificate) resolves this category of issue at the source, since the origin then genuinely does receive an HTTPS connection rather than needing to infer it from a header.
Should the origin encrypt end-to-end, or trust the proxy?
There's a real architectural choice here, not just a bug to fix: encrypting the CDN-to-origin hop too (Cloudflare's "Full" modes, or an equivalent setting on other CDNs/load balancers) provides genuine end-to-end encryption, closing the one internal gap where traffic between proxy and origin would otherwise be unencrypted. This matters more if that internal hop crosses the public internet (common with third-party CDNs) than if it stays within a tightly controlled private network — but it's the more thorough option either way, and increasingly the default recommendation as "good enough" security bars have risen.
Diagnosing which layer a redirect problem is actually happening at
Use curl -v against your domain and read the actual Location headers and status codes returned at each hop — this shows you exactly which layer (CDN edge, or origin) is issuing which redirect, rather than guessing based on browser behavior alone, which obscures the individual hops behind its own redirect-following logic.
A second common variant: caching a redirect at the CDN
A related but distinct issue occurs when a CDN caches a redirect response itself — if you fix an origin-level misconfiguration but the CDN continues serving a previously cached bad redirect for its normal cache duration, the fix can appear not to have worked even though the origin is now correctly configured. Purging the CDN's cache (or specifically the cached redirect responses) after any origin-level fix rules this out as a separate possibility.
Why testing directly against your origin server is a critical debugging step
Bypassing the CDN entirely and connecting directly to your origin server's IP address, using a hosts file override or a direct connect command, isolates whether a redirect issue originates at your origin or at the CDN layer — a step worth taking early in any CDN-related troubleshooting rather than assuming the problem is wherever seems most likely.
What CDN-specific caching settings can mask a real underlying redirect problem
A CDN caching a redirect response for longer than expected can make a genuinely fixed origin-level issue appear unresolved, since the CDN keeps serving the old, cached redirect — explicitly purging the CDN's cache after any origin-level configuration change rules this out as a confounding variable during troubleshooting.
What a CDN's own SSL certificate versus your origin's certificate actually means
The CDN presents its own certificate to visitors (often a shared certificate covering many customer domains, or one specifically issued for your domain depending on the CDN), entirely separate from whatever certificate your origin server presents to the CDN on the backend hop — two distinct certificates serving two distinct segments of the overall connection.
How to diagnose whether a specific issue is CDN-side or origin-side using response headers
Comparing response headers when connecting directly to your origin's IP versus through the CDN's normal routing often reveals telling differences, additional headers the CDN adds, different caching behavior, that help isolate whether an issue originates at the CDN layer or your origin server itself.
Why some CDNs offer a dedicated staging or preview mode useful during migration testing
Several major CDNs offer a staging or development mode that lets you test configuration changes against a preview URL before applying them to live production traffic — using this feature during an HTTPS-related configuration change reduces the risk of a live-traffic-affecting mistake during testing.
What Web Application Firewall rules specifically need review during this kind of migration
WAF rules configured with specific hostname or protocol assumptions, blocking requests that don't match an expected pattern, for example, may need review to ensure they correctly accommodate the post-migration https:// traffic pattern rather than inadvertently blocking legitimate requests that no longer match an outdated rule assumption.
How origin shielding features interact with the redirect and certificate configuration
Origin shielding, a CDN feature that funnels all origin requests through a single, consistent edge location rather than many, doesn't change the fundamental certificate or redirect configuration covered in this guide, but can affect caching behavior in ways worth retesting specifically if you enable it around the same time as a migration.
Why some CDNs handle the redirect and origin connection as entirely separate configuration areas
Some CDN platforms deliberately separate visitor-facing redirect and certificate settings from origin-connection settings into distinct configuration sections, reflecting that these genuinely are two independent concerns, visitor experience versus backend connectivity, that happen to both relate to HTTPS but are configured and can fail independently of each other.
What a CDN configuration export or backup provides before making significant changes
Exporting or documenting your current CDN configuration before making SSL mode or certificate-related changes gives you a clear reference to revert to if a change doesn't produce the expected result, rather than trying to reconstruct the prior working configuration from memory under time pressure.
A final word on why understanding this architecture pays off beyond just fixing redirect loops
Understanding exactly where TLS terminates and how forwarded headers work pays off well beyond troubleshooting one specific redirect loop — the same conceptual model applies to diagnosing session handling issues, understanding why an application sees a different client IP than expected, and generally reasoning correctly about any proxied infrastructure.
What to do once your CDN and origin configuration is confirmed correct
Once confirmed working, documenting your specific CDN SSL mode setting and why it was chosen prevents a future team member from changing it without understanding the redirect-loop risk that a seemingly reasonable change (like switching to Flexible mode for a perceived simplicity benefit) could reintroduce.
A quick closing checklist to confirm before considering the migration finished
Before considering this configuration complete, confirm: your CDN's SSL mode matches your origin's actual certificate status, testing directly against your origin's IP shows the expected behavior, and your application correctly reads the forwarded-protocol header rather than performing a direct HTTPS check.