若是“100%视频优化”是指视频一定不卡顿、加载速率始终最快，单靠 Nginx 无法作出这样的包管。Nginx 主要认真视频文件的传?输效率、断点请求、缓存和并发毗连治理；视频编码质量、效劳器带宽、磁盘性能、播放器战略以及用户网络，同样会影响播放体验。

关于通俗 MP4 视频，应重点设置字节规模请求、sendfile、合理缓存和 MP4 元数据位置；关于 HLS 视频，则要划分优化播放列表与分片缓存，并配合多码率自顺应播放。先确定视频类型，再选择对应计划，比盲目堆叠 Nginx 参数更有用。

先判断卡顿事实来自那里

视频问题不?一定是 Nginx 设置过失？梢韵仁硬熹榔骺⒄吖ぞ咧械?请求状态、效劳器带宽和磁盘读写情形，再确定优化偏向。

视频播放异常与优先排查偏向

征象	优先检查	处置惩罚偏向
无法拖动进度或拖动后重新最先	是否返回 206、是否保存 Content-Range	检查 Range 请求、反向署理和视频封装名堂
视频首次翻开很慢	MP4 的 moov 元数据位置、磁盘读取和首字节响应时间	启用 faststart、sendfile 缓和存
岑岭期多人同时卡顿	出口带宽、并发毗连数、回源流量	使用 CDN、分级码率和边沿缓存
HLS 播放中途频仍缓冲	m3u8 更新、ts 或 m4s 分片是否能实时获取	区分播放列表和分片的缓存战略

MP4 直出时，先包管拖动和分段请求正常

HTML5 播放器拖动进度时，通；嵯蛐Ю推鞣⑺痛 Range 请求头的字节规模请求。正常?情形下，效劳器应返回 206 Partial Content，并带有 Content-Range。若是始终返回完整文件，用户拖动进度就可能期待很长时间，甚至体现为无法快进。

Nginx 静态文件默认支持规模请求，但若是前面尚有 CDN、工具存储或反向署理，需要逐层检查是否过失删除了 Range 请求头。通俗 MP4 文件可以使用下面的基础设置作为起点：

mp4 指令依赖 Nginx 的 MP4 ？，并不是所有编译版本都默认包括。它适合需要 MP4 伪流式播放或按起始时间请求的场景，但不可替换 Range 支持。若效劳器提醒未知指令，应先确认？槭欠褡爸，不要直接把?这条指令复制到生产情形。

视频文件自己也需要处置惩罚。MP4 的 moov 元数据若是位于文件末尾，播放器往往要读取较多内容后才华最先播放。上传前可以通过编码工具启用 faststart，把?须要元数据移动到文件前部。这个处置惩罚通常比单独调解 Nginx 参数更能改善首次翻开速率。

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

MP4、WebM、TS 和 M4S 已经属于压缩后的媒体名堂，继续使用 gzip 往往会增添 CPU 消耗，却很难显着镌汰传输体积。因此，视频二进制文件一样平常应关闭 gzip。

m3u8 播放列表是文本文件，体积较小时收益有限，但?可以凭证现实响应大?小决议是否压缩。设置时要把文本?播放列表和视频分片脱离处置惩罚，阻止一个通用规则同时作用于所有媒体文件。

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

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

• 直播 m3u8：需要频仍更新，缓存时间应短，须要时使用 no-cache，阻止播放器拿到逾期的分片列表。
• 点播 m3u8：内容宣布后基本稳固，可以设置适度缓存?，但重新宣布同名文件时要思量缓存刷新。
• 点播 ts 或 m4s：若是文件名带版本号且不会被笼罩，可以设置较长缓存时间，镌汰重复回源。
• 直播分片：缓存时间不可凌驾直播窗口的现实需求，不然可能把已经失效的分片继续提供应播放器。

若是视频跨域播放，还要检查响应中的 CORS 设置。允许泉源应只管限制为现实营业域名；使用登录态或 Cookie 时，不宜简朴使用恣意泉源的通配设置。

毗连数和文件传输参数要连系效劳器上限

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

并发参数不可越大越好。worker_processes 可以凭证 CPU 核数自动设置，worker_connections 则要连系文件形貌符上限、署理毗连数和现实带宽盘算。一个 Nginx 事情历程的毗连数并不即是可以承载的有用视频用户数，由于反向署理场景中，一名用户可能同时占用客户端毗连和上游毗连。

上面的数值只是设置思绪，不是所有效劳器都应照搬。假设每个用户一连消耗 5 Mbps，100 个用户理论上就需要约 500 Mbps 的视频流量，还要预留协议开销、网页请求和其他营业的带宽。带宽缺乏时，继续增添 worker_connections 并不可解决卡顿。

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

若是 Nginx 前面毗连 CDN，或者 Nginx 后面尚有应用效劳、工具存储，视频请求的瓶颈可能泛起在回源链路。应确认上游是否支持? Range，是否准确返回 Content-Length、Content-Type 和 Content-Range，以及 CDN 是否缓存了分片。

牢靠稳固的点播视频适合使用带?版本号的文件名，例如替换视频后改变文件路径，而不是笼罩统一个地点。这样可以定心设置较长缓存，也能阻止用户由于旧缓存继续播放逾期文件。带权限的视频则要审慎设置公共缓存，阻止差别用户之间爆发内容越权。

关于大宗异地用户，Nginx 源站只认真稳固回源，CDN 认真就近分发，通常比单台效劳器直接承载所有视频流量更合理。若视频文件很大、会看法域疏散，优先评估带宽和 CDN 掷中率，而不?是先调解毗连超时时间。

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

Nginx 不会自动降低视频码率，也不会把一个 4K 文件酿成适合移动网络播放的版本。想让差别网络条件下都坚持流通，通常需要准备?多档清晰度和码率，并让播放器凭证实时带宽举行自顺应切换。

• 点播 MP4：准备合适的区分?率和码率，并将 moov 元数据放到文件前部。
• 点播 HLS：天生多码率播放列表，让播放器在网络变差时切换到低码率分片。
• 直播 HLS：坚持要害帧距离与分片界线协调，阻止切换码率时泛起长时间期待。
• 移动端播放：不要只提供高码率版本，应凭证终端屏幕和网络条件设置合理的清晰度梯度。

若是原视频自己码率远高于用户网络可承?受规模，Nginx 只能把问题更快地传给用户，不可从基础上消除缓冲。因此，“100%优化”更适相助为排查目的：让请求、文件、缓存、带宽和编码每一层都没有显着瓶颈，而不是依赖某一个神奇开关。

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

• 审查视频首次请求是否返回准确的 Content-Type，MP4 不应被当?成通俗文本或下载文件处置惩罚。
• 拖动播放进度，检查请求是否泛起 206 Partial Content、Accept-Ranges 和有用的 Content-Range。
• 比照缓存掷中前后的首字节时间、下载速率和回源流量，确认缓存确实镌汰了源站压力。
• 在低带宽、移动网络和高并发情形下划分测试，视察 Nginx 会见日志、过失日志、CPU、磁盘 I/O 和出口带宽。

只有当文件名堂、Range 请求、缓存战略、带宽容量和自顺应码率同时匹配营业场景时，Nginx 视频播放才华获得稳固的流通体现。

校对：罗昌平(rsln0LhyhW9amXY2JGVPfAtTlKfWu1zrzKg)