As the web grows more complex and performance expectations rise, using multiple Content Delivery Networks (CDNs) has become a common strategy for increasing availability, improving load times, and guarding against outages. However, when not implemented carefully, multi-CDN setups can introduce new problems—ones that unexpectedly impact user experience and compromise security. One such incident involved a failover scenario in a multi-CDN configuration that began routing users to a HTTP origin despite the primary site being HTTPS-only. This led to widespread mixed-content errors and client-side asset failures.
TL;DR
When a healthcheck-triggered failover in a multi-CDN configuration switched traffic to a secondary CDN, it routed users to a non-HTTPS (HTTP-only) origin. This caused browsers to reject insecure content, triggering mixed-content warnings and breaking critical site functionality. Surprisingly, the failover healthcheck criteria only validated TLS from the CDN to the origin, not end-user HTTPS access. Addressing the issue required a review of origin health monitoring, stricter TLS enforcement, and content validation rules.
The Rise of Multi-CDN Architectures
Deploying a multi-CDN architecture has become a best practice in today’s global internet landscape. Organizations use two or more CDNs to improve:
- Availability: Failover mechanisms kick in if one CDN provider experiences an outage.
- Performance: Traffic is routed to the CDN with the lowest latency based on geographic proximity and current load.
- Resilience: Protection against DDoS attacks or region-specific failures.
This kind of approach works well in theory, but its complexity leaves room for misconfiguration. If one of your CDNs is misaligned—especially in how it communicates with the origin or serves secure content—you may unknowingly expose your users to errors and even security risks.
The Incident: When Failover Meets HTTP
During a routine failover initiated due to high latency detected on CDN1, a global e-commerce platform began routing traffic through CDN2. However, without thorough testing of how CDN2 fetched resources from the origin, something crucial was overlooked: CDN2 was serving assets via a non-HTTPS origin.
This wouldn’t have been a problem for standalone HTTP sites, but in this case, the platform’s primary domain enforced HTTPS across all pages using a strict Content Security Policy (CSP). As soon as CDN2’s HTTP-based resources were served in an HTTPS environment, browsers began throwing mixed-content errors and blocking essential content such as JavaScript files, CSS stylesheets, and fonts.
The result? Users couldn’t interact with the platform: buttons didn’t respond, drop-downs didn’t function, and payment pages failed to load.
Understanding Mixed-Content Errors
Mixed content occurs when a secure website (loaded over HTTPS) loads any asset (like scripts, images, or videos) over an insecure HTTP connection. Most modern browsers cancel such requests to protect users, leading to breakdowns in how pages are displayed or function.
There are two types of mixed-content:
- Active mixed content: Includes scripts, iframes or other code that can interact with the document. These are blocked completely.
- Passive mixed content: Includes media elements like images or videos. Browsers might load these but often flag warnings.
In this case, it was heavy with active mixed content: everything from React bundles to authentication scripts failed to load, effectively turning a robust e-commerce platform into a static HTML tombstone.
The Healthcheck That Missed the Mark
Most CDNs employ healthchecks to determine if an origin is healthy and can serve traffic. These healthchecks typically include HTTP requests at regular intervals to check if an expected response is received. But in this scenario, an important nuance was missed: the failover was triggered by latency metrics from CDN1, and once routed to CDN2, CDN2’s healthchecks confirmed the origin was “healthy.” But how?
As it turns out, the healthcheck validated the origin by accessing a TLS-terminated endpoint—but only between the CDN and origin server. It didn’t validate how the origin responded to user-facing URLs or whether HTTPS was properly configured for content accessible to real end-users.
Key misconfiguration issues included:
- No verification if the origin served identical HTTPS content as the primary CDN.
- The healthcheck did not check for content mismatches or HTTP response headers like
Strict-Transport-SecurityorContent-Security-Policy. - No TLS validation on the host headers used by the fallback CDN.
This oversight led to a situation where the origin passed the healthcheck but delivered HTTP content incompatible with the site’s security requirements.
Detecting and Diagnosing the Problem
The issue didn’t manifest immediately. Initially, CDN2 showed green lights—origin connections succeeded, responses were timely, and there were no internal CDN alarms. However, within minutes, error reports began to surge:
- JavaScript CDNs were failing to load core logic.
- Fonts and stylesheets were blocked due to insecure sourcing.
- Customer support tickets flooded in, complaining that the checkout page was “broken.”
Teams quickly examined browser Developer Tools and noticed a flood of Mixed content: The page was loaded over HTTPS, but requested an insecure script errors. The logs, rich in 403 and 404 responses for asset files, pointed to HTTP origins being force-fed into HTTPS pages.
Mitigation and the Fixes Applied
Resolving the issue involved multiple tactical and strategic fixes.
Tactical Fixes:
- Manually disabled CDN2 routing and reverted traffic to CDN1 once latency returned to normal.
- Updated the DNS failover weights temporarily to prevent automatic failbacks.
- Pushed hotfix patches to alter base URLs for critical JavaScript to enforce HTTPS paths.
Strategic Changes:
- Introduced TLS validation in all healthcheck layers — including from CDN to origin and end-to-end verification using emulated browser requests via headless Chrome setups.
- Enforced SSL redirection at the origin server level so that any HTTP connections are forcefully upgraded to HTTPS.
- Expanded Content Security Policy to restrict asset loading to HTTPS-only domains.
- Tested all CDN-provider origin paths to ensure consistency in configuration and behaviour, regardless of entry point.
What Can We Learn From This?
This type of failover fiasco highlights the dangerous assumptions often made in distributed environments:
- That healthchecks confirm user-experience quality—they don’t.
- That origins serve the same exact configuration to all entry points—they might not.
- That HTTP can be silently upgraded without side effects—not when CSPs and modern browsers enforce strict rules.
Takeaway: Any component in a failover chain should be treated as live production and be tested accordingly—including security configurations, protocols, and content delivery behavior. CDN redundancy is valuable—but only when all parts conform to the same expectations.
Final Thoughts
Failover systems are meant to improve stability, not compromise it. In this story, a seemingly intelligent, automated system created chaos because origin validation didn’t take HTTPS and user security into account. By refining healthcheck criteria and enforcing stricter protocols, companies can avoid this pitfall and deliver the reliable, secure experience users expect.
The battle for high availability doesn’t end by adding more nodes; it ends by ensuring every node, path, and byte respects the security standards of your application—especially when adversarial conditions strike.
- Multi-CDN failover sent users to a non-HTTPS origin causing mixed-content errors and the failover healthcheck that enforced TLS - November 22, 2025
- How to Connect Meta Quest to GeForce Now (2025 Guide) - November 22, 2025
- How to Turn Off NVIDIA GeForce Experience - November 22, 2025