遇到 nginx100 视频播放卡顿、加载缓慢或要求中断时
，先别直接改缓存参数
。把“100”拆成具体监控项：它可能指 CPU、网卡带宽、衔接数或其他资源使用率达到告警阈值
，并不是一个能单独注明故障原因的 Nginx 谬误码
。先确认哪些视频受影响、从什么时辰起头
，再按要求、过程、网络、存储和配置的挨次排查
。

先分清卡顿产生在哪一段

别离用统一条视频查抄初次打开、拖动进度条、陆续播放和顶峰时段的阐发
。只有个别视频异常
，优先看文件蹊径、文件权限和文件自身；统一目录的视频普遍慢
，沉点看静态文件服务、磁盘和网卡；多个目录同时出现延长
，再查抄 Nginx 过程、上游服务和整体负载
。

同时观察是“首帧迟迟不出”“播放一段后缓冲”
，还是“拖动后期待很久”
。首帧慢通常与衔接成立、上游响应或文件读取有关；播放中反复缓冲常见于出口带宽不及、码率偏高或链路颠簸；拖动失效则要沉点查抄视频要求是否支持字节领域要求
。

查抄要求状态和视频分段响应

在浏览器开发者工具的网络面板中找到视频要求
，查看状态码、响应功夫、传输大幼和要求是否被反复沉试
。也能够从服务器提议领域要求
，观察响应头：

curl -sS -D - -o /dev/null \
  -H 'Range: bytes=0-1023' "$VIDEO_URL"

静态视频支持领域读取时
，常见响应是 206 Partial Content
，并带有 Content-Range
。若是始终返回 200
，播放器可能只能按整文件方式处置
，拖动或断点续播履历会变差；若是返回 416
，查抄要求的字节领域、文件大幼与代理链路是否一致
。不要只看浏览器提醒的“加载失败”
，还要把状态码和对应功夫段的 Nginx 接见日志对起来
。

景象或状态	优先查抄	定位方向
206 ，但缓冲频仍	响应耗时、文件发送快率、出口流量	带宽或读盘快率跟不上视频码率
200 ，拖动不顺	Range 要求头与响应头	领域要求未按预期传递或处置
404	要求 URI、映射目录、文件名大幼写	蹊径映射谬误或文件不存在
499	客户端断开功夫、响应耗时	客户端期待超时或网络中断
502、504	上游地址、衔接和响应功夫	代理服务异；蛏嫌蜗煊

确认 Nginx 是否真的处于满载

在故障产生时查看过程和系统指标
，预防拿整机 CPU 的瞬时峰值直接当成 Nginx 过载：

top
ps -eo pid,comm,%cpu,%mem --sort=-%cpu | head
ss -s

若是 Nginx 工作过程持续占用高 CPU
，结合接见日志查看是否有大量沉复要求、异常扫描、频仍幼文件接见或日志写入压力；若是 CPU 不高但带宽靠近网卡或线路上限
，瓶颈更可能在视频出口
。衔接数持续增长时
，再查看活跃衔接、客户端起源和要求是否长功夫未实现
。内存占用高也要结合系统是否产生互换、过程是否持续增长判断
，不能仅凭一个百分比就增长 worker 数量
。

日志可按故障功夫筛出响应码、要求耗时和上游耗时
。若配置了相应日志字段
，沉点对照 $status、$request_time 与 $upstream_response_time：要求总耗时高、上游耗时也高
，先处置上游；总耗时高而上游耗时低
，则持续查抄文件读取、网络发送和客户端衔接
。

排查带宽、磁盘和上游服务

统一视频在服务器本机读取很快、表部播放却持续缓冲
，优先查网卡流量、丢包和出口限快；分歧功夫段阐发差距显著
，尤其要对照顶峰时段的带宽曲线
。视频均匀码率靠近可用出口带宽时
，即便 Nginx 过程正常
，多个观多同时播放也会争抢吞吐量
８丛疤岵皇恰癈PU 降下来」剽么单一
，而是现实发送快率能持续高于视频播放所需码率
。

若是文件位于机械盘、网络盘或远端存储
，查抄读盘期待、存储延长和文件是否频仍被迁徙
。代理方式提供视频时
，还要别离测上游首字节功夫与齐全响应功夫：上游慢
，调整 Nginx 缓存无法解除源头延长；上游正常而代理端慢
，则查抄本机网卡、衔接复用和代理配置
。

凭据证据调整静态文件与代理配置

本机磁盘上的静态视频
，可查抄对应 location 是否正确映射目录、文件是否可读
，以及静态发送配置是否适合当前环境
。例如：

location /video/ {
    sendfile on;
    tcp_nopush on;
}

这类设置要放在现实射中的配置块中
，批改后先执行配置查抄
，再滑润沉载；若文件走代理
，则应查抄代理是否正确传递 Range 要求
，并确认缓存战术不会把分歧字节领域的响应混为一份
。不要在没有凭据时直接关关代理缓冲、扩大超不断间或给所有客户端设置限快
，这些扭转可能覆盖上游故障
，或让衔接持久占用
。

若是日志中大量出现 502、504
，先验证上游服务可用性、衔接超时和响应功夫；若是 404 集中在某个目录
，查对 URI 与磁盘蹊径的映射；若是谬误码正常但传输快率低
，持续回到网卡、磁盘和码率查抄
。每次只调整与当前证据对应的一项
，沉测一样视频和一样操作
，预防多个扭转叠加后无法判断成效
。

复原后再做一次对照测试

排查实现后
，别离验证初次播放、拖动、陆续播放和并发要求
。确认领域要求返回合理的部门响应
，接见日志不再持续出现对应谬误
，Nginx 工作过程与出口资源回到不变区间
，并且播放期间下载快率能满足视频码率需要
。若只有顶峰时段复发
，就持续萦绕并发流量、出口容量和视频码率定位；若单文件复发
，则回查该文件的蹊径、存储状态和要求领域
。按这条挨次定位
，能把 nginx100 视频问题从抽象的“服务器满了”
，落实到具体要求和资源瓶颈
。