nginx proxy_cache在微服务网关中需精准控制缓存范围，仅缓存纯只读get、低频更新、无用户身份依赖、高耗时的四类接口；配置独立缓存区、按路径启用、忽略干扰响应头、启用缓存锁，并谨慎支持幂等post。
在微服务网关中用 Nginx proxy_cache 做响应缓存，核心是“精准控制、安全隔离、稳定兜底”，不是简单加几行配置就完事。重点在于只缓存真正适合的接口，避免污染、误命中或泄露敏感数据。
明确哪些接口该缓存
不是所有微服务接口都适合缓存，优先选这四类：
- 纯只读 GET 请求（如
/api/v1/products、/api/v1/config），无下单、扣库存等副作用 - 内容更新频率低（如城市列表每小时一更、字典项每天同步一次）
- 不依赖用户身份：响应不随
Authorization、Cookie或X-User-ID变化；若必须区分，需显式写入proxy_cache_key - 后端耗时明显（单次响应 >200ms），尤其是涉及多库 JOIN、远程调用或聚合计算的接口
定义独立缓存区与基础参数
在 http 块中声明专用缓存区，避免和静态资源或其他代理共用：
proxy_cache_path /var/cache/nginx/gw_cache levels=1:2 keys_zone=gw_cache:100m max_size=5g inactive=10m use_temp_path=off;
关键点：
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
-
use_temp_path=off：跳过临时文件拷贝，减少 I/O 延迟 -
inactive=10m：10 分钟内未被访问的缓存自动清理，防磁盘占满 -
keys_zone=...:100m：100MB 共享内存足够支撑数万活跃 key
按路径精细启用缓存
不要在 location / 下全局开启，而是匹配具体 API 路径：
location ^~ /api/v1/public/ {
proxy_pass http://public_service;
proxy_cache gw_cache;
proxy_cache_valid 200 302 5m;
proxy_cache_valid 404 1m;
proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
proxy_cache_lock on;
proxy_cache_lock_timeout 3s;
proxy_ignore_headers Cache-Control Expires Set-Cookie;
proxy_cache_key "$scheme$host$request_uri";
add_header X-Cache-Status $upstream_cache_status;
}
说明：
-
proxy_cache_key去掉$request_body和动态 header，因这是公开只读接口，URI 已唯一标识内容 -
proxy_ignore_headers忽略后端误设的Cache-Control: no-cache或Set-Cookie，防止缓存被跳过 -
proxy_cache_lock防止高并发下相同请求多次穿透回源（即“缓存雪崩”）
特殊场景：需缓存 POST 查询类接口
例如 GraphQL 查询或复杂搜索表单（幂等、无副作用、无用户私有数据），可谨慎开启：
- 显式允许方法：
proxy_cache_methods GET HEAD POST;（必须含 GET/HEAD） - 自定义 key，避免体内容相同但缓存混乱：
proxy_cache_key "$scheme$host$request_uri$args$sha1($request_body)";（需确保proxy_buffering on且client_max_body_size合理） - 强制支持状态码：
proxy_cache_valid 200 201 30s;（默认不缓存 POST 的 200） - 更推荐做法：让前端改用 GET + query string，语义清晰、Nginx 原生友好、调试直观
