要让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 并缓存这些细粒度响应
