nginx100%video100% 不是 Nginx 官方过失码、设置项或标准监控指标，通常体现 Nginx 承载视频文件、直播流或切片请求时，CPU、带宽、磁盘读取、毗连数中的一项或多项抵达 100%。排查重点不是修改一个名为“video100%”的参数，而是先确认究竟是哪类资源耗尽。

若是 Nginx 视频效劳已经泛起播放卡顿、响应变慢、效劳器负载升高，优先审查 CPU 使用率、出口带宽、磁盘 I/O、活跃毗连数和过失日志。静态 MP4 大文件下载、HLS 或 DASH 小切片请求、反向署理直播流，爆发高负载的缘故原由并不相同，不可使用统一套设置直接处置惩罚。

nginx100%video100% 对应哪一种资源满载

Nginx 视频效劳的“100%”必需对应详细监控指标，单看面板上的一个百分比无法判断故障位置。Linux 主机可以先视察整体负载，再区分 Nginx 历程、磁盘和网卡的转变。

视频效劳常见满载征象与判断偏向

体现	优先视察	常见缘故原由	处置惩罚重点
CPU 靠近 100%	top、pidstat、历程线程	署理转发、TLS、日志写入、请求洪泛	降低署理开销，限制异常请求
出口带宽靠近上限	网卡流量、发送速率、单 IP 流量	大文件直出、多人并发、盗链	缓存、限速、鉴权、使用 CDN
磁盘读取一连很高	iostat、磁盘行列、读吞吐	冷文件下载、缓存失效、机械盘并发	缓存热门文件，优化存储层
毗连数靠近上限	活跃毗连、worker_connections	长毗连、慢客户端、直播署理群集	检查超时、毗连上限和上游状态

Nginx 会见日志还应重点审查请求路径、状态码、响应字节数和请求耗时。大宗相同视频文件、相同 IP 高频下载、单个请求一连良久，往往能直接说明是热门下载、盗链照旧长毗连占用。

静态 MP4 下载为什么会让 Nginx 负载升高

静态 MP4 文件由 Nginx 直接发送时，主要压力通常落在网卡和磁盘，而不是视频编码自己。Nginx 不会由于“明确视频内容”而自动完成转码；若是 CPU 显着升高，需要进一步检查 TLS 加密、署理转发、日志、限速？榛蛞斐Ｇ肭。

• 文件过大且并发集中：多个用户同时请求统一部高清影片，会一连占用出口带宽和文件读取通道。效劳器带宽缺乏时，毗连会变慢，慢客户端又会延伸毗连生命周期。
• Range 请求过多：播放器拖动进度、断点续传和多次重试都会发送字节规模请求。Range 自己不是过失，但过失的缓存战略可能让统一片断重复回源。
• 会见日志写入频仍：视频切片或下载请求数目很大时，磁盘写日志的开销可能高于静态文件发送。日志文件过大还会增添轮转和磁盘空间压力。
• 单机肩负所有出口流量：源站直接向所有用户发送完整视频，源站带宽和毗连数会随着寓目人数线性增添，热门内容尤其容易形成瓶颈。

静态视频文件应优先确认响应头是否支持 Range 请求，并检查播放器是否收到准确的 Content-Length、Content-Range 和 Accept-Ranges。视频文件通常不适合再使用 gzip 压缩，重复压缩会增添 CPU 消耗，却很难带来有用体积下降。

HLS、DASH 与直播署理的排查重点

HLS 或 DASH 视频效劳的压力结构与单个 MP4 下载差别。播放器会一连请求 m3u8、mpd、ts、m4s 或其他媒体分片，文件数目更多、请求频率更高，短请求集中泛起时，毗连和会见日志可能先抵达瓶颈。

切片文件缓存与响应头

HLS 切片缓存应凭证内容类型设置差别战略。已经天生且不会转变的历史分片可以使用较长缓存时间，正在更新的播放列表需要较短缓存时间，不然播放器可能拿到逾期清单或重复请求统一内容。

• 播放列表适合短缓存，并凭证直播延迟要求控制缓存时间。
• 已完成的媒体分片适合较长缓存，镌汰源站重复读取。
• 静态切片需要准确设置 Content-Type，阻止播放器误判文件名堂。
• 高频小文件应关注文件系统缓存、翻开文件数目和日志写入速率。

