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

Nginx对静态文件通常原生支持字节范围请求，不要在视频目录中配置禁用Range的规则。检查时不要要求首次请求一定返回206，因为播放器首次获取完整文件信息时可能返回200；更重要的是，拖动进度条或从中间开始播放后，响应是否出现206 Partial Content、Content-Range是否正确，以及服务器是否只传输请求的片段。

很多所谓的“Nginx视频优化”其实首先应该在视频文件本身完成。MP4中的moov原子👍保存时长、轨道和索引信息。如果它位于文件末尾，播放器可能要等待较长时间才能获得完整信息，尤其是在移动网络或需要拖动播放时更明显。

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

静态MP4的Nginx基础配置

如果“100%”是指让视频首帧、拖动、连续播放和多人并发都达到最优，Nginx并不存在一个打开后就能完全解决问题的开关。它主要负责文件传输，实际体验还取决于视频编码、文件结构、服务器磁盘、出口带宽、播放器和用户网络。

多人同时播放时，瓶颈通常是出口带宽，而不是某一条Nginx指令。粗略判断时，应将同时播放人数乘以单路视频码率，再为协议开销、峰值流量和其他业务预留空间。服务器本地磁盘读取速度不足时，SSD、操作系统文件缓存和边缘缓存都可能带来帮助；用户分布较广或并发明显时，CDN🌈通常比继续堆高worker_connections更有效。

HLS、反向代理与缓存要分开设置

Nginx📚编译并加载了MP4模块时，可以使用mp4指令处理部分MP4伪流式场景，例如根据start参数读取指定位置。但这个模块不是转码器，也不能替代faststart和Range请求；如果只是普通HTML5视频播放，先把索引前置并验证分段请求，通常比盲目启用模块更稳妥。使用前应通过Nginx编译信息确认模块是否存在，否则加入该指令会导致配置检查失败。

单个MP4不够稳定时，改用自适应播放

直播HLS的m3u8播放列表会持续变化，不能使用与固定视✨频分片相✅同的长缓存策略。一个常见的静态分发思路如下：