proxy_cache_max_range_offset 限制可缓存的range请求起始偏移，仅缓存偏移≤设定值（如5m）的前段range，后段range直接透传；需配合含$http_range的cache_key、合理max_size/inactive及短时效206缓存策略。

proxy_cache_max_range_offset 本身不直接支持大文件缓存，而是限制哪些 Range 请求能被缓存，目的是防止大文件尾部随机 Range 导致缓存失控。

它不是“让大文件更好缓存”的开关，而是“给 Range 缓存划一条安全边界”的控制阀。

---

它怎么影响大文件缓存？

• ✅ 前段 Range 可缓存：比如设为 2m，那么 bytes=0-1023、bytes=1m-2m 这类起始偏移 ≤ 2MB 的请求，只要满足其他缓存条件（如状态码、proxy_cache_valid），就会被正常缓存。
• ❌ 后段 Range 被跳过缓存：如 bytes=9G-（一个 10GB 视频的末尾 1MB），Nginx 直接透传给上游，不建缓存条目，避免生成大量低价值碎片。

这本质上是用空间换稳定：牺牲极靠后 Range 的缓存能力，换来缓存目录结构整洁、元数据可控、磁盘不被无效条目撑爆。

FastAPI Flask Proxy

FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。

下载

---

想真正高效缓存大文件，需配合这些

• 启用 proxy_cache_key 包含 $http_range
  否则不同 Range 会共用同一缓存键，导致拖拽播放返回错误字节段。
  示例：

  proxy_cache_key "$scheme$request_method$host$request_uri$http_range";

• 合理设置 proxy_cache_path 的 max_size 和 inactive
  大文件缓存占用空间大，需预留足够磁盘并及时清理不活跃项：

  proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:100m max_size=50g inactive=1h;

• 关闭对 206 响应的长时缓存
  206 Partial Content 本身是动态片段，不宜缓存太久：

  proxy_cache_valid 200 206 302 10m;  # 206 也只缓 10 分钟

• 必要时禁用 Range 缓存，改由源站处理
  若后端已优化 Range 响应（如支持 Accept-Ranges: bytes + 快速定位），可完全绕过 Nginx 的 Range 缓存逻辑：

  proxy_cache_bypass $http_range;
  proxy_no_cache $http_range;
  proxy_force_ranges off;

---

实际配置参考（兼顾大文件与稳定性）

proxy_cache_path /var/cache/nginx/range_cache 
  levels=1:2 
  keys_zone=range_cache:50m 
  max_size=30g 
  inactive=30m;

server {
  location ~ \.(mp4|mkv|avi)$ {
    proxy_cache range_cache;
    proxy_cache_valid 200 206 10m;
    proxy_cache_key "$scheme$request_method$host$request_uri$http_range";

    proxy_cache_max_range_offset 5m;  # 只缓前 5MB 内的 Range 片段

    # 其他代理参数...
    proxy_pass http://backend;
    proxy_buffering on;
  }
}

这样既保留了首屏加载、快进前几秒等高频 Range 的缓存收益，又避免了用户拖到视频末尾时引发的缓存雪崩。