With CDN caching enabled on a service, Railway's edge caches static media responses keyed by URL only. It does not vary on the request Range header, and it caches partial 206 responses.

The first request for a URL populates the cache; every later request for that URL is served that exact cached body, even when its Range differs.

iOS Safari loads <audio>/<video> by first sending a 2-byte range probe

(Range: bytes=0-1) and then requesting the rest of the file. When the probe response (206, 2 bytes) is what gets cached, the follow-up full-file request is served those same 2 bytes, so the media element can never buffer enough to decode and playback silently fails.

It is understandable you don't want the CDN to serve large video files, etc. The specific use case was small mp3 1-2s sound clips.

Env

• server: railway-hikari, x-railway-edge: sin1, CDN caching enabled on the service ().
• Django + WhiteNoise. The origin handles Range correctly and returns proper 206 responses on every cache MISS (application's own logs look completely healthy; the corruption only appears on an edge cache HIT)

Reproduced the "key on URL not range" behavior in both directions (probe, large range) and (large range, probe).

Please let me know if there is any configuration issue on my side that results in this behavior. If not (and if not already on the to-do list), please adjust cache to follow RFC 9111 3.3.

Thanks!