先判断卡顿发生在哪一层

对于自建站点上的MP4视频，优先完成四件事：把MP4的索引信息放到文件前部，确保拖动时支持HTTP Range分段请求，使用Nginx高效发送静态文件，并为可缓存的视频设置合理缓存策略。如果视频需要适应不同网络环境，还应使用HLS或DASH提供多档码率，而不是只依赖单个大MP4文件。

对于文件名带版本号、发布后不会改变的点播视频，可以使用较长缓存，例如将视频文件替换为新文件名后再发布。若始终使用同一个文件名更新内容，缓存时间应缩短，或者在更新时主动清理缓存，避免用户拿到旧文件。

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

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

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

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

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

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