curl -I -H "Range: bytes=0-1023" https://cdn.a.com/v.mp4 # 期望 HTTP/1.1 206 Partial Content # content-range: bytes 0-1023/104857600
视频请求带了 Range: bytes=1048576-，响应状态码却是 200，Content-Length 是完整文件大小。播放器进度条拖过去就卡住，重新从头加载。这类现象通常不是突然出现的，往前翻半天日志能看到苗头。
追下去是这么回事：服务端支持 Range 才会返回 206 并带 Content-Range，返回 200 说明请求被当成普通 GET 处理。中间层开了压缩或做了整文件缓冲，Range 头会被忽略。代理有时候还会直接把 Range 头丢掉。
这次卡住的地方就在「Range 206」这一环，单独把它拎出来验证，别和其他改动混在同一次发布里。同一份配置存在多处的，先确认改的是被加载的那一份。
新版本先放一台机器上跑一天再全量，问题一般在这段时间暴露。备份不是备了就行，恢复一次才算数，很多备份文件打开才发现是空的。
处理上按这个顺序：确认对象存储和前置代理都透传 Range 头；对媒体文件关掉 gzip 压缩；返回 206 时带正确的 Content-Range 和 Accept-Ranges；用 curl 直接打源站 排除 CDN 影响。
确认没问题再收工，响应变成 206 且 Content-Range 的总长度正确，播放器可以随意拖动。