Facebook serves audio-stripped video to some datacenter IPs, but not others

Updated 2026-09-16

A user told us a video downloaded silent. It played with sound on their phone. Our metrics said that download had succeeded — not "succeeded with warnings", but succeeded, at 2560p, on every host we had.

Measuring it

The extraction returned a 200, a full format list, and a video file at the highest resolution the platform offers. There was simply no audio in it.

The first useful thing was to stop reasoning and fetch the same reel from three different places at once: a Hetzner dedicated box in Helsinki, an ordinary shared-hosting account in Denmark, and a residential line.

The obvious reading is "datacenter bad, residential good", and it is wrong. The Danish host is an ordinary datacenter box. It gets audio. What the three rows actually show is that the specific address is degraded — its reputation, its ASN — not the category it belongs to. The next section rules out the fallback explanation too.

The mechanism turned out to be blunter than expected. The platform does not serve a worse audio stream to that address; it omits the audio representation from the manifest entirely. The format list that host receives contains no audio-bearing entry at all. Both sd and hd come back silent. There is nothing to select, so no format-selector change can recover it.

One precision worth stating, because it is easy to overclaim: this is decided per post, not per request, and not for every post. Re-extracting the same reel from the degraded address returns no audio every time — three of three, after the ordering was forced. But across 28 logged extractions of assorted posts from that address, 15 were offered audio. So some posts are stripped for that network and some are not, and the ones that are, are stripped consistently. The same per-item pattern already shows up on Instagram, where a dedicated check decodes a CDN parameter to spot a stripped rendition post by post.

The same shape on other platforms

A sweep across everything we support found this is not one platform's quirk, but it is also far from universal:

Some platforms do this. Most do not. The ones that do give you no error to catch.

One more measurement mattered, because it made the fix cheap: the URLs are not IP-bound. Fetching a Denmark-obtained URL from the degraded Helsinki box returns the full bytes, audio included — 2,344,345 against 2,154,715 for the locally-obtained one. Only the manifest request is degraded, so only extraction has to move and delivery can stay where it is.

IPv6 does nothing, in case you were wondering. Same host, working global v6, same post: byte-identical, silent over both.

It is not "cloud providers" either

The natural retreat from "datacenter bad" is "large cloud providers are flagged as a class". Published work on how Meta scores incoming traffic does describe hosting networks — AWS, Google, Azure, Hetzner, OVH, DigitalOcean — being judged by range rather than by behaviour, so the hypothesis is reasonable. It is also wrong here, and the measurement was cheap enough that there was no excuse for guessing.

GitHub Actions runners egress from Microsoft address space. That is a free vantage point on about as large a cloud as exists. Same reel, same hour, four networks:

Azure is served full audio. So whatever drives this, it does not treat "large cloud" as one category — and the literature that says otherwise is describing login and API access, which is a different mechanism wearing similar clothes.

Geography does not rescue it either. The working vantage points answered from Chicago, Copenhagen and Copenhagen; the failing one answered from Helsinki, and the Danish host is a great deal closer to Helsinki than Chicago is.

Of four networks measured, exactly one is degraded. That is the whole finding, and it is worth being precise about how little it generalises: one platform, one URL, one day, and a single address per provider. DigitalOcean is grouped with Hetzner by the same sources that group Azure with Hetzner, and Azure is fine — so DigitalOcean is untested, not exonerated and not convicted. Assume nothing about a network you have not measured.

Fix one: teach the router about audio

We already ranked hosts per platform — health, and a separate ceiling signal watching maximum offered height, built for exactly this class of silent degradation after a platform started capping us at 480p.

The height ceiling had not caught this, because it watches the video dimension and audio is not a dimension. So we added the counterpart: record whether each extraction was offered any audio-bearing format, and demote hosts consistently offered none.

It worked. Traffic moved to the Danish host, visitors got their audio back, and we moved on. Four days later, another silent reel.

Why it failed

The demotion was a threshold with no hysteresis, and the ranking had eaten itself.

