Nginx 反向代理缓存：proxy_cache 的三层配置与命中率排查

给站点加 Nginx 缓存，最容易踩的坑不是不会配，而是配完了不知道有没有生效。判断标准只有一个：X-Cache-Status 这个响应头到底返回什么。

三层配置，缺一层就白配

第一层是缓存空间本身，写在 http 段里：

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=site:64m max_size=2g inactive=60m use_temp_path=off;

第二层是缓存键，决定什么请求算"同一个页面"。默认用 $scheme$proxy_host$request_uri 就够了，但如果站点有移动端和桌面端两套模板，必须把设备标识加进键里，否则手机访问会拿到 PC 页面的缓存。

第三层是缓存策略，写在 location 里：

proxy_cache site;
proxy_cache_valid 200 302 10m;
proxy_cache_valid 404 1m;
proxy_cache_use_stale error timeout updating http_500 http_502 http_503;
proxy_cache_lock on;
add_header X-Cache-Status $upstream_cache_status;

命中率低的三个常见原因

响应带 Set-Cookie。Nginx 默认不缓存带 Set-Cookie 的响应。如果后端每个页面都塞会话 Cookie，缓存会全部失效。解决办法是在 proxy_ignore_headers Set-Cookie; 的同时，用 proxy_hide_header Set-Cookie; 把 Cookie 挡在缓存之外。
请求带 Cookie 或 Authorization。默认情况下这类请求直接绕过缓存。对纯展示页面，可以 proxy_cache_bypass 加白名单，只让登录态请求穿透。
Vary 头。后端返回 Vary: User-Agent 时，每个 UA 都是一份独立缓存，命中率自然低。