nginx层缓存api响应可将200ms+接口降至5–20ms，需满足读多写少、无用户依赖、纯get、后端耗时>200ms；配置含定义缓存区、启用缓存、控制缓存行为三步；并需处理 stale、background update、cache lock 及精准 cache key。
直接在 Nginx 层缓存 API 响应，是提升响应速度最立竿见影的手段之一。它不改一行后端代码，却能让 200ms 以上的接口降到 5–20ms，同时大幅降低数据库和业务逻辑层压力。
选对能缓存的接口
不是所有 API 都适合缓存。优先考虑以下特征的接口：
- 读多写少、更新频率低（如城市列表、商品类目、配置项、用户等级规则）
- 无用户身份依赖（不依赖 Cookie 或动态 token；若需区分用户，必须把用户标识纳入缓存键）
- 纯 GET 请求，无副作用（不扣库存、不下单、不发消息）
- 后端耗时明显（实测 >200ms，尤其含多表 JOIN、远程调用或复杂计算）
基础缓存配置要到位
三步完成核心配置，缺一不可：
-
定义缓存区：在 http 块中声明磁盘路径、内存索引区和容量限制，例如：
proxy_cache_path /var/cache/nginx/api levels=1:2 keys_zone=api_cache:100m max_size=5g inactive=10m use_temp_path=off; -
启用并指定缓存：在 location 块中开启 proxy_cache，并绑定对应 zone：
proxy_cache api_cache; -
控制缓存行为：明确哪些状态码缓多久，例如：
proxy_cache_valid 200 302 5m;
proxy_cache_valid 404 1m;
proxy_ignore_headers Cache-Control Expires Set-Cookie;（强制忽略后端不合理的缓存头）
让缓存更稳更智能
光缓存不够，还要应对后端故障和数据新鲜度问题：
- 加 proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;——后端挂了，仍可返回过期但可用的数据
- 配 proxy_cache_background_update on;——过期时后台悄悄刷新，前端始终拿到有效响应
- 开 proxy_cache_lock on;——防止高并发下大量请求同时穿透到后端（缓存雪崩）
- 加 add_header X-Cache-Status $upstream_cache_status;——方便通过响应头快速判断 HIT/MISS/STALE
缓存键要精准，避免污染
默认缓存键可能把不该区分的请求拆成多个缓存条目，浪费空间又降低命中率：
- 若需统一缓存（如忽略分页参数
?page=1），用 proxy_cache_key "$scheme$request_method$host$request_uri"; - 若需按用户隔离（如
/api/user/profile），显式加入身份字段：
proxy_cache_key "$scheme$request_method$host$request_uri$http_authorization"; - 若 URL 含无意义参数（如
?utm_source=xxx&ts=123），先用 map 指令清洗再构造 key
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