反向署理直播流

Nginx 反向署理直播流时，毗连会恒久坚持，资源消耗取决于寓目人数、上游毗连数和下游网络质量。慢客户端会让署理毗连一连占用，直播源异常则可能造成大宗重连，形成毗连数和上游请求同时升高。

直播署理设置应单独检查 proxy_read_timeout、proxy_send_timeout、proxy_buffering 和上游毗连池。关闭署理缓冲并不适合所有场景：实时性要求高的直播转发通常需要镌汰期待，但点播署理更需要合理缓存，阻止每次播放都重新读取源站。

降低 Nginx 视频负载的设置与架构步伐

降低 Nginx 视频负载需要先匹配营业类型，再调解设置。静态点播、切片点播和实时直播的优化偏向差别，盲目增添 worker_connections 不可解决带宽缺乏、磁盘过慢或上游转码过载。

静态点播效劳器

• 启用高效文件发送：确认 sendfile 是否适合目今操作系统和存储情形，并视察开启后磁盘与网卡体现。
• 镌汰重复文件查找：热门视频较多时，可以评估 open_file_cache，降低频仍翻开文件和读取文件属性的开销。
• 保存断点续传能力：不要为了镌汰请求而随意禁用 Range，播放器拖动和失败重试通常依赖该能力。
• 控制下载速率：对通俗用户、单 IP 或单毗连设置合理限速，阻止少数下载使命耗尽出口带宽。
• 疏散会见日志：视频请求可以使用自力日志战略，须要时降低无价值的乐成请求纪录频率，但过失日志仍应保存。

切片点播与直播效劳

• 把热门内容放到缓存层：CDN 或边沿缓存可以镌汰源站重复发送相同文件，源站只承；卦春湍谌莞。
• 限制异常请求：对不保存的切片、频仍刷新播放列表、短时间大宗 Range 请求设置会见频率限制。
• 控制上游重试：直播源不稳固时，太过重试会放大故障，应设置合理的毗连、读取和重试超时。
• 拆分转码与分发：转码、截图、封装和视频分发不应恒久争用统一台主机的 CPU、磁盘和网络资源。

worker_processes 通？梢云局 CPU 核数和现实压测效果设置，worker_connections 只代表单个事情历程可治理的毗连规模，不等同于可承载的寓目人数。文件形貌符上限、内核毗连行列、带宽上限和上游效劳能力同样需要匹配。

按顺序处置惩罚 nginx100%video100% 故障

nginx100%video100% 故障处置惩罚应从“确认指标”最先，而不是先复制一份通用 Nginx 设置。下面的顺序适合线上泛起视频卡顿、效劳器负载突然升高或出口流量异常时使用。

1. 确认时间规模：比照故障最先时间与宣布新视频、修改缓存、启用署理、播放器升级或流量上涨的时间点。
2. 区分资源类型：划分审查 CPU、内存、磁盘 I/O、网卡出口和活跃毗连，纪录峰值一连时间，不要把系统负载直接等同于 CPU 满载。
3. 定位请求泉源：从会见日志中统计请求路径、客户端 IP、状态码、响应字节数和耗时，找出最大文件、最高频路径和异常泉源。
4. 验证 Range 与缓存：检查播放器首次请求、拖动请求和断点续传是否掷中缓存，确认缓存层没有由于盘问参数或响应头导致重复回源。
5. 检查上游链路：反向署理场景需要同时审查上游毗连、读取耗时、重试次数和上游返回码，阻止只调 Nginx 而忽略源站转码或存储异常。
6. 实验单项变换：一次只调解缓存、限速、日志、署理缓冲或毗连超时中的一项，并用相同流量举行比照，阻止多项修改后无法判断效果。

当 CPU 不高但带宽抵达上限时，增添 worker 历程没有资助；当带宽富足但磁盘期待很高时，扩容网卡也不可解决问题；当毗连数很高而请求耗时异常时，应优先检查慢客户端、超时和上游效劳。凭证资源瓶颈选择步伐，才华把视频分发恢复到可展望状态。

人民网校对：陈嘉倩(1wIeasW5O1NMOC4IXkZPp3FnN8mJlVns)