要让多个 server 或 location 共享同一份缓存，关键是统一 keys_zone 名称和 proxy_cache_key 构造逻辑；否则仅共享存储会导致碎片化缓存。需在 http 块定义全局 proxy_cache_path，用 map 剥离干扰参数、归一化 host 和语言头，并通过日志与响应头验证 key 是否真正收敛。
要让多个 server 或 location 共享同一份缓存，关键不是“复制配置”，而是统一 keys_zone 名称 + 一致的 proxy_cache_key 构造逻辑。共享本身很简单，但命中率提升取决于键是否真正收敛——否则只是把碎片化缓存从多个区搬进一个区。
一、定义全局缓存区（必须在 http 块）
所有共享缓存的配置起点只有一个：在 http{} 块中声明 proxy_cache_path，且 keys_zone 名称需唯一、可被所有 location 引用。
-
/var/cache/nginx/global需手动创建，并确保 nginx 工作用户（如www-data）有读写权限 -
levels=1:2保持两级子目录结构，避免单目录文件膨胀 -
keys_zone=global_cache:128m—— 128MB 内存可支撑约百万级 key，静态资源多时建议不低于 64m -
max_size=50g inactive=2h use_temp_path=off：磁盘上限按业务预估，inactive设为 2 小时利于及时清理冷数据，use_temp_path=off减少 IO 开销
二、跨 server/location 复用同一缓存区
只要 proxy_cache 指令值与 keys_zone 名称完全一致，Nginx 就自动共享该内存索引和磁盘存储。无需额外同步或代理协调。
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 不同域名（
site-a.com和site-b.com）可共用global_cache，但proxy_cache_key中必须保留$host，否则响应会相互覆盖 - 同域名下多个 path（如
/api/和/static/）可共享，前提是它们的 key 构造逻辑一致、不引入高变字段（如$cookie_session、$http_user_agent） - 若某 location 需个性化缓存（如登录态页面），应单独定义
keys_zone=user_cache，避免污染全局区
三、键一致才是共享有效的前提
共享空间 ≠ 自动提升命中率。若两个请求本应返回相同内容，却因 key 不同被存成两份，那再大的缓存区也白搭。
- 剔除干扰参数：用
map提前提取白名单 query（如lang、id），过滤utm_*、fbclid、v=等纯客户端参数 - 归一化 Host：统一转小写，
${host,,}（Nginx ≥ 1.11.8） - 语言头精简：只取
Accept-Language的主语言码（zh而非zh-CN;q=0.9），用map提前处理 - 示例 key：
proxy_cache_key "${scheme}${host,,}$uri|$cache_lang|$cache_args";
四、验证是否真共享 & 真收敛
上线后不能只看“有没有 HIT”，而要看“谁和谁 HIT 了”。重点验证两类一致性：
- 相同业务语义的请求（如带 / 不带 utm 参数、大小写不同的 host）是否生成完全相同的
$cache_key？可通过日志log_format cache_log '$cache_status $request_uri $cache_key';抽样比对 - 多个 server 块发起的同类请求（如
api.example.com/v1/users和www.example.com/api/v1/users），若 key 中含$host，则必然分离；若想合并，需统一 host 值或改用$server_name等逻辑标识 - 观察
X-Cache-Status响应头和边缘节点命中率趋势，优化后 48 小时内 HIT 率应明显上升，MISS 请求的 URI 分布应更集中
