适合视频文件的 Nginx 配置调整

“nginx100%video100%”通常不是 Nginx 的正式报错，而是视频播放期间出现了 Nginx CPU 占用 100%、网卡带宽📚达到上限，或者视频请求占满连接资源。处理前必须先区分 CPU、磁盘 I/O、网络带宽和连接数，否则仅修改 worker 数量，往往不能解决卡顿。

Nginx 视频服务出现高负载时，优先执行 top -H -p Nginx进程号、pidstat -p 进程号 1、i📌ostat -xz 1 和 sar -n DEV 1，同时查看访问日志中的请求路径、响应时间、状态码和返回字节数。CPU 高而网络低，重点查压缩、TLS、日志和视频处理；网络达到上限而 CPU 正常，重点查出口带宽、缓存和分发架构；磁盘延迟高，则重点查存储和缓存写入。

Nginx 视频请求的真实瓶颈还需要结合播放端现象判断。用户缓冲并不必然说明 Nginx CPU 已满，也可能是视频码率超过了用户带宽、分片过大、首包响应慢，或播放器反复发起 Range 请求。监控曲线、Nginx 日志和播放器网络面板应当同时对照。

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

proxy_cache_lock 能减少同一热点文件在缓存未命中时被大量请求同时回源，但它不能修复源站本身的慢读取。pr▶️oxy_read_time📚out 只决定等待上游的容忍时间，盲目调大可能让慢请求长期占用连接；盲目调小又可能中断正常的大文件传输。

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

静态 MP4 文件占满 CPU 或磁盘

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

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

视频出口带宽达到上限时，Nginx 配置无法凭空增加可用带宽。limit_rate 可以控制单连接速度，limit_conn 和 limit_req 可以限制异常并发，但限制过严会让合法用户更容易缓冲。大量公网视频分发应把热点内容放到边缘缓存或专用分发层，让 Nginx 主要处理鉴权、回源和未命中请求。

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

Nginx 反向代理视频时，瓶颈可能位于上游存储、代理缓冲区或临时文件，而不一定位于 Nginx 本身。开启 proxy_buffering 后，Nginx 会先读取上游响应，再按客户端速度发送；缓冲区不足时可能产生临时文件，慢客户端较多时会增加磁盘压力。

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

Nginx worker_connections 只限制单个 worker 可处理的连接数量，不代表可承载的用户数🔍或视频带宽。提高该值前，还要同步检查 worker_rlimit_nofile、系统文件描述符上限、内核连接队列、云主机带宽和上游连接数。

反向代理上游视频时出现等待和临时文件

Nginx 视频优化的验收应同时覆盖正常播放、拖动进度、并发访问和异常请求，不能只观察首页打开速度。至少保😎留以下指标：worker CPU、出口带宽、磁盘 await、活跃连接数、206 比例、缓存命中📌率、首字节时间、完整请求耗时和 4xx、499、5xx 比例。