我被这一下整不会了，蘑菇视频ios的清晰度选择问题我终于定位到原因了

蘑菇视频1282026-01-24 00:28:42

前几天用蘑菇视频看短片，界面上可以选择“高清 / 流畅 / 原画”等清晰度，但无论怎么切换，画面没任何变化，低码率的马赛克一直在那——折腾了好久，终于把问题定位清楚了，顺便把排查和解决过程写下来，遇到类似情况可以参考。

一、现象（如何复现）

iOS 客户端：点击播放页的清晰度按钮，选择不同档位后 UI 会变，但视频画质没有变化，且切换时没有明显的缓冲或分段切换痕迹。
网络层面：网络请求并没有请求到新的视频片段（segment），而是反复命中同一组低码率文件。
桌面/浏览器复现：用浏览器直接打开 HLS 的 master playlist（m3u8），不同 variant 的 URL 实际返回的内容和分片一致。

二、我怎么一步步定位的

抓包查看 master playlist

用 Charles / mitmproxy 抓到播放时的 m3u8，发现 master.m3u8 中列出的多个 variant URL 看起来正常，且标签里有 BANDWIDTH/RESOLUTION。

直接请求各个 variant 的 m3u8

把各个 variant 的 URL 在浏览器或 curl 中打开，发现虽然 URL 不同，但 m3u8 内容完全相同，里面都是低码率的分片 URL。

比对分片请求

分片（ts/fmp4）请求的响应头里 Content-Length 很小，且来自同一个 CDN 节点，说明 CDN 把不同的 variant 指向了同一份缓存。

用 ffprobe / VLC 检查

下载若干分片做检查，所有分片的分辨率和码率都一致，确认确实是同一质量文件被反复返回。

验证 CDN 配置

向运维确认 CDN 的缓存键（cache key）配置，发现 CDN 在转发时忽略了文件路径后面的某些参数或把不同 URL 规则化了，导致多个 variant 的请求被命中到同一个缓存对象。

三、最终原因（总结）看起来是服务端/CDN 层面的配置问题：master playlist 指向了若干不同的 URL，但 CDN 的缓存规则把这些 URL 识别成了同一份资源（或 origin 上的重写/重定向导致所有 variant 指向同一个低码率源）。客户端发起切换时确实会请求不同的 URL，但 CDNs 把返回的内容“统一化”成了低码率分片，所以播放质量没有变化。

四、如何确认你的环境是不是同样的原因（快速自检）

在浏览器打开 master.m3u8，逐个打开 variant 的 m3u8，确认里面列出的分片是否有所不同。
对比不同 variant 的第一个分片，直接下载并用 ffprobe/vlc 检查分辨率和码率。
抓包看分片请求的响应头，关注 Cache-Control、Via、X-Cache 等 CDN 相关头部，确认是否都来自同一缓存节点或被重写。
如果你无法抓包，试试把不同 variant 的 URL 在不同网络（移动数据 vs Wi‑Fi）中打开，看返回是否一致。

五、解决方案（运维/开发角度）

调整 CDN 的 cache key，使得 variant URL 能根据路径或 query 区分缓存对象。把 m3u8 和分片的完整路径作为 cache key 的一部分，不要把不同分辨率的请求合并。
避免 origin 端对 variant URL 做不当重写或重定向。检查后端部署脚本、路由规则，确认每个分辨率对应独立资源。
在 master playlist 中使用绝对并唯一的 URL（不要依赖会被 CDN rewrite 的短链接或同构路径）。
配置正确的 Content-Type、Content-Length 和合适的 Cache-Control，便于 CDN 正确缓存和验证。
上线前在测试环境用抓包/ffprobe 验证每个 variant 返回的分片确实属于不同码率/分辨率。
如果用 HLS Live，确保 variant 的分片集合真实对齐且不会被边缘缓存策略错误合并。

六、能替代的临时处理（用户端能做的）