先判断卡顿究竟来自哪里

上面的数值只是配置思路，不是所有服务器都应照搬。假设每个用户持续消耗 5 Mbps，100 个用户理论上就需要约 500 Mbps 的视频流量，还要预留协议开销、网页请求和其他业务的带宽。带宽不足时，继续增加 worker_co🌅nnections 🌈并不能解决卡顿。

如果原视频本身码率远高于用户网络可承受范围，Nginx 只能把问题更快地传给用户，不能从根本上消除缓冲。因此，“100%优化”更适合作为排查目标：让请求、文件、缓存、带宽和编码每一层都没有明显瓶颈，而不是依赖某一个神奇开关。

Nginx解决不了的部分，要从编码和播放器入手

视频文件本身也需要处理。MP4 的 moov 元数据如果位于文件末尾，播放器往往要读取较多内容后才能开始播放。上传前可以通过编码工具启用 faststart，把必要元数据移动到文件前部。这个处理通常比单独调整 Nginx 参数更能改善首次打开速度。

上线后用四项指标验证效果

对于普通 MP4⭐ 视频，应重点配置字节范围请求、sendfile、合理缓存和 MP4 元数据位置；对于 H💪LS 视频，则要分别优化播放列表与分片缓存，并配合多码率自适应播放。先确定视频类型，再选择对应方案，比盲目堆叠 Nginx 参数更有效。

Nginx 静态文件默认支持范围请求，但如果前面还有 CDN、对象存储或反向代理，需要逐层检查是否错误✅删除了 Range 请求头。普通 MP4 文件可以使用下面的基础配置作为起点：

MP4、WebM、TS 和 M4S 已经属于压缩后的媒体格式，继续使用 gzip 往往会增加 CPU 消耗，却很难明显减少传输体积。因此，视频二进制文件一般应关闭 gzip。