在 linux 中测试 nginx 不同缓存键的命中效果，核心方法是修改 proxy_cache_key 配置并配合 x-cache-status 响应头进行验证。通过调整 $uri、$query_string 或自定义变量，可以观察请求变化时缓存是命中还是未命中。设置完成后，使用 curl 命令发送带有 -i 参数的请求，检查返回头中的 x-cache-status 字段，若显示 hit 则表示缓存生效，显示 bypass 或 miss 则说明缓存键策略导致未命中。
如何验证默认缓存键对相同 URL 的命中情况
默认情况下，Nginx 使用 $scheme$proxy_host$request_uri 作为缓存键。要验证这一行为，只需确保请求的 URI 和查询字符串完全一致，即可观察到连续的 HIT 状态。这证明了只要缓存键不变，Nginx 就会直接返回之前的缓存内容，而不会向后端发起新的请求。
server {
listen 80;
server_name localhost;
proxy_cache_path /tmp/nginx_cache levels=1:2 keys_zone=my_cache:10m max_size=1g inactive=60m;
location /api {
proxy_pass http://backend_server;
proxy_cache my_cache;
# 使用默认的缓存键
proxy_cache_key $scheme$proxy_host$request_uri;
add_header X-Cache-Status $upstream_cache_status;
}
}
预期结果：第一次请求返回 X-Cache-Status: MISS，第二次相同请求返回 X-Cache-Status: HIT。
如何通过包含 Query String 区分不同参数的缓存
当需要为不同的查询参数生成独立的缓存时，必须在 proxy_cache_key 中包含 $query_string。这样，即使 URI 路径相同，只要查询参数不同，Nginx 就会将其视为不同的资源，从而生成不同的缓存条目。通过对比不同参数组合的请求头，可以清晰看到缓存键的变化如何影响命中结果。
server {
listen 80;
server_name localhost;
proxy_cache_path /tmp/nginx_cache_query levels=1:2 keys_zone=query_cache:10m max_size=1g inactive=60m;
location /api {
proxy_pass http://backend_server;
proxy_cache query_cache;
# 将查询字符串纳入缓存键
proxy_cache_key $scheme$proxy_host$request_uri$query_string;
add_header X-Cache-Status $upstream_cache_status;
}
}
预期结果：请求 /api?id=1 首次为 MISS，再次请求仍为 HIT；但请求 /api?id=2 会返回 MISS，因为缓存键不同。
基于 proxy_cache_key 中移除 query_string 的具体问题
如果在 proxy_cache_key 中显式移除了 $query_string，例如设置为 $scheme$proxy_host$request_uri，那么所有携带不同查询参数但 URI 相同的请求都将共享同一个缓存。这意味着一旦第一个请求生成了缓存，后续所有不同参数的请求都会直接命中该缓存，而不会向后端发送请求。这种行为在某些场景下可能导致数据不一致，但在静态资源或忽略参数的场景中非常有用。
