206状态码是HTTP协议中表示“部分内容已成功返回”的正常响应，核心在于服务端是否规范支持范围请求：必须返回Accept-Ranges: bytes、每响应含匹配实际字节数的Content-Range与Content-Length，且中间层（Nginx/CDN/后端）需透传并正确处理Range头，否则易引发CONTENT_LENGTH_MISMATCH等异常。
206 状态码本身不是错误，而是 HTTP 协议中表示“部分内容已成功返回”的正常响应。真正需要排查的，是它背后是否隐含配置缺陷、服务异常或客户端行为异常——尤其当用户遇到下载中断、播放卡顿、内容长度不匹配（如 net::ERR_CONTENT_LENGTH_MISMATCH）时。
看响应头是否真正支持断点续传
仅出现 206 不代表断点续传可用。关键要看响应头是否规范：
-
必须有
Accept-Ranges: bytes—— 这是客户端决定是否发起 Range 请求的前提；没有它，浏览器会直接发全量请求（200），即使你手动加了 Range 头也无效 -
每次 206 响应都应带
Content-Range，格式如bytes 0-1023/10485760，且数值要与实际返回字节数、文件总大小严格一致 - 若响应是
multipart/byteranges类型（多段并行下载），每一段都需独立含Content-Range，且Content-Length必须匹配该段真实长度
查服务器是否真的处理了 Range 请求
很多问题出在中间层“吞掉”或“改写”了 Range 行为：
- Nginx / CDN 未透传
Range和If-Range请求头，或缓存策略强制回源但丢弃了 Range - 后端是 Java（Tomcat）、PHP 或 Node.js 动态服务，但代码未解析
Range头，也未设置Accept-Ranges和Content-Range，只是简单返回 200 的完整文件 - 启用了 gzip 压缩（
mod_deflate或gzip on），旧版 Apache/Nginx 可能对 206 响应错误压缩，导致 Content-Length 与解压后数据不一致
验客户端请求是否合法且被正确路由
206 出现但不可靠，常因请求本身有问题：
- Range 值越界（如
bytes=1000000000-超过文件大小），部分服务会静默退化为 200，不报错也不提示 - 同一资源被多个标签页/下载器并发请求，不同 Range 重叠或冲突，引发代理层缓冲混乱（Nginx 的
proxy_buffer溢出就可能触发upstream sent too big header） - 浏览器或播放器首次请求未带 Range，拿到 200 后才发起带 Range 的续传；若首响没返回
Accept-Ranges: bytes，后续 Range 请求可能被忽略
盯日志和临时路径的实际表现
不要只信状态码，要结合底层行为验证：
- 检查 Nginx
error.log：出现No space left on device（磁盘满，/var/lib/nginx/proxy_temp写失败）、Permission denied（临时目录无写权限）、upstream sent too big header（缓冲区太小）都是 206 异常的典型诱因 - 用
curl -v -H "Range: bytes=0-999" https://yoursite/file.mp4直接测，观察是否返回 206 + 正确头部；再用curl -I看首响有没有Accept-Ranges - 对比相同 URL 的多次请求：如果连续几个 206 的
Content-Range是跳跃、重复或不连续（如 0–1023、0–1023、2048–3071），说明服务端未正确维护偏移逻辑
