要让nginx proxy_cache真正支持断点续传，必须协同配置四方面：显式透传range/if-range头、确保源站返回206响应、缓存key包含$http_range或$slice_range、明确允许proxy_cache_valid 200 206。

要让 Nginx 的 proxy_cache 既缓存大文件下载，又真正支持断点续传（即 Range 请求），不能只开缓存或只透传头，必须从请求透传、源站响应、缓存键设计、缓存策略四方面协同配置。

显式透传 Range 和 If-Range 请求头

Nginx 默认在 proxy_pass 场景下不自动转发 Range 和 If-Range 头，尤其当你设置了自定义 proxy_set_header 时，它们极易被覆盖。必须在对应 location 块中明确添加：

• proxy_set_header Range $http_range;
• proxy_set_header If-Range $http_if_range;
• 建议加上 proxy_pass_request_headers on;，避免其他关键头意外丢失

当客户端没发 Range（即全量请求）时，$http_range 为空，Nginx 不会发送空头，不影响 200 响应，安全可靠。

FastAPI Flask Proxy

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

下载

确保源站正确返回 206 Partial Content

如果后端（如 OSS、S3、另一台 Nginx 或静态服务）对 Range: bytes=100-199 返回的是 200 而非 206，断点续传就形同虚设。验证方式很简单：

• 用 curl 测试：curl -I -H "Range: bytes=0-1023" https://your-domain.com/file.zip
• 必须看到 HTTP/1.1 206 Partial Content 和 Content-Range: bytes 0-1023/1234567
• 常见失败原因：源站禁用了 range 支持（如 Nginx 中 disable_symlinks 或 satisfy any 拦截）、文件权限不足、或路径被重写逻辑跳过

缓存 key 必须区分 Range 范围

若所有 Range 请求共用同一个缓存 key（比如仅用 $uri），会导致“用第一个分片覆盖全部请求”，返回错位内容。正确做法是将请求范围纳入 key：

• 基础方案：proxy_cache_key "$scheme$request_method$host$request_uri$http_range";
• 更健壮方案（推荐）：proxy_cache_key "$uri$is_args$args$slice_range";（需启用 slice 模块）
• 切忌使用不含 $http_range 的 key，否则缓存污染风险极高

合理设置缓存有效期与状态码支持

只缓存 200 是不够的——206 响应也必须可缓存，且需控制其生命周期：

• 明确允许缓存 206：proxy_cache_valid 200 206 1h;
• 避免全局强缓存干扰：不要给响应加 Cache-Control: public, max-age=31536000，否则 CDN 可能直接返回旧的 200 全量缓存，绕过 Range 逻辑
• 如需支持尾部大偏移 Range（如视频拖到末尾），可调大 proxy_cache_max_range_offset 5m;，但注意该参数仅在缓存了完整 200 响应、且需从中切片时才生效；更推荐让源站返回 206 并缓存这些细粒度响应