先判断卡顿究竟来自哪里

mp4 指令依赖 Nginx 的 MP4 模块，并不是所有编译版本都默认包含。它适合需要 MP4 伪流式播放或按起始时间请求💯的场景，但不能替代 Range 支持。若服务器提示未知⭐指令，应先确认模块是否安装，不要直接把这条指令复制到生产环境。

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

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

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

m3u8 播放列表是文本文件，体积较小时收益有限，但可以根据实际响应大小📢决定是否压缩。配置时要把文本播放列表和视频分片分开处理，避免一个通用规则同时作用于所有媒体文件。

并发参数不能越大越好。worker_processes 可以根据 CPU 核数自动设置，worker_connections 则要结合文件描述符上限、代理连接数和实际带宽计算。一个 Nginx 工作进程的连接数并不等于可以承载的有效视频用户数，因为反向代理场景中，一名用户可能同时占用客户端连接和上游连接。

反向代理和 CDN 场景要重点检查回源

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

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

只有当文件格式、Rang📌e 请求、缓存策略、带宽容量和自🔮适应码率同时匹配业务场景时，Nginx 视频播放才能获得稳定的流畅表现。

MP4 直出时，先保证拖动和分段请求正常

HTML5 播放器拖动进度时，通常会向服务器发送带有 Range 请求头的字节范围请求。正常情况下，服务器应返回 206 Pa⭐rtial Content，并带有 Content-Range。如果始终返回完整文件，用户拖动进度就可能等待很长时间，甚至表现为无法快进。

如果视频跨域播放，还要检查响应中的 CORS 配置。允许来源应尽量限定为实际业务域名；使用登录态或 Cookie 时，不宜简单使用任意来源的通配配置。

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

连接数和文件传输参数要结合服务器上限

HLS 通常由一个或多个 m3u8 播放列表，以及大量 ts 或 m4s 分片组成。🎯这两类文件的更新频率不同，不能使用完全✅相同的缓存时间。

HLS 视频要分开设置播放列表和分片缓存

视频问题不一定是 Nginx 配置错误。可以先观😎察浏览器开发者工具中的请求状态、服务器带宽和磁盘读写情况，再确定优化方向。

静态视频传输可以使用 sendfile on，让文件数据更高效地从文件系统交给网络层，减少不必要的用户态拷贝。tcp_nopush on 通常与 sendfile 一起使用，有助于减少发送大量小数据包的情况。

对于大量异地用户，Nginx 源站只负责稳定回源，CDN 负责就近分发，通常比单台服务器直接承载所有🚀视频流量更合理。若视频文件很大、访问地域分散，优先评估带宽和 CDN 命中率，而不是先调整连接超时时间。