缓存失效瞬间大量请求穿透到后端本质是未命中叠加并发回源，排查关键在于日志验证$upstream_cache_status（MISS/EXPIRED/BYPASS）、检查key一致性、确认stale+lock兜底生效及排除请求头/响应头干扰。
缓存失效瞬间大量请求穿透到后端（常误称为“穿透到数据库”，实际是穿透到上游服务，如应用层或网关），本质是缓存未命中叠加并发回源，导致上游被压垮。排查关键不在于“有没有缓存”，而在于“为什么没用上、谁在同时打上去、Nginx 是否做了兜底”。
看日志确认缓存真实状态
不能只信配置，要靠运行时证据：
- 在 location 块中添加：log_format cache_log '$remote_addr - $upstream_cache_status $time_local "$request" $status $upstream_response_time'; 并启用 access_log 使用该格式
- 查日志中 $upstream_cache_status 字段：出现大量 MISS 或 EXPIRED 是击穿起点；若全是 BYPASS，说明请求被主动绕过，不是失效问题
- 用 curl -I 请求目标接口，检查响应头是否含 X-Cache: EXPIRED（需先配 add_header X-Cache $upstream_cache_status;）
查 key 是否稳定、缓存是否真存在
缓存“失效”常因根本没存进去，或存了但 key 不一致：
- 检查 proxy_cache_valid 是否覆盖当前响应状态码：比如后端返回 200，但你只写了 proxy_cache_valid 502 1m;，那 200 响应压根不进缓存
- 打印实际 key：加 log_format debug_key '$upstream_cache_key';，观察同一接口的请求是否生成相同 key；若含 $args 或 $cookie_xxx，且参数随机（如
?t=1623456789），key 就会散列 - 进入缓存目录（如
/var/cache/nginx/），执行 find . -type f | head -10 看是否有文件；再用 stat 查修改时间，判断是否刚写入就马上过期
验证 stale + lock 是否生效
即使缓存过期，Nginx 也应能用旧内容扛住第一波并发——前提是配置到位且触发条件满足：
- 确认启用了 proxy_cache_lock on; 和 proxy_cache_use_stale error timeout updating;；前者让多请求排队等一个回源，后者允许在更新中、超时或连接失败时返回旧缓存
- 停掉 upstream 后测试：curl 应返回 502，但响应头 X-Cache 显示 STALE（而非 MISS 或空），且内容是旧的——这才是兜底成功
- 若返回的是空响应或 502 且无 STALE，检查是否漏了 proxy_cache_background_update on;，或 proxy_cache_path 中未设 use_temp_path=off 导致后台更新失败
排除前端和响应头干扰
很多“击穿”其实是被隐式跳过，而非缓存真失效：
- 前端带 Cache-Control: no-cache、Pragma: no-cache 或任意 Cookie，Nginx 默认 bypass；可在配置中加 proxy_cache_bypass $http_pragma $http_authorization; 显式控制
- 上游返回 Cache-Control: private、no-store 或 Set-Cookie，Nginx 默认不缓存；可加 proxy_ignore_headers Cache-Control Set-Cookie;（仅限可信后端）
- 临时关闭浏览器开发者工具的 “Disable cache”，避免本地干扰；用 curl 或 Postman 复现更可靠
