反向代理视频源时的缓冲与超时设置

实时 HLS、DASH 或多码率输出会同时读取源文件并生成多个分片。视频分片任务应提前生成并缓存常用清晰度，播放请求只负责读取已经生成的文件；对所有用户同时实时切片，容易让 CPU 和磁盘同时达到高位。

nginx100%video100%的安全与配置检查清单

搜索“nginx100%video100%”通常是在排查视频播放、下载或转码场景中的资源异常：Nginx 进程占用 CPU 接近 100%，服务器带宽或磁盘读取也接近 100%，导致视频卡顿、首屏加载慢、连接数暴涨。处理前不要直接增加 worker_processes，应先确认到底是 CPU、带宽、磁盘 I/O 还是上游应用响应变慢。

视频文件通常已经经过编码压缩，继续使用 gzip 压缩 MP4、WebM、TS 等文件，往往增加 CPU 消耗，却不能带来明显的传输收益。视频静态目录应避免对媒体类型启用 gzip，压缩策略更适合用于 HTML、CSS、JavaScript、JSON 等文本内容。

检查是否有转码或切片进程

磁盘 I/O 跑满时，应检查视频文件是否存放在低性能磁盘、网络盘或共享存储中。大量用户从同一个机械磁盘读取不同位置的大文件，容易出现寻道等待；将热门文件放入更快的存储或缓存层，通常比单纯增加 Nginx worker 更有效。

nginx100%video100%的最终处理应结合访问日志和系统指标，而不是只依靠📌页面能否播放来判断。视频服务恢复后，还需要确认异常请求是否仍在持续☀️，否则短时间内降负载后可能再次达到上限。

视频播放导致 CPU 100% 时的重点排查项

视频播放导📚致 CPU 100%时，最先要区分“静态文件分发”和“实时处理”。Nginx 适合直接传输已经生成好的视频文件，不适合承担视频编码、解码、截图或复杂的实时切片任务。

视频断点续传依赖 Range⚡ 请求。浏览器拖动进度条、暂停后继续播放和分段加载都会请求文件的部分字节；服务端若不能正确返回部分内容，浏览器可能反复重试，造成无效流量和额外磁盘读取。

如果 CPU、磁盘和带宽同时达到高位，单项调参往往无法根治问题，应优先减少源站直接承载的视频流量，把热门内容交给缓存层，并将转码与实时切片任务从 Nginx 主机分离。只有先确定真正的瓶颈，Nginx 视频服务才能在不牺牲播放稳定性的前提下恢复正常。