Cdn on Everyone Has a Story

It only fails in Safari: two HLS engines, and how to debug across hops

BhaveshSGupta@disroot.org (Bhavesh S. Gupta) — Tue, 06 Oct 2026 09:03:00 +0530

When a live stream breaks in Safari and plays in Chrome, the tempting conclusion is that Safari’s player is the problem. Often it isn’t. Both browsers receive the same files from the same CDN. They differ in what they do when one of those files is wrong, so a delivery fault that Chrome quietly recovers from becomes a Safari bug report.

In short: Chrome, Edge and Firefox usually play HLS through hls.js, which retries failed requests and skips small gaps; Safari uses its native player, which surfaces the same faults as errors or stalls. Both get identical bytes, so a problem that only shows in Safari is usually a delivery problem. Find it by measuring each hop separately: compare responses at the origin and the CDN, probe from many regions, group logs by browser, and inspect the segments.

Putting a live HLS origin behind a CDN

BhaveshSGupta@disroot.org (Bhavesh S. Gupta) — Tue, 06 Oct 2026 09:01:00 +0530

A CDN in front of a live HLS origin should mean each segment leaves your server a handful of times, however many people watch. Whether it does depends on details that are easy to get wrong and hard to see: the URLs your origin hands out, the headers on each kind of file, and every layer between the origin and the viewer that has its own opinion about caching.

In short: A CDN only protects a live origin if every viewer requests the same URLs: no per-viewer session ids, and no query strings in the cache key. Give media playlists about a one-second lifetime, segments about a minute, and errors no-store so an early 404 isn’t served to everyone. Check headers at every hop, send CORS headers when the player is on another domain, and confirm request collapsing and an origin shield with the CDN that pulls from you.