监控Nginx缓存命中率需区分HIT、MISS、EXPIRED、BYPASS、STALE、REVALIDATED六种状态，正确配置$upstream_cache_status采集、分路径结构化日志、结合open_file_cache指标及响应时间综合评估。
监控 Nginx 缓存命中率，核心不是看“有没有缓存”，而是看清每个请求在缓存生命周期中真实处于哪个环节——HIT、MISS、EXPIRED、BYPASS、STALE、REVALIDATED 这六种状态含义不同，混在一起统计会掩盖真实瓶颈。
用 $upstream_cache_status 记录每类请求行为
这个变量是分析命中的第一手依据，但必须正确采集：
- 只在配置了 proxy_cache 的 location 中有效（静态文件直出不走 proxy_pass，应改用 $sent_http_x_cache 或自定义头）
- 确保后端响应不含 Set-Cookie、Cache-Control: no-store 或 Vary: *，否则 Nginx 默认跳过缓存
- log_format 必须在 http 块定义，access_log 要写在同一作用域（比如都在 server 块内），避免变量为空或为“-”
结构化日志 + 分路径统计，避免干扰
把静态资源、API、HTML 页面的日志分开，才能看出哪类流量拖低了整体命中率：
- 为静态资源单独配 location 和 access_log：
location ~* \.(js|css|png|woff2|svg)$ {
access_log /var/log/nginx/static.log cache_log;
} - log_format 显式包含关键字段：
log_format cache_log '$remote_addr [$time_local] "$request" $status $body_bytes_sent $upstream_cache_status $upstream_response_time'; - 用简单命令快速看分布：
awk '{print $12}' /var/log/nginx/static.log | sort | uniq -c | sort -nr
结合 open_file_cache 状态，排查底层读取效率
静态文件服务不仅依赖 proxy_cache，更依赖文件系统访问效率。open_file_cache 缓存的是文件元数据（如 inode、修改时间），直接影响小文件并发读取性能：
- 启用并监控两个关键变量：$open_file_cache_hits 和 $open_file_cache_misses
- 在日志里一并记录，算出句柄级命中率：
ofc_hit:$open_file_cache_hits ofc_miss:$open_file_cache_misses - 命中率偏低？检查是否开了 noatime 挂载选项，以及 open_file_cache_min_uses 是否设得太低（建议 ≥2）
命中率不等于性能，要配合响应时间看实效
高 HIT 不代表快，比如大量 EXPIRED 或 STALE 请求仍需回源校验，延迟可能接近未缓存：
- 在日志中保留 $upstream_response_time 和 $request_time
- 筛选出 HIT 但 $upstream_response_time > 0.01s 的请求，说明缓存项虽存在，但可能因 proxy_cache_use_stale updating 或锁等待导致延迟
- 命中率目标建议分层设定：静态资源 >95%，API 接口 >70%，HTML 页面视更新频率定（通常 60%~80%）
