可通过Nginx的add_header结合$upstream_cache_status变量在proxy_pass后添加X-Cache-Status头，标识缓存命中状态（HIT/MISS等），需启用proxy_cache、正确定义缓存区与键，并注意add_header作用域及always参数使用。
可以通过 Nginx 的 add_header 指令，在代理响应中添加 X-Cache-Status 头，标识该响应是否命中缓存。关键在于：这个头必须在缓存决策完成后设置，且不能被后端响应覆盖——因此推荐结合 $upstream_cache_status 变量，在 location 或 proxy_pass 上下文中使用。
确认已启用 proxy_cache 并定义缓存区域
只有启用缓存并成功匹配缓存键，$upstream_cache_status 才会有值（如 HIT、MISS、EXPIRED、BYPASS 等）。需确保配置中包含：
- 全局定义缓存区：
proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=1g; - 在
server或location中启用缓存：proxy_cache my_cache; - 设置缓存有效时间：
proxy_cache_valid 200 302 10m; - 指定缓存键：
proxy_cache_key "$scheme$request_method$host$request_uri";
在 proxy_pass 后使用 add_header 注入 X-Cache-Status
add_header 必须放在 proxy_pass 所在的 location 块内，且不能在子请求或 rewrite 后丢失上下文。正确写法示例：
location / {
proxy_pass http://backend;
proxy_cache my_cache;
proxy_cache_valid 200 302 10m;
add_header X-Cache-Status $upstream_cache_status;
}
注意：add_header 默认不继承父块，且不会覆盖后端已有的同名响应头（除非加 always 参数）；若需强制添加（包括 304、错误响应等），应写成：
add_header X-Cache-Status $upstream_cache_status always;
避免常见陷阱
-
不要在 upstream 块里用 add_header：它只作用于响应头生成阶段，而
$upstream_cache_status是 proxy 模块在转发后才填充的变量 -
不要用 return 或 error_page 覆盖响应流：这些指令会跳过后续的
add_header，导致头未注入 - 区分 $upstream_cache_status 和 $sent_http_x_cache_status：后者是已发送的响应头，不可用于条件判断或动态赋值
-
浏览器可能忽略自定义头：X-Cache-Status 不影响渲染，仅用于调试；若需前端读取，请确保响应允许 CORS（如加
add_header Access-Control-Expose-Headers X-Cache-Status;）
进阶：按缓存状态做差异化处理
可结合 map 定义更友好的状态描述，再注入：
map $upstream_cache_status $cache_status_desc {
HIT "HIT";
MISS "MISS";
EXPIRED "STALE";
BYPASS "BYPASS";
DEFAULT "NONE";
}
server {
...
location / {
proxy_pass http://backend;
proxy_cache my_cache;
add_header X-Cache-Status $cache_status_desc always;
}
}
这样返回的头更直观，便于监控和排查。
