静态MP4的Nginx基础配置

sendfile可以减少文件从磁盘发送到网络时的额外数据复制，通常适合大文件传输。tcp_nopush有助于配合sendfile发送较大的数据块，tcp_nodelay则可以减少部分小数据包的等待。它们不能增加服务器本身的出口带宽，实际效果仍要通过真实播放和并发测试确认。

先判断卡顿发生在哪一层

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

worker🔑_processes auto和worker_connections主要影响Nginx能够管理的进程与连接数量，并不会凭空增加网络出口能力。调整前还要同步检查文件描述符、内核连接限制和实际带宽。不要随意使用🍀limit_rate限制视频速率，否则可能把原本正常的连接人为变成卡顿连接。

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

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

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

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

如果视频文件直接存放在服务器上，最好让Nginx直接读取，而不是每次经过PHP、Java或其他业务程序转发。下面是一份偏保守的静态视频配置示例，适合公开访问且文件内容不会频繁变化的MP4、M4V和W📌ebM文件。

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

如果视频由上游服务提供，必须确认Nginx没有丢弃客户端的Range和If-Range请求，也没有把上游返回的206、Content-Range和Content-Length错误改写。反向代理中的proxy_buffering不能一概而论：点播大文件可以利用缓冲减少上游连接压力，直播或需要尽快把数据推给播放器的场景则可能需要关闭或缩短缓冲。应根据首帧时间、磁盘临时文件和上游连接数进行测试，而不是直接套用“关闭缓冲就一定更快”的结论。