Nginx proxy_cache生效需四层协同：一、http块预定义proxy_cache_path；二、location中配置proxy_cache、proxy_cache_key、proxy_cache_valid等指令；三、与proxy_pass及必要header配合；四、通过X-Cache-Status验证命中。缺一不可。
要让 proxy_cache 真正生效，实现反向代理内容的本地缓存，不能只在 location 里加一行 proxy_cache cache_one。它是一套必须前后对齐、分层协作的机制——缓存区得先建好，键值得定清楚，策略得配到位，否则 Nginx 会默默跳过缓存，每次仍直连后端。
一、必须在 http 块预定义缓存区
这是整个缓存体系的地基，缺了就完全不工作：
-
路径要存在且权限正确：比如用
/www/server/nginx/proxy_cache，执行mkdir -p /www/server/nginx/proxy_cache && chown www:www /www/server/nginx/proxy_cache -
proxy_cache_path 必须写在 nginx.conf 的
http { }块内，通常放在include mime.types;上方，例如：proxy_cache_path /www/server/nginx/proxy_cache levels=1:2 keys_zone=cache_one:10m inactive=30m max_size=1g use_temp_path=off; - keys_zone 名称（如
cache_one）必须和 location 中proxy_cache引用的名称严格一致
二、在 location 中绑定并控制缓存行为
仅定义不调用等于没配。以下指令需出现在含 proxy_pass 的 location 块中（紧贴 proxy_pass 下方）：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
-
proxy_cache cache_one;—— 绑定上一步声明的缓存区 -
proxy_cache_valid 200 301 302 1h;—— 成功响应缓存 1 小时；proxy_cache_valid 404 1m;避免反复探测 -
proxy_cache_key "$scheme$host$request_uri";—— 排除 Cookie、User-Agent 干扰，提升命中率；如需区分移动端，可用map提取简标后拼入，不建议直接用完整$http_user_agent -
proxy_cache_use_stale error timeout updating http_500-504;—— 后端出问题时仍可返回旧缓存，保障可用性 -
proxy_cache_lock on;和proxy_cache_lock_timeout 5s;—— 防止缓存失效瞬间大量并发回源压垮后端
三、配合 proxy_pass 构成完整链路
proxy_pass 是出口，proxy_cache 是入口快车道，二者共存于同一 location 才有意义：
-
proxy_pass地址不要以/结尾（除非后端路径逻辑要求），避免路径替换异常 - 务必补全关键请求头，否则后端可能无法识别真实客户端：
proxy_set_header Host $host;proxy_set_header X-Real-IP $remote_addr;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;proxy_http_version 1.1;proxy_set_header Connection ""; - 加一句
add_header X-Cache-Status $upstream_cache_status;，方便用curl -I验证是否命中缓存（返回HIT、MISS或BYPASS）
四、验证与运维要点
上线前别跳过这步：
- 重载配置：
nginx -t && systemctl reload nginx或宝塔面板【重载配置】 - 用
curl -I https://your-domain.com/path查看响应头中X-Cache-Status字段 - 检查缓存目录是否生成文件：
ls /www/server/nginx/proxy_cache/（正常会有哈希子目录） - 如需主动清理，可配置
proxy_cache_purge模块或使用第三方 purge 接口
