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

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

先判断卡顿发生在哪一层

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

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

这条处理通常不会▶️重新编码画面，速度较快，但前提是原视频编码和🎊封装结构能够被目标播放器接受。如果播放器兼容性仍然不好，应重新编码为更通用的H.264视频和AAC音频，并根据目标设备制作适当分辨率与码率。

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

跨域播放时还要检查响应头。若播放器和视频不在同一来源，需要允许播放器所在的可信来源访问媒体资源；使用Cookie或授权信息时，不应简单地对所有来源开放通配跨域。公开免费视频与带权限的视频，缓存规则也必须分开，私有视频不能使用面向所有用户的public缓存。

上线前按播放场景验收

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

静态MP4的Nginx基础配置

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

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

视频文件已经经过编码压缩，通常不应再对MP4或WebM启用gzip。对视频做gzip往往只会增加CPU消耗，却很难获得明显的体积收益。对于特别大的文件，可以在确认操作系统和Nginx版本支持后测试异步I/O或线程池，但不要把aio、directio等参数直接复制到所有服务器上；磁盘类型、文件大小和内核配置不同，结果可能相反。

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

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

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

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

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