Nginx proxy_cache 中502错误不直接破坏缓存，而是因proxy_cache_valid未配置502、proxy_cache_use_stale未启用http_502、cache_key不稳或路径不可写等导致无法缓存或兜底失败。
排查 Nginx proxy_cache 因 502 错误引发的缓存失效，核心在于：502 本身不会直接“破坏”缓存，但若配置不当，会导致错误响应不进缓存、或无法从缓存兜底，从而让 502 暴露给用户。关键不是查“缓存丢了”，而是查“为什么该缓存的没缓存，该用缓存的没用上”。
确认 502 响应是否被缓存
默认情况下，Nginx 不会缓存 5xx 响应。如果后端返回 502，而你又没显式配置缓存策略，那这个 502 就是实时透传的，根本不会进 cache，自然也谈不上“缓存失效”。
- 检查配置中是否有
proxy_cache_valid 500 502 503 504 Xs;（例如1m），没有这行，502 永远不进缓存 - 用
curl -I http://your-domain/查看响应头，若返回 502 且无X-Cache: HIT或MISS，说明压根没走缓存逻辑 - 停掉上游服务后再次请求，观察 error.log 是否出现
upstream prematurely closed connection类报错——这是 502 来源，但不代表它被缓存了
验证 proxy_cache_use_stale 是否生效
即使 502 被缓存了，用户也不一定拿到它；proxy_cache_use_stale 才决定“什么情况下允许返回过期缓存”。没配它，缓存再全也没用。
- 必须启用对应条件：
proxy_cache_use_stale http_502;（单独写也行）或更常用的一组：http_500 http_502 http_503 http_504 - 禁用不相关项：不要加
error timeout updating，除非你明确需要应对网络抖动；否则可能把临时故障当成“崩溃”来 stale 返回，反而掩盖真实问题 - 配合添加响应头便于验证：
add_header X-Cache $upstream_cache_status;，停掉后端后看到X-Cache: STALE才算真正生效
检查缓存 key 和存储路径是否稳定可用
缓存条目存在，是 stale 生效的前提。key 不稳或路径不可写，会导致“想缓没得缓”。
-
proxy_cache_key必须排除动态变量：避免含$request_id、$time_iso8601、$cookie_xxx等，推荐用$scheme$host$request_uri -
proxy_cache_path路径需有写权限，且磁盘未满；可用df -h和ls -ld /path/to/cache快速确认 - 确保
location块里正确引用了 cache 区域，例如proxy_cache my_cache;，且该名称与proxy_cache_path中定义的一致
区分“缓存未命中”和“缓存兜底失败”
日志里看到 502，不等于缓存机制坏了。要判断到底是没缓存成功，还是缓存了但没 fallback 成功。
- 查
error.log：出现upstream sent no valid HTTP/1.0 header或connect() failed (111: Connection refused)，说明上游根本连不上，此时依赖的是stale配置是否覆盖该场景 - 查
access.log（需提前加log_format含$upstream_cache_status）：若大量BYPASS或空值，说明请求被跳过缓存；若全是MISS且持续返回 502，大概率是proxy_cache_valid缺失 502 规则 - 手动触发一次正常请求（后端开着），确认能生成
HIT；再停后端，看是否转为STALE—— 这个闭环验证比看日志更直观
