先判断卡顿究竟来自哪里

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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