Nginx slice模块需满足编译启用、location内配置、proxy_pass配合Range支持、客户端带Range头及HTTP/1.1等全部条件才生效，通过化整为零实现按需拉取与精细缓存，降低回源带宽峰值。
直接用 slice 模块能缓解大文件回源时的带宽峰值压力，但前提是配置得当、后端配合、缓存协同。它不是开个开关就自动生效的“银弹”，而是把一次大请求拆成多个小请求，让带宽占用更平滑、缓存更精细、失败影响更小。
slice 模块真正起作用的前提条件
模块本身不转发、不缓存、不合并——它只在满足以下全部条件时才激活分片逻辑：
- nginx 编译时已启用 --with-http_slice_module（主流发行版如 Ubuntu/Debian 的 apt 包通常默认包含，可执行
nginx -V 2>&1 | grep http_slice验证） - 配置写在 location 块内，不能放在 http 或 server 级别
- 必须搭配 proxy_pass 使用，且后端服务明确支持 Range 请求（响应头含
Accept-Ranges: bytes） - 客户端请求必须带
Range头（例如Range: bytes=0-1048575），普通 GET 不触发切片 - 不能与
proxy_buffering off共存——关闭缓冲会禁用 slice 功能
核心配置三要素缺一不可
仅写 slice 1m 是无效的。必须同步完成以下三项设置：
-
传递分片范围：用
proxy_set_header Range $slice_range;把自动生成的区间（如bytes=0-1048575）准确发给后端 -
区分缓存键：用
proxy_cache_key "$uri$is_args$args$slice_range";确保每个分片单独缓存，避免不同 Range 写入同一 cache key 导致覆盖或错乱 -
启用 HTTP/1.1：加
proxy_http_version 1.1;和proxy_set_header Connection "";，因为 Range 是 HTTP/1.1 特性，且需清除 Connection 头防止代理干扰复用
为什么能降低回源带宽瞬时压力？
关键在于“化整为零”和“按需拉取”：
- 客户端请求某一段（如视频拖动到第 50MB），Nginx 不会拉整个 2GB 文件，只按 slice 大小（如 1M）发起最少数量的子请求（如 50–51MB 这一段可能只需拉一个 slice）
- 每个子请求返回的是 206 Partial Content，体积可控（
Content-Length就是 slice 实际大小），后端无需加载全量文件到内存或磁盘 - 多个用户并发请求不同区间时，Nginx 只拉各自需要的 slice，不会重复拉取未被请求的部分，回源流量天然分散
- 配合
proxy_cache_lock on，还能防止相同 slice 的并发请求同时穿透到后端
调优建议：平衡粒度、并发与缓存效率
slice 大小不是越小越好，也不是越大越好：
- 太小（如 128k）→ 分片数暴涨，HTTP 请求头开销占比升高，后端连接数激增，易触发 TIME_WAIT 或端口耗尽
- 太大（如 10M）→ 单次回源仍占高带宽，缓存粒度变粗，局部更新或断点续传收益下降
- 推荐起步值：512k～2M，根据典型文件大小和平均请求区间调整；视频类可设 1M，软件包类可设 2M
- 务必检查后端是否稳定返回 206；若某次返回 200（全量），Nginx 会放弃分片逻辑，后续同 URL 请求可能全量回源
