验证Nginx proxy_cache命中率需四类数据交叉印证：响应头X-Cache-Status、结构化访问日志、后端实际请求数、缓存文件物理存在性；缺一不可，否则易误判。
要验证 Nginx proxy_cache 缓存命中率统计的准确性，不能只看单一指标，必须用四类数据交叉印证：响应头状态、访问日志记录、后端实际请求数、缓存文件物理存在性。单靠某一项容易误判，比如响应头显示 HIT，但日志漏记或后端仍在被调用，说明配置有干扰项或缓存未真正生效。
加 X-Cache-Status 响应头快速验证单次行为
在启用 proxy_cache 的 location 块中加入：
add_header X-Cache-Status $upstream_cache_status always;
用 curl -I 或浏览器 Network 面板查看该头，确认返回值是否为预期状态：
- HIT：缓存直接返回，未触达后端
- MISS：首次请求，已回源并写入缓存
- EXPIRED：缓存存在但过期，已回源更新
- BYPASS：被跳过（如含 Cookie、
Cache-Control: no-cache、非 GET/HEAD 方法） - STALE：返回陈旧内容（
proxy_cache_use_stale生效时）
用结构化日志批量统计真实分布
仅查几个请求无法反映整体效果，必须将 $upstream_cache_status 写入日志并聚合分析：
在 http 块定义日志格式：
log_format cache_log '$remote_addr - [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $upstream_cache_status $request_time';
在对应 location 中启用：
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
access_log /var/log/nginx/api_cache.log cache_log;
用命令统计各状态出现频次：
awk '{print $11}' /var/log/nginx/api_cache.log | sort | uniq -c | sort -nr
注意分母应为所有非“-”状态之和：HIT + MISS + EXPIRED + BYPASS + STALE + UPDATING
不是简单用 HIT/(HIT+MISS)，否则会高估有效命中率。
压测对比后端真实负载变化
缓存是否起效，最终体现为上游压力下降：
- 关闭缓存，用
wrk -c 100 -d 30s http://your.site/api/data发起压测，记录后端 access log 中该路径的请求数 - 开启缓存并 reload，用相同参数重跑，观察后端请求数是否大幅减少（例如从 3000 次降到个位数）
- 同时比对
$request_time：HIT 请求应明显更快（如 0.002s vs 0.3s）
排除干扰项：
- 测试请求不带
Cookie或Cache-Control: no-cache - 禁用浏览器本地缓存（可加随机 query 参数如
?t=123） - 确保后端不返回
Set-Cookie或Vary: *
检查缓存目录与文件是否真实生成
配置正确 ≠ 缓存落地。需确认磁盘写入是否成功：
- 进入
proxy_cache_path目录（如/var/cache/nginx），执行：find . -type f | head -15—— 应看到大量哈希命名的文件 - 挑一个最近 HIT 的请求，用
stat查对应缓存文件修改时间，与请求时间比对是否一致 - 检查错误日志：
tail -f /var/log/nginx/error.log，留意Permission denied、cache file not found、no space left on device等报错
不复杂但容易忽略
