nginx100%video100%不是 Nginx 官方指令或牢靠过失代码，通常体现视频播放场景中 CPU、网络带宽、磁盘 I/O 或毗连数抵达 100%。处置惩罚重点不是盲目增添 worker，而是先确认是哪项资源跑满，再凭证静态 MP4、HLS 分片、反向署理或实时流媒体选择设置。

若是 Nginx 主要提供已经编码完成的 MP4 文件，正常情形下 CPU 不应由于纯粹发送文件而恒久满载；若是 CPU、带宽和磁盘同时升高，常见缘故原由是并发下载、重复回源、开启视频 gzip、TLS 握手过多或后端转码混入了 Nginx 主机。所谓“解锁视频流媒体的极致性能”，现实需要建设在资源定位、断点续传、缓存战略和分发架构都匹配的基础上。

先判断 100% 对应哪一项效劳器资源

Nginx 视频效劳的第一项检查是区分 CPU、出口带宽、磁盘 I/O 和毗连数，由于四种指标的处置惩罚方法完全差别。只看监控面板上的一个“使用率 100%”，无法直接判断设置过失。

Nginx 会见日志应至少纪录 status、request_time、body_bytes_sent、request_length、http_range 和 upstream_response_time。top 或 htop 可以确认 CPU 历程，iostat 可以视察磁盘期待，ss 可以统计毗连状态，流量监控则用于确认出口是否真正饱和。日志中的 206 响应比例较高，通常说明播放器正在举行规模请求或断点续传。

静态 MP4 文件需要哪些 Nginx 基础设置

Nginx 静态 MP4 效劳的焦点使命是高效读取文件并直接发送，不应在每个请求中重复举行压缩、转码或重大剧本处置惩罚。视频目录应只管与动态应用脱离，阻止 PHP、Java 或其他后端历程加入每一段文件传输。

• sendfile on：让 Nginx 只管使用内核文件发送机制，镌汰用户态复制，但最终效果仍受操作系统、文件系统和存储装备影响。
• tcp_nopush on：适合配合 sendfile 发送较大的一连文件，可镌汰过多的小数据包；启用后需要用真实播放器和差别网络情形测试。
• aio threads：在版本和系统支持时，可用于降低大文件读取对 worker 的壅闭。没有线程异步支持时，不应仅凭设置名称判断一定有用。
• gzip：MP4、TS 等已经压缩的视频通常没有须要再次 gzip。全局 gzip 设置不应把 video/mp4、video/mp2t 等概略积媒体类型纳入压缩规模。
• 文件类型：MP4 应返回准确的 video/mp4，WebM 应返回 video/webm，HLS 播放列表和分片则划分使用对应的 MIME 类型。

Nginx 静态文件通常原生支持 Range 请求，播放器可以从中心位置最先读取，也可以在网络中止后继续下载。排查时应使用浏览器开发者工具或播放器网络面板确认 Range 请求是否返回 206、Content-Length 是否合理，以及响应是否被应用层重写。

MP4 点播与 HLS 分片不可用统一套判断

Nginx MP4 点播适合文件数目有限、希望直接提供单文件播放和拖动进度的场景。启用了 mp4 ？楹，Nginx 可以配合最先时间参数处置惩罚部分伪流式播放需求，但该？楸匦柙诒嘁牖蜃爸冒姹局邢质当４，不可把设置写入后就假设功效已经启用。

Nginx HLS 分发适合把视频拆成播放列表和多个短分片的场景。播放器会一连请求新的分片，因此请求数目可能显着高于单个 MP4；HLS 需要重点优化小文件缓存、文件翻开次数、缓存掷中率和跨域响应，而不是只关注 sendfile。

• MP4 文件更新频率低时，可以设置较长的浏览器或 CDN 缓存时间。
• HLS 分片使用文件名版本化后，可以接纳更稳固的恒久缓存战略。
• M3U8 播放列表更新较快时，缓存时间应短于视频分片，直播场景尤其需要单独设置。
• 公共视频的出口流量较大时，应让边沿缓存肩负重复请求，源站只认真缓存未掷中的内容。

CPU、带宽和磁盘划分跑满时的处置惩罚分支

