遇到 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 访问日志对起来
。

确认 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 进程正常，多个观众同时播放也会争抢吞吐量
；指刺跫不是“CPU 降下来”这么简单，而是实际发送速度能持续高于视频播放所需码率
。

如果文件位于机械盘、网络盘或远端存储，检查读盘等待、存储延迟和文件是否频繁被迁移
。代理方式提供视频时，还要分别测上游首字节时间与完整响应时间：上游慢，调整 Nginx 缓存无法消除源头延迟；上游正常而代理端慢，则检查本机网卡、连接复用和代理配置
。

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

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

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

这类设置要放在实际命中的配置块中，修改后先执行配置检查，再平滑重载；若文件走代理，则应检查代理是否正确传递 Range 请求，并确认缓存策略不会把不同字节范围的响应混为一份
。不要在没有依据时直接关闭代理缓冲、扩大超时时间或给所有客户端设置限速，这些改动可能掩盖上游故障，或让连接长期占用
。

如果日志中大量出现 502、504，先验证上游服务可用性、连接超时和响应时间；如果 404 集中在某个目录，核对 URI 与磁盘路径的映射；如果错误码正常但传输速度低，继续回到网卡、磁盘和码率检查
。每次只调整与当前证据对应的一项，重测相同视频和相同操作，避免多个改动叠加后无法判断效果
。

恢复后再做一次对照测试

排查完成后，分别验证首次播放、拖动、连续播放和并发请求
。确认范围请求返回合理的部分响应，访问日志不再持续出现对应错误，Nginx 工作进程与出口资源回到稳定区间，并且播放期间下载速度能满足视频码率需求
。若只有高峰时段复发，就继续围绕并发流量、出口容量和视频码率定位；若单文件复发，则回查该文件的路径、存储状态和请求范围
。按这条顺序定位，能把 nginx100 视频问题从笼统的“服务器满了”，落实到具体请求和资源瓶颈
。