Demoting the Helsinki box starved it of work on that platform. With no new samples, its stripped measurements aged out of the 168-hour window one by one, until a single surviving audio-bearing sample carried its ratio to 1/6 — 0.167, just above the 0.15 demotion threshold. The demotion switched itself off. The stripped host went back to the front of the queue.

Then a second signal made it worse. A quality probe, tracking a different starved statistic, promoted the residential host to the front. That machine was asleep. It failed in 138 milliseconds, the next host in line was the stripped one, and it succeeded. The Danish host — the one that would have worked — was never consulted.

Logged as a success. Full 2560p. Every signal read the fetch as perfect.

The general form is worth stating plainly: a statistical ranking learns from the very requests it exists to protect, so it is always at least one broken request behind. Ranking is the right tool for a preference. It is the wrong tool for a correctness property. We had used it for a correctness property.

Fix two: stop ranking, start checking

So we replaced the mechanism instead of tuning the threshold. On the way out of every job: if the winning host's answer contains no audio-bearing format at all, and some peer is measurably offered audio for this platform, re-extract there and serve that instead.

Deterministic. Per request. No accumulation, no threshold to drift across.

It has a nice side effect on the oscillation too: each recovery writes a negative for the stripped host and a positive for the peer in the same request, so the demotion stays latched instead of drifting back.

That shipped, we verified it live, and downloads had audio again. Five days later, every one of them was silent, and had been for days.

The part worth the write-up

The recovery was intact. It was platform-agnostic, it had two peers available, and its logic was correct. It had simply gone inert.

To decide whether a peer was worth asking, it checked whether that peer had recently been offered audio for this platform. That check read its evidence through the ranking's 168-hour window — the same window, inherited without thinking about it, because the two mechanisms lived next to each other.

The peer evidence was real and unambiguous: Denmark 9 measurements out of 9, residential 5 out of 5, both a perfect ratio. All of it logged across a five-day stretch. Five days after that, every sample was older than 168 hours. No peer cleared the healthy threshold. The recovery looked for somewhere to recover to, found nowhere, and quietly did nothing.

And it could not heal on its own. That platform is served local-first. Local reports success — it always does, that is the entire problem — so no peer is ever consulted, so no fresh peer evidence is ever recorded.

The signal that decided whether to consult a peer could only be refreshed by consulting a peer. A self-referential starvation. Not a bug in any line of code; a bug in which clock a piece of evidence was read against.

The fix is one constant. The audio signal gets its own window, 720 hours, separate from the ranking's 168. The justification is that the two measure different kinds of fact. Host reputation drifts, so a week-old reading is genuinely stale. Whether a platform strips audio for a given address is structural — a property of how that platform treats that network — and it does not change because a week passed.

The asymmetry of being wrong settles it. A stale positive costs one wasted extraction, which the recovery validates and discards, correcting the evidence on its way past. A stale negative silently disables a correctness mechanism for an unbounded stretch of time, which is precisely what happened.

What to take from it

Success metrics do not see silent degradation. Ours reported 200, full resolution, complete format list, on a file with no audio. If a degraded response is well-formed, every health check you own will pass.

Measure from more than one place before forming a theory. One host cannot tell you the difference between "this platform is like that" and "this platform is like that to you". The second is more common than it looks, and the theory you form from a single vantage point will be confidently wrong — ours was "datacenter versus residential", and the retreat position, "large clouds are flagged as a class", died to a free GitHub Actions run that took two minutes to set up.

Do not close a correctness hole with a statistical signal. Rankings are for preferences. Correctness needs a check that runs on the request it protects.

Check which clock your evidence is read against. Both real outages here came from a time window rather than from logic: one from evidence expiring under a threshold with no hysteresis, one from a correctness mechanism inheriting a window meant for a fast-drifting signal. Neither was visible in the code that used it.

The probe we used for the three-host comparison is MIT-licensed and on GitHub as asn-media-probe (github.com/Kjartansson/asn-media-probe). Point it at a URL and a couple of hosts and it will tell you whether they are being served the same thing. The measured sweeps are in results/.

More guides