Nginx CPU 100%时，治理员应先确认是否真的由 Nginx worker 消耗，而不是 ffmpeg、视频转码历程、数据库或清静扫描程序占用。静态发送自己通常不是高 CPU 操作，视频 gzip、HTTPS 新毗连过多、重大 rewrite、会见日志同步写入以及应用署理都可能放大处置惩罚本钱。

• CPU 高而流量不高：检查 gzip、TLS 握手、转码历程和正则 rewrite，阻止把视频请求交给动态应用。
• 带宽高而 CPU 低：先确认高流量是否切合预期。带宽跑满纷歧定是故障，也可能只是目今出口无法承载现实视频码率。
• 磁盘期待高而内存富足：检查媒体目录是否位于低速磁盘，视察缓存是否频仍失效，以及大宗用户是否同时请求差别的大文件。
• 毗连数高而吞吐不高：检查慢客户端、超长 keepalive、读取超时和异常泉源，阻止单个毗连长时间占用资源。

Nginx worker_processes 设置为 auto 通常比手工写一个过大的数字更稳妥。增添 worker 数目不可解决带宽缺乏、磁盘延迟或上游转码过慢，过多 worker 还可能增添上下文切换和内存消耗。limit_rate 可以控制单请求发送速率，但它只能缓解突发占用，不可替换容量妄想。

反向署理视频和断点续传的要害检查

Nginx 反向署理视频时，性能瓶颈可能位于上游应用、工具存储、署理缓冲区或源站到 Nginx 的链路。播放器能够翻开页面，不代表视频字节约已经稳固传输，必需划分审查客户端响应时间和 upstream_response_time。

• 上游响应慢：检查应用是否每次播放都重新鉴权、盘问数据库或天生文件。已经保存的媒体文件应只管直接读取或由工具存储提供。
• 署理缓冲过大：点播和直播不可简朴套用统一项 proxy_buffering 设置。关闭缓冲可能降低实时期待，但会让上游毗连更长时间坚持；开启缓冲有利于部分点播请求，却可能增添磁盘或内存压力。
• Range 头丧失：检查署理是否转发 Range 和 If-Range，确认后端没有把所有请求强制返回 200，也没有过失地缓存差别规模的响应。
• 响应头被笼罩：确认 Content-Type、Content-Length、Content-Range、Accept-Ranges 缓和存头没有被应用层过失修改。
• 毗连频仍建设：检查 keepalive、TLS session reuse 和上游毗连复用，短视频分片过多时，毗连治理的本钱会显着增添。

Nginx 署理直播流时，超时设置需要笼罩正常的分片或长毗连周期，但不可无限期待失效上游。Nginx 署理点播大文件时，则应关注客户端断开后的资源接纳、缓存文件整理和上游响应是否仍在一连占用毗连。

用一次完整测试确认 nginx100%video100% 是否已解决

nginx100%video100%的排查效果必需通过统一文件、统一网络条件和相近并发量复测，不可只看修改设置后短时间内的监控曲线。单个浏览器播放乐成，只能证实基本可用，不可证实高并发传输稳固。

1. 先测单请求：确认状态码、Content-Type、Content-Length、Range 响应和首字节时间，扫除文件权限与 MIME 类型问题。
2. 再测断点续传：拖动进度条并中止网络，确认播放器可以重新提倡规模请求，而不是重新下载完整文件。
3. 再测多用户下载：逐步增添并发，划分视察 CPU、磁盘期待、出口带宽、毗连数和过失率，纪录每个阶段的转变。
4. 最后看日志漫衍：统计 200、206、304、403、404、499、5xx 的比例。499 增多可能代表客户端提前断开，5xx 增多则需要继续检查上游或存储。
5. 验证缓存掷中：重复请求统一个视频或分片，较量源站读取量、响应时间和边沿缓存体现，确认缓存战略没有因盘问参数或响应头失效。

当 CPU 正常但出口带宽已经抵达上限时，继续调解 Nginx 指令不会凭空增添带宽；当磁盘期待恒久过高时，纯粹增添 worker 也不可替换存储升级或缓存分流。nginx100%video100%的准确解决路径，是先确定瓶颈，再在传输协议、缓存、毗连治理和基础设施之间做对应调解。