通过map指令动态控制proxy_cache开关,依据租户id、路径前缀、响应类型、http方法等请求特征实时计算缓存策略,实现多业务线共用配置下的精细化缓存管理。

用 map 指令动态控制 proxy_cache 开启策略,核心是把“缓存是否生效”变成一个可计算的布尔值,再通过 proxy_cache_bypass 和 proxy_no_cache 联动实现按需开关。它不靠硬写多个 location 分离逻辑,而是根据真实请求特征实时决策,适合多业务线共用一套反向代理配置的场景。
按业务身份区分缓存启用状态
不同业务线常对应不同用户角色或访问来源。例如:运营后台接口需强一致性,而商品页对未登录用户可缓存;SaaS 平台中免费版用户响应不缓存,付费版允许缓存。
- 利用 Cookie 或请求头识别业务归属:map $cookie_tenant_id $cache_enabled { "" 0; # 无租户 ID → 禁用 "tenant_a" 1; "tenant_b" 1; default 0; }
- 在 location 中绑定:proxy_cache_bypass $cache_enabled; proxy_no_cache $cache_enabled; ——当值为 1 时跳过缓存且禁止存储,彻底隔离该业务线
- 配合 proxy_cache_key 加入租户标识(如 $cookie_tenant_id$request_uri),避免跨业务线缓存污染
按请求路径前缀划分业务缓存域
各业务线通常有固定路径前缀,如 /shop/、/pay/、/report/,可据此做粗粒度开关。
安全更新和维护 CLI Proxy API(CPA)部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
- 定义路径映射:map $request_uri $bypass_by_path { "~*^/report/" 1; "~*^/pay/webhook" 1; "~*^/shop/api/v2/" 0; default 0; }
- 注意正则以
^开头防止误匹配(如/report_data不触发);大小写忽略用~* - 若某业务线需完全禁用缓存,直接设为 1;若需启用,则保持 0,并配合独立 proxy_cache 区域提升隔离性
按响应内容类型决定是否纳入缓存
同一业务线内,不同响应类型对缓存要求差异大:HTML 页面可缓存,JSON 接口一般不可缓存,图片资源又需长期缓存。
- 先确保能读取上游响应头:proxy_buffering on; proxy_pass_request_headers on;
- 映射响应类型:map $upstream_http_content_type $no_cache_for_json { "~*application/json" 1; "~*image/.*" 0; default 0; }
- 应用到 location:proxy_cache_bypass $no_cache_for_json; proxy_no_cache $no_cache_for_json; ——JSON 响应强制绕过并拒绝落盘
- 配合 proxy_cache_valid 多行声明(如 200 302 5m; 404 1m;),让非 JSON 类型仍走常规 TTL 规则
按 HTTP 方法实现读写分离式缓存
GET/HEAD 请求天然幂等,适合缓存;POST/PUT/DELETE 通常改变状态,应默认禁用缓存,但部分业务线存在“只读 POST”(如带 body 的查询接口),可单独放开。
- 方法级映射:map $request_method $cache_allowed { GET 1; HEAD 1; POST 0; default 0; }
- 进阶用法:结合请求体构造 key,仅对特定 POST 允许缓存:map $request_method $cache_key_post { GET "$scheme$host$request_uri"; POST "$scheme$host$request_uri$request_body"; default "$scheme$host$request_uri"; }
- 搭配使用:proxy_cache_key $cache_key_post; proxy_cache_bypass $cache_allowed; proxy_no_cache $cache_allowed;










