nginx100视频出现卡顿、转圈或播放一段后停住，排查时先看播放器请求是否正常，再检查传输速度、服务器资源和视频文件。不要一开始就反复刷新或更换播放器：先判断是单个视频异常，还是多个视频都卡，再按下面的顺序缩小范围。
先区分卡顿发生在哪个环节
如果点击播放后长时间黑屏，优先检查视频请求是否成功；如果能播放、随后频繁缓冲，重点看持续下载速度和网络波动；如果只有某一段画面停住，检查文件编码、切片或该时间点对应的请求。用同一设备分别播放另一个视频，再换一条网络测试，可以快速区分单条资源故障与设备、网络问题。
第一步：检查浏览器请求状态与响应内容
打开浏览器开发者工具的“网络”面板，重新播放并筛选媒体请求。重点查看状态码、响应大小、耗时和请求是否反复重试。常见结果可按下表判断：
| 现象 | 优先检查 | 处理方向 |
|---|---|---|
| 请求返回 404 | 视频路径、文件名及大小写 | 修正资源路径或恢复对应文件 |
| 请求返回 403 | 访问权限、防盗链规则及签名有效期 | 调整访问规则或更新有效资源地址 |
| 请求返回 5xx | 上游服务、磁盘和 Nginx 错误日志 | 先恢复服务，再复测视频请求 |
| 长时间等待或反复中断 | 首字节时间、连接稳定性及下载速度 | 继续检查带宽、负载和代理链路 |
| 拖动进度条后失败 | Range 请求及分段响应 | 确认服务器或代理正确处理范围请求 |
对于支持断点读取的 MP4，浏览器拖动进度条时通常会请求文件的一段数据，响应中常见 206 状态和 Content-Range 信息。若请求被改写成错误的完整文件响应，或返回 416，前后拖动可能失败。对照正常视频的请求头与响应头，检查代理是否移除了 Range、错误缓存了部分响应，或把范围边界传错。
第二步：用日志定位服务器端耗时
若请求状态异常，查看 Nginx access log 和 error log，按发生时间找到对应视频请求。重点关注状态码、发送字节数、请求总耗时和上游响应耗时：状态码正常但请求耗时持续偏长，通常要继续查传输链路或机器负载；发送字节数明显小于文件大小，且请求中途结束，则要检查连接是否被客户端、代理或上游提前关闭。
还要留意同一资源是否被短时间大量请求，以及错误日志是否出现文件不存在、权限拒绝或上游超时。修正路径、目录读取权限或上游连接后，再用浏览器重新播放，确认请求不再报错且字节数符合预期。
第三步：比较实际下载速度与视频码率
播放流畅需要持续下载速度高于视频码率，并留出网络波动余量。例如视频平均码率为 4 Mb/s，链路若只能稳定提供约 3 Mb/s，即使开播时缓存足够，也容易在几分钟后再次转圈。可在播放器缓冲期间观察媒体请求的下载速度，并分别检查用户网络、服务器出口带宽和并发占用。
若同一网络播放其他视频正常，而 nginx100视频的请求速度明显偏低，应查看服务器网卡流量、CPU、磁盘读取和连接数。系统监控工具可观察网卡收发与负载；若出口带宽长期接近上限，先减少不必要的并发占用或扩充传输能力，再测同一视频。若服务器负载平稳而某个地区普遍慢，则进一步检查 CDN 节点与回源链路。
第四步：检查 Nginx 静态文件与代理配置
如果视频由 Nginx 直接提供，确认 MP4 文件的路径和读取权限正确，响应类型为 video/mp4，且静态资源没有被错误的缓存或压缩规则处理。配置中可以检查对应目录的 alias 或 root 是否与真实文件位置一致；修改后先执行配置检查，再平滑重载服务。不要把“开启某个模块”当作所有卡顿的通用修复，优先以请求状态和响应头确认问题确实出在文件传输。
如果视频经过反向代理，检查代理超时、缓冲及上游连接设置是否适合大文件传输。上游已快速返回而客户端接收缓慢时，单纯增加代理超时并不会提升带宽；如果上游响应本身很慢，则应先定位源站磁盘读取或应用处理。调整配置后，对照修改前后的响应状态、首字节时间和下载速度。
第五步：核对视频文件并确认恢复
只有一条视频反复卡在同一位置时，检查文件是否完整、容器索引是否正常，以及编码参数是否被目标浏览器支持。将问题文件与一条正常文件对比大小、时长、分辨率和编码格式；重新封装或转码后替换资源，并清理对应缓存，避免播放器继续读取旧文件。若播放能开始但拖动后黑屏，也要检查文件索引是否位于便于读取的位置。
排查完成后，用同一设备连续播放数分钟，再执行暂停、继续、拖动进度条和重新加载。状态码稳定、分段请求正常、缓冲速度高于播放码率，且卡顿点不再重现，才算恢复。若只有特定网络仍慢，就沿该网络到 CDN、再到源站逐段比对请求耗时，避免把局部线路问题误判为视频文件损坏。