Nginx缓存过期逻辑排查关键在于还原上游响应头真实内容，而非解析二进制缓存文件；需通过$upstream_http_cache_control等变量查实际解析结果，用curl+xxd定位非法字符（如max-age=空值），结合error_log中“invalid header”报错确认Header解析失败，并区分proxy_ignore_headers临时绕过与后端根治修复。
缓存文件结构本身不直接存储可读的 HTTP Header，Nginx 的 proxy_cache 是二进制格式的内部存储，无法像日志或响应流那样直接查看原始 Header。真正需要分析的，是缓存决策所依赖的 Header 信息——它们来自上游响应，被 Nginx 解析后用于判断是否缓存、缓存多久、是否命中等。排查过期逻辑，关键在于还原“Nginx 看到了什么 Header”，而不是打开 cache 文件去读字节。
查 $upstream_http_* 变量确认实际收到的响应头
Nginx 在代理响应后，会把上游返回的响应头存入变量（如 $upstream_http_cache_control、$upstream_http_expires、$upstream_http_etag），这些变量反映的是 Nginx 实际解析到的内容，可能已被截断、忽略或因非法字符为空。
- 在对应 location 中添加调试日志：
log_format cache_debug '$remote_addr - "$request" $status $upstream_http_cache_control $upstream_http_expires "$upstream_http_content_type"';，再配access_log /var/log/nginx/cache_debug.log cache_debug; - 重点观察
$upstream_http_cache_control是否为public, max-age=3600这类合法值，还是空、含空格（max-age=）、控制字符（\u00A0）或重复字段 - 若该变量为空，说明 Nginx 根本没成功提取 Cache-Control——大概率是后端返回了畸形 Header（如开头/结尾有空格、换行、不可见 Unicode 字符）
用 curl + xxd 验证原始响应头字节流
绕过 Nginx 直连后端，抓取未经处理的原始响应，才能定位非法字符真实位置：
- 执行：
curl -v http://backend:port/path 2>&1 | head -n 50，先看状态行后是否紧跟着异常空白或乱码 - 更准确方式：
curl -s -D /tmp/hdrs.txt -o /dev/null http://backend:port/path && xxd /tmp/hdrs.txt，用十六进制查看每个字符（如20是空格，a0是不间断空格，0d 0a是 CRLF） - 常见陷阱：Spring Boot 中
response.setHeader("Cache-Control", "max-age=" + ttl)，当ttl为 null 或空字符串时，生成Cache-Control: max-age=—— 这是语法错误，Nginx 拒绝解析整条 Header
检查 Nginx 是否因 Header 合法性问题跳过缓存解析
Nginx 对非法 Header 的处理很严格：一旦发现响应头含控制字符、超长字段、非法分隔符或空值，就会丢弃整个响应头块，导致 $upstream_http_cache_control 为空，进而无法执行 proxy_cache_valid 之外的任何缓存逻辑。
- 查 error_log：
grep "invalid header\|upstream sent invalid" /var/log/nginx/error.log，高频出现即证实 Header 解析失败 - 此时
$upstream_cache_status多为BYPASS或MISS，且X-Cache-Status不体现缓存行为，因为缓存模块根本没启动 - 注意：
proxy_ignore_headers Cache-Control可临时绕过此问题，让 Nginx 忽略非法头、转而信任proxy_cache_valid配置，但这只是应急，不能替代修复后端
比对缓存键与实际生效的过期策略
即使 Header 合法，过期逻辑也可能被覆盖或误判：
- 确认
proxy_cache_key是否包含影响缓存粒度的变量（如$args导致带不同参数的请求各自缓存） - 检查是否有多个
proxy_cache_valid规则冲突：Nginx 按响应状态码匹配，proxy_cache_valid 200 1h和proxy_cache_valid any 1m同时存在时，200 响应以 1h 为准；但若只配了any，而响应头又有Cache-Control: no-cache，默认仍不缓存 - 验证是否启用了
proxy_cache_use_stale updating：它会让 Nginx 在后台更新缓存时仍返回旧内容，此时$upstream_cache_status显示STALE，容易误判为“过期未更新”
