nginx中资源缓存分为客户端缓存和代理缓存两类：前者通过cache-control响应头控制浏览器缓存行为，后者由proxy_cache系列指令实现反向代理层缓存，二者作用位置、配置方式及适用场景截然不同，需严格区分并分层配置。
在 Nginx 中管理资源缓存，核心是区分两类缓存：**客户端缓存（Browser Caching）** 和 **代理缓存（Proxy Server Caching）**。二者目标一致——减少重复请求、提升响应速度、降低后端压力，但作用位置、配置方式和适用场景完全不同。用错类型或混用指令，轻则缓存失效，重则返回错误内容。
客户端缓存：控制浏览器怎么存静态资源
这是最常用也最容易配错的一层。Nginx 通过设置 Cache-Control 响应头来告诉浏览器“这个文件能存多久、谁可以存、要不要验证”。关键不是加个 expires，而是用好 Cache-Control 的组合指令：
-
带哈希指纹的资源（如
app.a1b2c3.js）：内容不变就永远不变，可设为长期不可变缓存add_header Cache-Control "public, max-age=31536000, immutable" always; -
普通静态资源（如未带哈希的
style.css）：更新较频繁，建议 30 天并允许验证add_header Cache-Control "public, max-age=2592000, must-revalidate" always; -
HTML 文件（尤其是 SPA 入口）：骨架常变，禁止 CDN 缓存，每次使用前必须校验
add_header Cache-Control "private, no-cache, must-revalidate" always;
代理缓存：让 Nginx 自己存后端响应
当 Nginx 作为反向代理时，它能把后端（如 Node.js、PHP、Java 应用）返回的动态内容缓存到本地磁盘/内存，下次相同请求直接返回，不碰后端。这需要三步联动：
-
定义缓存区：在
http块中声明缓存路径与共享内存proxy_cache_path /var/cache/nginx/api levels=1:2 keys_zone=api_cache:100m max_size=10g inactive=60m use_temp_path=off; -
启用并绑定缓存：在
location中指定使用哪个缓存区proxy_cache api_cache; -
控制缓存生命周期：按 HTTP 状态码设置不同过期时间
proxy_cache_valid 200 302 5m; proxy_cache_valid 404 1m; proxy_cache_valid any 1m;
避免常见陷阱的实操要点
缓存配置看似简单，但线上出问题往往源于细节疏忽：
-
缓存键（
proxy_cache_key）要合理：默认值可能忽略查询参数或 Cookie，导致用户看到别人的数据；需显式定义，例如proxy_cache_key "$scheme$request_method$host$request_uri$is_args$args"; -
不要盲目信任后端的缓存头：如果后端返回了
Cache-Control: no-cache，Nginx 默认会跳过缓存；加proxy_ignore_headers Cache-Control Expires Set-Cookie;可强制按 Nginx 规则执行 -
区分缓存状态便于排查：加一行
add_header X-Cache-Status $upstream_cache_status;，响应头里就能看到HIT/MISS/STALE，一目了然
动静分离 + 策略分层才真正高效
单一配置撑不起真实业务。推荐按资源类型分层管理：
- JS/CSS/图片/字体 → 客户端长期缓存（
immutable+ 1 年） - API 接口（如
/api/v1/user）→ 代理缓存（5–30 分钟，视数据时效性） - 登录态页面或含用户信息的 HTML → 客户端不缓存（
no-store）或仅私有缓存（private） - 高并发热点页（如商品详情）→ 代理缓存 +
stale_while_revalidate，保证可用性不降级
