关键在于按响应状态码、响应头及请求特征精细化配置Nginx缓存：200/206缓存1小时，301/302缓存3天，404缓存10分钟，5xx慎缓存1分钟；优先遵循Cache-Control，启用proxy_cache_use_stale与proxy_cache_lock防并发回源；通过X-Cache头和Age头验证命中，并排查proxy_buffering off、cache_methods限制等常见失效原因。
关键不在盲目调大 proxy_cache_valid 时间，而在于让缓存策略匹配真实业务响应特征——比如状态码、内容类型和更新频率。
按响应状态码精细化设置缓存时长
不同 HTTP 状态码代表不同语义，统一设为 1 小时可能浪费缓存空间或导致陈旧内容被误用。
-
200/206（成功响应）：可缓存较长时间，如
proxy_cache_valid 200 206 1h; -
301/302（重定向）：通常稳定且长期有效，建议缓存 1–7 天：
proxy_cache_valid 301 302 3d; -
404（未找到）：避免反复穿透后端查不存在资源，缓存 5–10 分钟即可：
proxy_cache_valid 404 10m; -
跳过 5xx 响应缓存：默认不缓存，若需兜底可加
proxy_cache_valid 500 502 503 504 1m;，但慎用
结合响应头动态控制缓存有效期
单靠 proxy_cache_valid 是静态规则，实际中后端常通过 Cache-Control 或 Expires 告知缓存意愿。Nginx 默认会优先遵循这些头字段，除非显式禁用：
- 启用后端指示优先：
proxy_ignore_headers Cache-Control Expires;—— 强制忽略后端头，完全由proxy_cache_valid决定 - 更推荐保留协商能力：
proxy_cache_use_stale updating error timeout http_500;，配合proxy_cache_lock on;防止缓存失效时的并发回源 - 对 API 类接口，可添加
proxy_cache_bypass $arg_nocache $http_pragma $http_authorization;，支持客户端主动绕过缓存
验证缓存是否真正生效
命中率低不一定是配置错，可能是请求未进入同一 cache zone，或 key 构造不一致。
- 检查响应头是否有
X-Cache: HIT或MISS（需在配置中加add_header X-Cache $upstream_cache_status;） - 确认
proxy_cache_key是否包含影响缓存粒度的变量，例如默认$scheme$proxy_host$request_uri不含 Cookie；若需登录态缓存，应显式定义并谨慎评估安全边界 - 用
curl -I对比多次请求，观察Age头是否递增，确认缓存复用而非每次都新建
避免常见干扰项
以下配置会直接导致缓存失效或无法写入，需同步排查：
-
proxy_buffering off;：关闭缓冲会禁用缓存，必须开启 -
proxy_cache_methods GET HEAD;：默认不缓存 POST，如需缓存需显式添加，但注意幂等性 -
location中缺失proxy_cache my_cache;或指向了未声明的 zone - 磁盘路径
/tmp/cache权限不足或空间满，可用nginx -t和系统日志交叉验证
