视频传到网站上能正常点开，可只要一拖进度条就卡死、弹回原位，严重时干脆黑屏——这是网站维护里出现频率很高的一类报障。它和那种彻底打不开的情况要分开看：完全播不了，往往意味着文件坏了、格式不兼容或者链接指错了地方；而能播却拖不动，说明解码这条路大体是通的，症结基本落在“按需取片段”这个环节。与其一遍遍重新上传，不如按下面四层的顺序逐项核对，效率会高得多。
第一层，先确认文件本身有没有问题。 浏览器拖动播放，靠的是服务端能按字节范围回传数据，而视频文件想支持这种取法，得满足几个前提。其一，关键帧间隔不能拉得太大，假如整段视频只在开头有一个关键帧，拖到中段时播放器找不到可解码的切入点，只能往回跳。其二，moov原子的位置很关键，MP4的索引信息如果被写在文件尾部，播放器就得先下完整个文件才能知道时长和关键帧分布，表现出来就是进度条画得出来、却拖不动。其三，封装和编码也有影响，一些老编码或特殊封装虽然能播，但分片寻址的支持比较差。核对办法不复杂：拿本地播放器打开同一个文件，本地拖动顺畅，基本可以把文件因素排除；本地也拖不动，那就先转码再传。
第二层，检查服务器怎么响应。 拖动的时候，浏览器会发出带Range头的请求，服务器应当回206状态码，并带上Accept-Ranges和Content-Range。要是服务器不管怎样都返回200和整个文件，播放器拿不到分段数据，进度条自然失灵。验证方式是打开浏览器开发者工具的网络面板，拖动进度条，盯住那条视频请求的状态码和响应头。看到的是200而不是206，或者压根没有Accept-Ranges，就要去查Web服务器是不是把范围请求支持关掉了。
第三层，检查中间层。 CDN或反向代理如果缓存了完整响应，或者没把Range头透传给源站，前端的拖动请求就会被塞回一整段缓存内容。典型表现是首次播放正常、一拖就出问题，或者不同地区表现不一样。核对时可以拿源站直连地址和加速域名的响应头做对比，重点看两边是不是都返回206、Content-Range有没有跟着请求区间变化。涉及具体平台配置时，以对应服务商的官方文档为准。
第四层，检查前端播放器。 播放器如果没有启用分片加载，或者预加载策略把整个文件一次性拉完，也会出现时长显示错误、拖动无效。要确认播放器有没有开启流式加载选项，有没有误设强制预加载，以及时长是从文件元数据读出来的还是估算出来的。
可执行的排查顺序是：先用本地播放器验证文件，再用开发者工具看状态码与响应头，接着对比源站与加速域名，最后检查播放器配置。每层只改一个变量再复测，避免多个改动互相掩盖。it数运在处理这类网站维护问题时，通常也按这个由文件到服务端、再到中间层和前端的顺序推进，把每一层的证据留清楚，问题定位会稳定很多。
