验证proxy_cache是否生效需四步闭环：一看响应头X-Cache-Status值（HIT/MISS/BYPASS等），二查日志中$upstream_cache_status统计命中率，三测TTFB与后端请求数下降幅度，四比缓存启停前后性能指标变化。
验证生产环境中 proxy_cache 是否真正生效、加速是否达标，不能只看配置有没有写对，关键得看真实请求的响应行为和系统指标。核心方法是“看头、查日志、测指标、比前后”四步闭环。
一、用响应头快速判断缓存命中状态
最直接的方式是在 HTTP 响应中添加 X-Cache-Status，让每次请求都明确告诉你缓存结果：
- 在对应
location块里加这行：add_header X-Cache-Status $upstream_cache_status; - 用
curl -I请求一个静态资源（如curl -I https://example.com/app.js），观察返回头：-
X-Cache-Status: HIT→ 缓存命中，内容从本地磁盘/内存读取，不回源 -
X-Cache-Status: MISS→ 首次请求或缓存未命中，Nginx 回源拉取并存入缓存 -
X-Cache-Status: BYPASS→ 被proxy_cache_bypass或条件规则跳过，未进入缓存流程 -
X-Cache-Status: EXPIRED或STALE→ 缓存已过期但可能被proxy_cache_use_stale允许返回
-
- 注意：该头默认不随重定向传递，若请求被 301/302 跳转，需在跳转后的 location 中也加该指令才能看到
二、检查 Nginx 访问日志确认缓存行为
在 log_format 中加入缓存相关变量，让每条日志自带上下文：
aperture: the L402 aware reverse proxy
下载
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
- 定义带缓存信息的日志格式（放在
http块）：log_format cache '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$upstream_cache_status" $request_time $upstream_response_time'; - 在
server或location中启用：access_log /var/log/nginx/cache.log cache; - 上线后抽样查看日志，统计
HIT占比（例如：过去一小时 HIT 率是否稳定在 85%+），明显偏低说明缓存未覆盖预期请求，要回头检查location匹配、proxy_cache_key设计或proxy_ignore_headers是否误吞了上游 Cache-Control
三、观测实际性能提升指标
缓存的价值最终体现在用户侧和服务器侧的数字变化上：
- 首字节时间（TTFB）下降：对比缓存开启前后同一资源的 TTFB。HIT 请求通常
- 后端请求数锐减：在后端服务（如 Node.js/PHP/源站 Nginx）上统计每分钟请求量。若静态资源类请求下降 70% 以上，证明流量已被边缘缓存承接
-
Nginx 自身负载降低：监控
nginx_process_resident_memory_bytes和nginx_http_request_duration_seconds_count（配合 Prometheus + nginx-module-vts 或 openresty-lua-stats），HIT 率升高时，CPU 使用率与 upstream 连接数应同步走低
四、模拟真实场景做对比验证
避免“看起来配了，其实没用”，建议做三次对照测试：
-
关源验证：临时停掉后端服务（如
systemctl stop apache2），访问已知 HIT 的 URL，仍能正常返回且X-Cache-Status: HIT→ 证明缓存持久有效 -
参数绕过验证：访问带
?v=2的 URL，确认返回BYPASS或MISS；再访问无参版本，确认命中 → 验证proxy_cache_bypass $args生效 -
更新一致性验证：更新一个 JS 文件并重新部署，首次访问返回新内容（
MISS），后续访问返回HIT；再用旧哈希名访问，仍返回旧缓存 → 验证版本化文件缓存隔离正确
