Nginx 通过 ngx_http_slice_module 实现大文件分片回源与缓存，需配置 slice 指令、proxy_cache_key 含 $slice_range、支持 206 响应及 Content-Range 头透传。
直接支持视频分片下载，Nginx 本身不处理客户端上传分片，但能完美响应 Range 请求并转发/缓存分片响应——关键不在“分片上传”，而在“分片拉取 + 断点续传 + 缓存加速”。
确认 Nginx 版本并启用 sendfile 和 range 支持
Nginx 1.9.8+ 默认内置 ngx_http_slice_module，且原生支持 Range 头解析和 206 Partial Content 响应。但若关闭了 sendfile 或禁用了范围请求，浏览器会退化为整文件 200 响应，失去分片能力。
- 检查配置中是否含
sendfile on;（必须开启，否则内核零拷贝失效，大文件吞吐骤降） - 确保没写
disable_symlinks on;或其他干扰静态文件读取的指令 -
etag off;不推荐关，但若源站动态生成内容且 ETag 不稳定，可能导致Range请求被拒绝（Nginx 检查 ETag 一致性后才返回206） - 用
curl -I -H "Range: bytes=0-1023" https://yoursite.com/video.mp4验证响应头是否含Accept-Ranges: bytes和状态码206
配置 slice 模块实现回源分片缓存（适用于 CDN 边缘或反向代理场景）
当视频文件存在远端源站（如对象存储、私有源站），且单次拉取耗时长、带宽压力大时，slice 是核心优化手段：它把一个大响应体切成固定大小子请求并发回源，再拼装返回，避免单连接卡死、提升缓存命中率。
-
slice必须配合proxy_cache使用，单独在location中写slice 1m;不生效 -
proxy_cache_key必须包含$slice_range，否则所有分片都写进同一个缓存 key，后继请求永远只拿到第一片 - 需显式透传
Content-Range和Accept-Ranges头，Nginx 不自动继承上游响应头：proxy_hide_header Content-Range; add_header Accept-Ranges bytes; add_header Content-Range $sent_http_content_range;
- 缓存路径
proxy_cache_path的inactive时间建议 ≥ 24h，防止分片缓存被提前清理导致重复回源
调优超时与缓冲参数防止大文件传输中断
视频下载常因超时被切断，尤其在弱网或高延迟链路下。问题往往不出在客户端，而在于 Nginx 与后端（源站）之间的连接维持策略。
-
proxy_read_timeout 300;（非默认 60s）：控制 Nginx 等待后端响应数据的时间，大文件流式回源必须加长 -
proxy_send_timeout 300;：控制 Nginx 向客户端发送响应的超时，避免 TCP Keepalive 探测失败后连接静默断开 -
client_body_buffer_size 128k;和proxy_buffer_size 128k;：避免小缓冲区触发频繁磁盘临时文件写入（proxy_max_temp_file_size应设为0或足够大） - 若走 HTTPS 回源，还需确认
ssl_buffer_size不过小（默认 4k 可能加剧 TLS 分片延迟）
防盗链与限速要避开 Range 请求误伤
加了 valid_referers 或 limit_rate 后，部分视频播放器（如 hls.js、dash.js）发起的分片请求可能被拦截或限速过严，导致加载卡顿。
- 防盗链规则中，
if ($invalid_referer) { return 403; }会拦截所有Range请求——应在location块中用valid_referers+set $allow 1;显式放行，而非全局拦截 -
limit_rate对每个连接生效，但分片下载常建多个连接（如 6 个Range并发），总速率可能远超预期；改用limit_rate_after 5m;更合理：前 5MB 不限速，后续限速，兼顾首屏体验与带宽控制 - 避免在
if块中使用limit_rate，Nginx 官方明确不推荐，易引发未定义行为
真正难的不是配出 206，而是让每一片都稳定落入缓存、每次续传都命中本地、每个并发请求都不互相干扰——这些细节藏在 proxy_cache_key 构造、slice_range 变量作用域、以及 Content-Range 头是否被意外过滤里。
