nginx proxy_cache需精细配置才能高效工作：先定义proxy_cache_path指定缓存路径与内存区，再在location中启用proxy_cache并设置proxy_cache_valid、proxy_cache_use_stale等策略，通过proxy_cache_key定制键、proxy_no_cache/proxy_cache_bypass控制绕过逻辑，最后用x-cache-status头验证命中状态。
Nginx 的 proxy_cache 是一个高效、可控的反向代理缓存机制，能显著降低后端压力并提升响应速度。关键不在于开启缓存，而在于合理配置缓存路径、策略和失效逻辑。
配置缓存区域（proxy_cache_path）
缓存必须先定义共享内存区域和磁盘存储路径，这是所有缓存行为的基础。
-
语法示例：
proxy_cache_path /var/cache/nginx/proxy levels=1:2 keys_zone=my_cache:10m max_size=1g inactive=60m use_temp_path=off; -
keys_zone指定内存中缓存键的索引区大小（如my_cache:10m），影响并发查缓存性能 -
max_size控制磁盘缓存总容量，超出时 Nginx 会按inactive时间自动清理未被访问的缓存项 -
use_temp_path=off推荐关闭，避免临时文件写入再重命名带来的额外 I/O
在 location 中启用缓存（proxy_cache）
仅声明缓存区域还不够，需在具体代理位置块中显式启用，并控制缓存行为。
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 添加
proxy_cache my_cache;指向前面定义的keys_zone名称 - 用
proxy_cache_valid设置不同状态码的缓存时间，例如：proxy_cache_valid 200 302 10m; proxy_cache_valid 404 1m; - 默认只缓存 GET/HEAD 请求；如需缓存 POST，需配合
proxy_cache_methods POST;（慎用，注意幂等性） - 建议加上
proxy_cache_use_stale updating;，允许在后台更新缓存时仍返回旧内容，避免“缓存雪崩”式卡顿
控制缓存键与绕过逻辑（proxy_cache_key & proxy_no_cache）
缓存是否生效，取决于请求是否生成相同 key；而是否应缓存，则由业务规则决定。
-
proxy_cache_key默认是$scheme$proxy_host$request_uri，常需补充 Cookie 或 Header 区分用户态，例如：proxy_cache_key "$scheme$proxy_host$request_uri $cookie_user_id"; -
proxy_no_cache和proxy_cache_bypass可基于变量跳过缓存，比如：proxy_no_cache $arg_nocache $cookie_admin;，当 URL 带?nocache=1或用户带 admin cookie 时，不读也不存缓存 - 注意两者区别：
proxy_no_cache影响缓存存储，proxy_cache_bypass影响缓存读取（但依然可能存）
验证与调试缓存命中情况
上线前务必确认缓存是否按预期工作，Nginx 提供了简单可靠的响应头标识。
- 在响应中添加
add_header X-Cache-Status $upstream_cache_status;，可看到HIT、MISS、EXPIRED、BYPASS等状态 - 检查日志：在
log_format中加入$upstream_cache_status字段，便于统计命中率 - 缓存文件实际存储在
proxy_cache_path指定目录下，文件名由 MD5(key) 生成，不建议手动操作，但可用于排查磁盘占用
缓存不是开箱即用的开关，而是需要结合业务语义精细调控的机制。从路径定义、键设计到失效策略，每一步都影响稳定性与一致性。不复杂但容易忽略细节。
