nginx slice模块实现超大文件分片回源与缓存需客户端、配置、后端、缓存四者协同：必须编译模块，后端支持206响应，location内配置slice及proxy_set_header range $slice_range、proxy_cache_key含$slice_range、启用http/1.1，且缓存策略须同时覆盖200/206状态。
要让 Nginx 的 slice 模块真正支撑超大文件的分片回源与边缘缓存管理，关键不是“开了模块就行”，而是整套链路协同：客户端行为、Nginx 配置、后端能力、缓存策略四者必须严丝合缝。它本质是把一次“扛整包”的压力，拆成多个可控的“小快运”，再靠缓存把高频片稳住。
确认基础能力是否就位
缺任一环节，配置再全也返回 416 或 502：
- 检查 Nginx 是否编译了模块：
nginx -V 2>&1 | grep http_slice_module，无输出需重编译加--with-http_slice_module - 后端必须响应
206 Partial Content并带Content-Range头（如bytes 0-1048575/5242880），静态服务、OSS、S3 通常支持；PHP/Node.js 接口需手动实现 Range 处理 -
slice指令只能写在location块内，http或server级配置无效 - 禁用
proxy_buffering off会直接关闭 slice 功能，必须保持开启
核心配置必须同步完成三项动作
只写 slice 1m 是没用的，以下三者缺一不可：
-
传递分片范围：用
proxy_set_header Range $slice_range;把 Nginx 自动生成的区间（如bytes=0-1048575）准确发给后端 -
区分缓存键：用
proxy_cache_key "$uri$is_args$args$slice_range";确保每个分片独立缓存；漏掉$slice_range会导致所有片覆盖同一缓存项 -
启用 HTTP/1.1 协议栈：加
proxy_http_version 1.1;和proxy_set_header Connection "";，避免连接头干扰复用，因为 Range 是 HTTP/1.1 特性
缓存策略决定实际效果上限
没有缓存，slice 只是把压力从“单次大请求”变成“多次小请求”，反而增加延迟和连接数：
- 显式声明
proxy_cache_valid 200 206 1h;，必须同时包含200（整文件）和206（分片），否则 206 响应不进缓存 - 启用
proxy_cache_lock on;，防止相同分片的并发请求穿透到后端，避免重复拉取 - 配合
proxy_cache_background_update on;可在缓存过期前后台异步刷新热片，但注意该功能与 slice 兼容性需实测（部分版本存在冲突）
客户端配合才能激活分片逻辑
Nginx 不主动预热，一切由请求驱动：
- 普通 GET（无 Range 头）：Nginx 仍会按 slice 大小发起全部子请求回源，对外返回完整 200 响应，适合后台预热
- 带 Range 的请求（如
Range: bytes=0-1048575）：Nginx 直接匹配已缓存分片返回 206，未命中才触发对应子请求 - 断点续传工具（
wget -c、aria2）、现代播放器拖动进度条，天然发送多段 Range，Nginx 自动按需拉取、独立缓存、各自失效
这套机制不合并响应体、不保证子请求顺序，客户端负责按字节范围拼接——这完全符合 HTTP/1.1 RFC 7233 标准，也是它轻量可靠的基础。
