若是“100%”是指让视频首帧、拖动、一连播放和多人并发都达?到最优，Nginx并不存?在一个翻开后就能完全解决问题的开关。它主要认真文件传输，现实体验还取决于视频编码、文件结构、效劳器磁盘、出口带宽、播放器和用户网络。

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

先判断卡顿爆发在哪一层

不要一看到播放卡顿就修改Nginx参数。先视察浏览器开发者工具中的媒体请求、响应状态和下载速率，通常可以凭证下面的征象定位问题。

视频播放问题与排查偏向

播放征象	重点检查	优先处置惩罚方法
首帧加载很慢，拖动到后面无法连忙播放	MP4的moov索引是否位于文件末尾，拖动请求是否返回206	执行faststart处置惩罚，并检查Range分段传输
低清正常，高清播放几秒后重复缓冲	视频码率是否恒久高于用户现实下载速率	降低码率或制作多档清晰度，使用自顺应播放
单人播放正常，多人同时会见后显着变慢	效劳器出口带宽、磁盘读取速率、毗连数和上游响应时间	使用缓存或CDN，阻止动态程序重复读取视频
视频地点能翻开，但?播放器报名堂或跨域过失	Content-Type、跨域响应头和播放器请求泉源	修正媒体类型，并仅对可信播放器域名开放跨域
直播列表更新慢，播放器停在旧画面	m3u8是否被浏览器、Nginx或中心缓存长时间缓存	直播播放列表使用no-cache，分片单独设置缓存

静态MP4的Nginx基础设置

若是视频文件直接存放在效劳器上，最好让Nginx直接读取，而不是每次经由PHP、Java或其他营业程序转发。下面是一份偏守旧的静态视频设置示例，适合果真会见且文件内容不会频仍转变的MP4、M4V和WebM文件。

sendfile可以镌汰文件从磁盘发送到网络时的特殊数据复制，通常适合大文件传输。tcp_nopush有助于配合sendfile发送较大的数据块，tcp_nodelay则可以镌汰部分小数据包的期待。它们不可增添效劳器自己的出口带宽，现实效果仍要通过真实播放和并发测试确认。

Nginx对静态文件通常原生支持字节规模请求，不要在视频目录中设置禁用Range的规则。检查时不要要求首次请求一定返回206，由于播放器首次获取完整文件信息时可能返回200；更主要的是，拖动进度条或从中心最先播放后，响应是否出?现206 Partial Content、Content-Range是否准确，以及效劳器是否只传输请求的片断。

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

先处置惩罚视频文件，再调解Nginx

许多所谓的“Nginx视频优化”着实首先应该在视频文件自己完成。MP4中的moov原子生涯时长、轨道和索引信息。若是它位于文件末尾，播放器可能要期待较长时间才?能获得完整信息，尤其是在移动网络或需要拖动播放时更显着。

可以在视频宣布前使用FFmpeg执行无损封装调解：

这条处置惩罚通常不会重新编码画面，速率较快，但条件是原视频编码和封装结构能够被目的?播放器接受。若是播放器兼容性仍然欠好，应重新编码为更通用的H.264视频和AAC音频，并凭证目的装备制作适当区分率与码率。

Nginx编译并加载了MP4模块时，可以使用mp4指令处置惩罚部分MP4伪流式场景，例如凭证start参数读取指定位置。但这个模块不是转码器，也不可替换faststart和Range请求；若是只是通俗HTML5视频播放，先把索引前置并验证分段请求，通常比盲目启用模块更稳妥。使用前应通过Nginx编译信息确认模块是否保存，不然加入该指令会导致设置检查失败。

单个MP4不敷稳固时，改用自顺应播放

单个MP4只能凭证牢靠码率传输。用户目今网络速率低于视频码率时，Nginx纵然传输效率很高，播放器仍然会缓冲。更适合多种网络情形的做法是将统一视频制作成多档清晰度，再通过HLS或DASH让播放器凭证带宽切换。

• 低码率版本：适合移动网络、弱网或低区分率装备，重点是包管一连播放。
• 中码率版本：作为大大都用户的常用档位，在清晰度和流通度之间取得平衡。
• 高码率版本：适合大屏和高速网络，但不应作为所有用户的默认档位。
• 要害帧距离：应连系切片长度和播放器需求设置。要害帧过少会影响拖动和切换，过密则会增添文件体积。

HLS或DASH只能解决“凭证网络选择码率”的问题，不可修复源文件损坏、效劳器带宽缺乏或播放器逻辑过失。Nginx在这里主要认真稳固地发送播放列表和分片，真正的转码、切片和码率妄想应在宣布流程中完成。

HLS、反向署理与缓存要脱离设置

直播HLS的?m3u8播放列表会一连转变，不可使用与牢靠视频分片相同的长缓存战略。一个常见的静态分发思绪如下：

上面的分片缓存战略只适用于分片文件名不?会被重复笼罩的情形。若是系统会用统一个文件名替换旧分片，就不可随意设置immutable，不然用户可能一连读取旧内容。点播列表?可以接纳更长缓存，但直播列表通常需要实时重新请求。

若是视频由上游效劳提供，必需确认Nginx没有扬弃客户端的Range和If-Range请求，也没有把上游返回的206、Content-Range和Content-Length过失改写。反向署理中的proxy_buffering不可一概而论：点播大文件可以使用缓冲镌汰上游毗连压力，直播或需要尽快把数据推给播放器的场景则可能需要关闭或缩短缓冲。应凭证首帧时间、磁盘暂时文件和上游毗连数举行测试，而不是直接套用“关闭缓冲?就一定更快”的结论。

跨域播?放时还要检查响应头。若播放器和视频不在统一泉源，需要允许播放器所在的可信泉源会见媒体资源；使用Cookie或授权信息时，不应简朴地对所有泉源开放通配跨域。果真免费视频与带权限的视频，缓存规则也必需脱离，私有视频不可使用面向所有用户的public缓存。

缓存和带宽决议多人播放上限

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

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

worker_processes auto和worker_connections主要影响Nginx能够治理的历程与毗连数目，并不会凭空增添网络出口能力。调解前还要同步检查文件形貌符、内核毗连限制和现实带宽。不要随意使用limit_rate限制视频速率，不然可能把原本正常的毗连人为酿成卡顿毗连。

上线前按播放场景验收

• 先执行Nginx设置检查，确认正则位置、媒体目录权限和模块指令没有过失，再平滑加载新设置。
• 划分测试首次播放、拖动到中心、从中心刷新和一连播放，视察请求状态、Content-Range、Content-Type与现实下载速率。
• 用电脑、手机和差别网络测试统一个视频，区分是牢靠文件传输问题，照旧简单网络情形导致的带宽缺乏。
• 对HLS检查m3u8是否一连更新、分片是否能实时返回，以及分片缓存是否因文件名复用而爆发旧内容。
• 多人会见时视察Nginx会见日志、过失日志、磁盘I/O、CPU、出口带宽和上游响应时间，找到最先抵达瓶颈的指标。
• 果真点播、直播、跨域播放和登录后私有视频划分建设设置，不要用一套长缓存和跨域规则笼罩所有资源。

因此，Nginx100%视频优化的准确落地顺序是：先修复视频封装和码率，再确认Range分段传输，然后优化静态文件发送与缓存，最后凭证并发量引入自顺应码率和边沿分发。只有先找到现实瓶颈，Nginx设置调解才会真正改善播放流通度。

校对：何伟(rsln0LhyhW9amXY2JGVPfAtTlKfWu1zrzKg)