应记录$upstream_cache_status至日志而非仅响应头，通过log_format定义含该变量的日志格式并在location中启用access_log；其六类状态（HIT/MISS/EXPIRED/STALE/UPDATING/BYPASS）分别指向缓存键、有效期、绕过规则等配置优化方向。
直接看 $upstream_cache_status 的值，不是为了确认“有没有缓存”，而是为了诊断“缓存为什么没被用好”。命中率低往往不是缓存没开，而是配置与业务不匹配。
把状态真正记录下来才能分析
只在响应头里加 add_header X-Cache-Status $upstream_cache_status，只能手动调试单个请求。真实调优必须落盘日志：
- 定义带缓存状态的日志格式，例如：
log_format cache_log '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $upstream_cache_status $upstream_response_time $request_time'; - 在静态资源 location 块中启用该日志：
access_log /var/log/nginx/static_access.log cache_log; - 确保
proxy_cache已启用，且对应 location 匹配了需要缓存的路径（如/static/、.js、.css等）
读懂六类状态背后的含义
命中率不是简单算 HIT / (HIT + MISS)，每种状态都指向不同优化方向：
- HIT：缓存生效，理想状态
-
MISS：首次访问或缓存未建立；若比例过高，说明资源冷启动频繁，或
proxy_cache_min_uses设得过大 -
EXPIRED：缓存过期后回源；大概率是
proxy_cache_valid设置太短，尤其对不变的静态资源（如带哈希名的 JS/CSS），应设为 1y -
STALE：后端不可达时返回旧缓存；说明
proxy_cache_use_stale生效，但需检查上游健康状况 -
UPDATING：后台正在刷新缓存；属正常行为，但若比例高，可配合
proxy_cache_lock避免重复回源 -
BYPASS：被
proxy_cache_bypass规则跳过；常见于含特定 cookie、header 或参数的请求，需核对绕过条件是否误伤静态资源
从三个关键点针对性调整策略
统计出状态分布后，聚焦以下三处配置做修正：
-
缓存键（
proxy_cache_key）是否合理：默认值可能包含$cookie_或$args，导致相同资源因参数不同被多次缓存。静态资源建议精简为：proxy_cache_key "$scheme$request_method$host$uri"; -
缓存有效期（
proxy_cache_valid）是否分层：200/304 响应可设长 TTL（如 1y），404 可设短 TTL（如 1m），避免无效请求长期占位 -
缓存写入门槛（
proxy_cache_min_uses）是否恰当：默认为 1，若设为 3 或 5，会导致低频但稳定的资源无法进入缓存，对静态资源建议保持 1
验证优化效果要持续观察
改完配置后，别只看单次请求的 X-Cache-Status，而是用脚本或日志分析工具（如 awk、Logstash、Grafana+Prometheus）按小时聚合状态计数，计算滚动命中率：
命中率 = HIT / (HIT + MISS + EXPIRED + STALE + UPDATING + BYPASS)
重点关注 EXPIRED 和 BYPASS 是否明显下降，HIT 是否稳定上升——这才是调优落地的信号。
