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

sendfile可以减少文件从磁盘发送到网络时的额外📢数据复制，通常适合大文件传输。tcp_nopush有助于配合sendfile发送较大的数据块，tcp_nodelay则可以减少部分小数据包的等待。它们不能增加服务器本身的出口带宽，实际效果仍要通过真实播放和并发测试确认。

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

上线前按播放场景验收

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

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

因此，Nginx1😎00%视频优化的正确落地顺序是：先修复视频🚀封装和码率，再确认Range分段传输，然后优化静态文件发送与缓存，最后根据并发量引入自适应码率和边缘分发。只有先找到实际瓶颈，Nginx配置调整才会真正改善播放流畅度。

先判断卡顿发生在哪一层

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

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

静态MP4的Nginx基础配置

如果视频文件直接存放在服务器上，最好让Nginx直接读取，而不是每次经过PHP、Java或其他业务程序转发。下面是一份偏保守的静态视频配置示例，适合公开访问且文件内容不会频繁变化的MP4、M4V和WebM文件。

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

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