最直接有效的方式是结合请求头响应状态与实际性能数据交叉验证。通过添加X-Cache-Status头、压测对比响应时间与后端请求数、检查缓存目录文件生成、监控命中率等方式综合判断缓存是否真实生效。
最直接有效的方式是结合请求头响应状态与实际性能数据交叉验证，而不是只看配置是否加载成功。
查看缓存命中状态头
在 location 块中添加调试头，让每次响应都携带缓存执行结果：
-
必须启用：
add_header X-Cache-Status $upstream_cache_status;（用于代理缓存）或add_header Nginx-Cache $upstream_cache_status; - 浏览器开发者工具 → Network → 点击请求 → Headers → 查看 X-Cache-Status 字段值
- 常见状态含义：
HIT：缓存命中，未访问后端
MISS：首次请求，已存入缓存
EXPIRED：缓存过期，已回源并更新缓存
STALE：返回陈旧缓存（因proxy_cache_use_stale生效）
UPDATING：后台正在刷新缓存，当前返回旧内容
用 ab 或 wrk 做基础压测对比
通过并发请求观察响应时间与后端调用量变化：
- 先关闭缓存，运行：
ab -n 5000 -c 100 http://your.site/api/data，记录平均响应时间和后端日志请求数 - 开启缓存并 reload 配置后，用相同参数重跑，应看到：
平均响应时间明显下降（如从 800ms → 40ms）
后端日志中对应 URL 的访问次数大幅减少（例如仅前 2–3 次出现） - 注意：需确保测试期间无缓存清理、无
Cache-Control: no-cache请求头干扰
检查缓存目录与文件生成
确认缓存物理落地，排除路径权限或磁盘满导致的“假命中”：
- 进入
proxy_cache_path指定的目录（如/var/cache/nginx），执行：find . -type f | head -20—— 应能看到大量哈希命名的文件 - 用
du -sh *查看子目录大小，确认缓存区正在增长 - 检查 Nginx 错误日志：
tail -f /var/log/nginx/error.log，留意是否有open() "/var/cache/nginx/... failed (13: Permission denied)"或cache file ... not found类报错
监控缓存命中率（长期可观测）
借助 Nginx stub_status 模块 + 外部脚本或 Prometheus exporter：
- 启用状态页：
location /nginx_status { stub_status on; access_log off; allow 127.0.0.1; deny all; } - 访问
http://127.0.0.1/nginx_status，输出类似：
Active connections: 12<br> server accepts handled requests<br> 123456 123456 789012<br> Reading: 0 Writing: 2 Waiting: 10
其中第三行“requests”累计值可配合 HIT/MISS 日志做命中率估算 - 更精准做法：用 Logstash 或自定义脚本解析 access.log，统计含
X-Cache-Status: HIT的占比
