核心是分层配置：先在http块定义缓存区，再在location块中调用并控制缓存行为；需确保proxy_cache_path的keys_zone名、proxy_cache引用名、proxy_cache_key规则三者严格对齐，配合proxy_pass构成完整代理缓存链路。
要让 proxy_cache 和 proxy_pass 协同工作，核心是分层配置：先在 http 块定义缓存区，再在 location 块中调用并控制缓存行为。它不是加几行就能生效的开关，而是需要路径、键、策略三者对齐的体系。
定义缓存存储与内存区（http 块）
这是整个缓存体系的地基，必须放在 nginx.conf 的 http {} 作用域内：
-
proxy_cache_path 指定磁盘位置、目录结构、内存标识和清理规则。例如：
proxy_cache_path /data/nginx/cache levels=1:2 keys_zone=STATIC_CACHE:50m inactive=1d max_size=20g;
其中STATIC_CACHE是唯一标识名，后续 location 中必须严格一致；levels=1:2表示两级哈希子目录，避免单目录文件过多；inactive=1d表示 1 天未被访问就自动淘汰。 - 同时建议配好临时目录，防止缓存写入失败：
proxy_temp_path /data/nginx/proxy_temp;
在 location 中启用并精细控制缓存（server 或 location 块）
仅定义不调用等于没配。关键指令需出现在具体转发路径中：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- proxy_cache STATIC_CACHE —— 名称必须与 proxy_cache_path 中 keys_zone 的值完全匹配；
-
proxy_cache_key 决定“什么请求算同一个缓存项”。默认值较粗糙，推荐显式定义，例如：
proxy_cache_key "$scheme$host$request_uri";
若需区分登录态或设备类型，可加入 cookie 或 header 变量，但会显著降低命中率； -
proxy_cache_valid 按响应状态码设置不同缓存时长：
proxy_cache_valid 200 301 302 1h;
proxy_cache_valid 404 1m; -
proxy_cache_use_stale 提升可用性：后端出问题时仍可返回旧缓存，例如：
proxy_cache_use_stale error timeout updating http_502 http_503;
配合 proxy_pass 完成完整代理链路
proxy_pass 是流量出口，proxy_cache 是流量入口的“快车道”，二者共存于同一 location：
- 确保 proxy_pass 指向的是 upstream 或具体地址，且不能以
/结尾（除非后端路径逻辑要求）； - 常见错误：在启用缓存的 location 中漏掉
proxy_set_header，导致后端无法识别真实客户端信息；应至少保留：
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; - 可添加调试头，方便验证是否命中缓存：
add_header X-Cache-Status $upstream_cache_status;
返回值为HIT、MISs或BYPASS，便于排查。
验证与维护要点
配置生效后，不能只看 reload 是否成功，还要确认实际行为：
- 首次访问返回
X-Cache-Status: MISS，第二次相同请求应为HIT； - 检查缓存目录是否存在真实文件：
ls -lh /data/nginx/cache/??/??/（因 levels=1:2，实际路径类似c/7f/...）； - 如需手动清理某 URL 缓存，需借助第三方模块
ngx_cache_purge，原生 Nginx 不支持按 URL 删除； - 注意缓存不会自动继承后端的
Cache-Control或Expires头，除非显式配置proxy_ignore_headers并启用proxy_cache_valid覆盖。
