要让静态资源断点续传稳定高效，关键在于确保Range请求在传输链路中被准确识别、透传、分片和响应；需检查代理/CDN是否透传Range头、WAF是否过滤非法格式、Nginx是否正确解析$http_range、缓存key是否包含Range、避免sendfile等配置干扰，并优化分片大小与并发数。
要让静态资源断点续传真正稳定高效，不能只看“有没有 206 响应”，得从客户端发来的 Range 字段入手，逐层分析它在传输链路中是否被准确识别、透传、分片和响应。关键不在“开启功能”，而在确保每个环节对 Range 的处理逻辑一致、无损耗、无歧义。
检查 Range 请求是否被完整接收并解析
Nginx 或其他服务器必须能正确提取并赋值 $http_range 变量。常见干扰包括：
- 前端代理或 CDN（如 Cloudflare 免费版）默认剥离 Range 头，需确认其设置中启用 “Pass through Range requests” 或关闭“Always Online”等干扰行为
- 某些 WAF 或安全网关会过滤非常规格式的 Range（如含空格、多范围逗号分隔、超长数值），建议用标准格式
bytes=1024-2047测试 - 若请求中 Range 值为空或非法（如
bytes=-、bytes=abc-），Nginx 默认不报错但会忽略该头，导致降级为 200 响应——可用log_format记录$http_range值验证
优化 Range 分片策略与并发控制
客户端一次性发多个 Range（如 bytes=0-999,1000-1999）虽合法，但多数服务端（包括 Nginx 静态服务）不支持多段合并响应，仅取第一个范围处理；而并发多个单 Range 请求又易触发限流。更优做法是：
- 客户端按固定块大小切分（如 1MB/段），避免小碎片（8MB），兼顾 TCP 效率与内存占用
- 限制并发请求数 ≤ 4，防止连接耗尽或后端拒绝（尤其 Node.js 或 Golang 服务未做连接池管理时）
- 对 MP4/WEBM 等视频文件，确保已用
ffmpeg -i in.mp4 -c copy -movflags +faststart out.mp4移动 moov box 至头部，否则首段 Range 请求可能因元数据位置靠后而延迟返回
校验缓存键是否真实区分不同 Range
启用 proxy_cache 时，若 cache_key 不含 $http_range，所有 Range 请求都会命中同一缓存条目，造成“断点失效”。必须显式构造带 Range 的 key：
- 推荐写法：
proxy_cache_key "$uri|$http_range";—— 简洁、可读、自动兼容空值（全量请求时$http_range为空，key 变为/file.zip|，与/file.zip|bytes=0-1023互不冲突） - 务必配
proxy_cache_valid 206 1h;，否则 Nginx 默认不缓存 206 响应，每次请求都穿透到后端 - 若使用 CDN，需确认其缓存策略是否支持基于 Range 头的差异化缓存（部分 CDN 仅支持 query 参数维度）
规避 sendfile、gzip 和 max_ranges 的隐性干扰
这些看似无关的配置，实际会直接破坏 Range 行为：
-
sendfile on;在 Linux 低内核（如 3.10 以下）或小文件（off -
gzip on;对 Range 请求压缩会导致Content-Length与Content-Range不匹配，必须加gzip_disable "range"; -
max_ranges 0;是硬性关闭开关，务必删除或设为合理值（如max_ranges 10;），否则任何 Range 请求都返回 416
