先判断卡顿发生在哪一层

上面的分片缓存策略只适用于分片文件名不会被重复覆盖的情况。如果系统会用同一个文件名替换旧分片，就不能随意设置immutable，否则用户可能持续读取旧内容。点播列表可以采用更🔍长缓存，但直播列表通常需要及时重新请求。

上线前按播放场景验收

不要一看到播放卡顿就修改Nginx参数。先观察浏览器开发🔑者工具中的媒体请求、响应状态✅和下载速度，通常可以按照下面的现象定位问题。

对于文件名带版本号、发布后不会改变的点播视频，可以使用较长缓存，例如将视频文件替换为新文件名后再发布。若始终使用同一个文件名更新内容，缓存时间应缩短，或者在更新时主动清理缓存，避免用户拿到旧文件。

缓存和带宽决定多人播放上限

对于自建站点上的MP4视频，优先完成四件事：把📢MP4的索引信息放到文件前部，确保拖动时支持HTTP Range分段请求，⭐使用Nginx高效发送静态文件，并为可缓存的视频设置合理缓存策略。如果视频需要适应不同网络环境，还应使用HLS或DASH提供多档码率，而不是只依赖单个大MP4文件。

HLS或DASH只能解决“根据网络选择码率”的问题，不能修复源文件损坏、服务器带宽不足或播放器逻辑错误。Nginx在这里主要负责稳定地发送播放列表和分片，真正的🎯转码、切片和码率规划应在发布☀️流程中完成。

如果视频由上游服务提供，必须确认Nginx没有丢弃客户端的Range和If-Range请求，也没有把上游返回的206、Content-🔑Range和Content-Length错误改写。反向代理中的proxy_buffering不能一概而论：点播大文件可以利用缓冲减少上游连接压力，直播或需要尽快把数据推给播放器的场景则可能需要关闭或缩短缓冲。应根据首帧时间、磁盘临时文件和上游连接数进行测试，而不是直接套用“关闭缓冲就一定更快”的结论。

先处理视频文件，再调整Nginx

单个MP4只能按照固定码率传输🎨。用户当前网络速度低于视频码率时，Nginx即使传输效率很高，播放器仍然会缓冲。更适合多种网络环境的做法是将同一视频制作成多档清晰度，再通过HLS或DASH❤️让播放器根据带宽切换。