proxy_cache_max_range_offset 用于限制nginx对range请求缓存的起始偏移量，仅当range起始字节≤该值时才允许从缓存截取响应，防止远端偏移导致重复回源；推荐视频服务设50m～200m、文档设10m～50m，并需配合proxy_cache_valid设置206状态码缓存及后端返回accept-ranges头。
proxy_cache_max_range_offset 是 Nginx 缓存模块中一个容易被忽略但对分块下载（Range 请求）缓存行为有关键影响的指令。它不控制是否启用 Range 缓存，而是决定：当客户端发起 Range 请求（比如视频拖动、大文件断点续传）时，Nginx 最多允许从已缓存的完整响应中截取多大偏移范围的数据返回——超出该偏移，Nginx 就会绕过缓存，直接回源。
它解决什么问题？
默认情况下，Nginx 对 Range 请求的缓存支持是“保守”的：只有当请求的 Range 落在已缓存的完整响应开头附近（例如 bytes=0-1023），且缓存体足够大时，才复用缓存；如果请求的是远端偏移（如 bytes=9999999-10000999），而缓存尚未完整保存整个响应，Nginx 会放弃使用缓存，直接向后端发起新的 Range 请求——这导致重复回源、带宽浪费、后端压力上升。
proxy_cache_max_range_offset 就是用来放宽这个限制：告诉 Nginx，“只要缓存里已有目标 Range 起始位置往前最多 N 字节的数据，就允许从中截取并返回”，从而提升 Range 请求命中缓存的概率。
怎么设置才合理？
该值需结合业务场景权衡：
aperture: the L402 aware reverse proxy
下载
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
- 设得太小（如默认 0 或 1MB）：大部分远端 Range 请求无法复用缓存，失去分块缓存意义
- 设得太大（如 500MB）：可能让 Nginx 为单个大文件缓存过多前置数据，占用磁盘且利用率低
- 推荐起点：对视频类服务，设为 50M～200M；对文档/安装包等中等文件，10M～50M 更稳妥
示例配置：
proxy_cache_path /var/cache/nginx/video levels=1:2 keys_zone=video:10m max_size=10g inactive=24h; proxy_cache video; proxy_cache_max_range_offset 104857600; # 100MB
必须配合的其他配置
单独设置 proxy_cache_max_range_offset 不生效，需确保以下几点已启用：
- proxy_cache 已启用且对应 cache zone 存在
- proxy_cache_valid 明确设置了 200/206 响应的缓存时间（206 是 Range 成功响应的状态码）
-
proxy_ignore_headers 没有屏蔽
Accept-Ranges或Content-Range（除非你明确要忽略） - 后端响应需包含
Accept-Ranges: bytes，且对 Range 请求返回206 Partial Content
验证是否生效？
可通过日志或响应头观察：
- 开启
log_format记录$upstream_http_x_cache（需后端透传）或自定义变量$sent_http_x_cache_status，查看是否返回HIT - 用
curl -H "Range: bytes=10000000-10000999"请求，检查响应状态码是否为206，且X-Cache头为HIT - 对比相同 Range 请求在修改前后
$upstream_addr是否从后端地址变为cache或消失（表示未回源）
