不要对视频内容启用 gzip 压缩

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

固定不变的点播视频适合使用带版本号的文件名，例如更换视频后改变文件路径，而不是覆盖同一个地址。这样可以放心设置较长缓存，也能避免用户因为旧缓存继续播放过期文件。带权限的视频则要谨慎设置公共缓存，避免不同用户之间发生内容越权。

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

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

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

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

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

如果 Nginx 前面连接 CDN，或者 Nginx 后面还有应用服务、对象存储，视频请求的瓶颈可能出现在回源链路。应确认上游是否支持 Range，是否正确返回 C🍀ontent-Length、Content-Type 和 Content-Range，以及 🌈CDN 是否缓存了分片。

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

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

Nginx 不会自动降低视频▶️码率，也不会把一个 4K 文件变成适合移动网络播放的版本。🎯想让不同网络条件下都保持流畅，通常需要准备多档清晰度和码率，并让播放器根据实时带宽进行自适应切换。

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

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

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

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

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