“nginx100%video100%”通常不是 Nginx 的正式报错，而是视频播放时代泛起了 Nginx CPU 占用 100%、网卡带宽抵达上限，或者视频请求占满毗连资源。处置惩罚前必需先区分 CPU、磁盘 I/O、网络带宽和毗连数，不然仅修改 worker 数目，往往不可解决卡顿。

Nginx 视频效劳泛起高负载时，优先执行 top -H -p Nginx历程号、pidstat -p 历程号 1、iostat -xz 1 和 sar -n DEV 1，同时审查会见日志中的请求路径、响应时间、状态码和返回字节数。CPU 高而网络低，重点查压缩、TLS、日志和视频处置惩罚；网络抵达上限而 CPU 正常，重点查出口带宽、缓存和分发架构；磁盘延迟高，则重点查存储缓和存写入。

先确认 nginx100%video100%对应哪一种资源耗尽

Nginx 视频高负载的第一步是确认监控中的“100%”详细代表什么。Linux 中单个历程占用 100% CPU，通常只体现占满一个逻辑焦点；四核机械上显示 400%，才可能是四个焦点同时忙碌。容器设置了单核 CPU 配额时，历程抵达 100%也不即是整台宿主机已经满载。

Nginx 视频请求的真实瓶颈还需要连系播放端征象判断。用户缓冲并不必定说明 Nginx CPU 已满，也可能是视频码率凌驾了用户带宽、分片过大、首包响应慢，或播放重视复提倡 Range 请求。监控曲线、Nginx 日志和播放器网络面板应当同时比照。

按请求链路定位视频高负载泉源

静态 MP4 文件占满 CPU 或磁盘

Nginx 静态视频分发的主要事情是读取文件、处置惩罚 Range 请求并发送响应，正常情形下不应肩负视频转码使命。若 MP4 文件经由 gzip 压缩、频仍触发权限校验、每次请求都重新读取慢速磁盘，CPU 或磁盘延迟就会显着升高。

• 检查响应头：确认视频是否返回 206 Partial Content、是否包括 Accept-Ranges，以及大文件请求是否被过失地返回 200。
• 检查文件结构：MP4 的 moov 元数据最好位于文件前部，不然播放器可能先期待完整文件信息，造成首播延迟和特殊读取。
• 检查压缩设置：MP4、TS、M4S 等已经压缩的视频内容通常不适合再次 gzip，重复压缩只会增添 CPU 消耗。
• 检查 Range 行为：播放器或下载工具频仍提倡大宗小规模请求时，毗连数、系统挪用和日志量都会增添。

反向署理上游视频时泛起期待和暂时文件

Nginx 反向署理视频时，瓶颈可能位于上游存储、署理缓冲区或暂时文件，而纷歧定位于 Nginx 自己？ proxy_buffering 后，Nginx 会先读取上游响应，再按客户端速率发送；缓冲区缺乏时可能爆发暂时文件，慢客户端较多时会增添磁盘压力。

署理视频时需要划分视察 upstream_response_time、request_time 和 body_bytes_sent。上游响应时间长，说明工具存储、应用接口或源站读取慢；request_time 远高于 upstream_response_time，说明客户端吸收慢或署剃头送受限；两者都很高，则需要继续查源站和网络链路。

HLS 或 DASH 分片请求造成请求量过大

HLS 和 DASH 视频通常由播放列表及大宗小分片组成，单个分片流量不大，但并发用户增添后会形成很高的请求频率。分片时长过短、播放器频仍刷新播放列表、缓存响应头不对理，都会使 Nginx 在毗连治理和日志写入上消耗更多资源。

分片文件适合设置明确的缓存时间，并让相同分片只管掷中缓存。个性化鉴权参数不可直接所有作为缓存键，不然统一个分片会天生大宗险些相同的缓存工具；需要凭证营业将用户身份校验与公共视频内容缓存脱离处置惩罚。

适合视频文件的 Nginx 设置调解

Nginx 静态视频设置应优先镌汰数据复制、无效压缩和重复读取，设置修改后必需通过真实播放和压力监控验证。下面的设置适相助为排查起点，详细数值仍要连系文件巨细、磁盘类型、内存和并发量调解。

sendfile 适合本机磁盘上的静态文件发送，可以镌汰用户态与内核态之间的数据复制；当视频来自 proxy_pass 上游时，sendfile 并不可替换上游读取和署理缓冲。tcp_nopush 有助于镌汰响应头与首段数据的碎片发送，但在差别内核和网络情形下仍需实测。

Nginx 的 aio threads 和 directio 不应在不相识存储特征的情形下直接启用。机械硬盘、网络文件系统和外地 NVMe 的最佳设置差别；directio 可能绕过页缓存，热门小文件反而受损。建议先纪录 iostat 和播放延迟，再以单个视频目录举行灰度测试。

Nginx worker_connections 只限制单个 worker 可处置惩罚的毗连数目，不代表可承载的用户数或视频带宽。提高该值前，还要同步检查 worker_rlimit_nofile、系统文件形貌符上限、内核毗连行列、云主机带宽和上游毗连数。

署理缓存、毗连和 TLS 的优化界线

Nginx 视频署理缓存可以镌汰源站重复读取，但缓存设置必需避开带用户身份的私有内容。公共 HLS 分片和不带个性化内容的 MP4 可以使用 proxy_cache；带暂时署名、权限信息或用户水印的视频，应先确认缓存键不会造成越权。

proxy_cache_lock 能镌汰统一热门文件在缓存未掷中时被大宗请求同时回源，但它不可修复源站自己的慢读取。proxy_read_timeout 只决议期待上游的容忍时间，盲目调大可能让慢请求恒久占用毗连；盲目调小又可能中止正常的大文件传输。

TLS 占用较高时，Nginx 应检查会话复用、证书链、协议版本和硬件加速支持，而不是简朴增添 worker。视频内容自己不需要 gzip，关闭媒体类型压缩通常比调高压缩级别更直接；HTML 播放页面和 JSON 接口可以继续单独使用压缩。

视频出口带宽抵达上限时，Nginx 设置无法凭空增添可用带宽。limit_rate 可以控制单毗连速率，limit_conn 和 limit_req 可以限制异常并发，但限制过严会让正当用户更容易缓冲。大宗公网视频分发应把热门内容放到边沿缓存或专用分发层，让 Nginx 主要处置惩罚鉴权、回源和未掷中请求。

修复后用可量化指标验收

Nginx 视频优化的验收应同时笼罩正常播放、拖动进度、并发会见和异常请求，不可只视察首页翻开速率。至少保存以下指标：worker CPU、出口带宽、磁盘 await、活跃毗连数、206 比例、缓存掷中率、首字节时间、完整请求耗时和 4xx、499、5xx 比例。

1. 先测单文件：验证完整下载、从中心位置拖动、断点续传和多次 Range 请求是否正常。
2. 再测分片：检查播放列表刷新频率、分片缓存掷中和播放器一连拉取是否稳固。
3. 再测并发：逐步提高并发，不要一次把流量推到机械极限，划分纪录 CPU、网络和磁盘曲线。
4. 最后查异常：识别重复下载、超大 Range、伪造 User-Agent、无效鉴权和慢客户端，阻止把攻击流量误判为正常视频需求。

当 CPU、磁盘和网络都没有一连抵达上限，但用户仍然卡马上，应继续检查视频码率、分片时长、源站首包、播放器缓冲战略和用户侧网络。只有在资源指标与请求链路相互对应时，才华准确诠释 nginx100%video100%，并选择设置优化、缓存扩容、存储升级或分发架构调解。