Nginx缓存失效源于后端返回非法Header（如空格、控制字符），导致无法解析Cache-Control等指令；需通过日志分析、curl验证、定位问题路径、临时忽略非法头+修复后端逻辑，并建立CI/CD检查与Header审计机制。
这个问题本质是缓存链路被“污染”——Nginx 本该缓存合法响应，却因后端返回非法 Header（如含空格、控制字符、超长字段等）直接拒绝解析，导致无法提取 Cache-Control、ETag 等关键缓存指令，最终整个缓存逻辑失效，所有请求都穿透到后端。
先确认是不是缓存真瘫痪了
别急着改配置，先验证现象是否匹配：
- 查 Nginx access_log，看命中缓存的请求是否极少或为零（$upstream_cache_status 字段长期为
MIS或BYPASS，几乎不出现HIT或STALE） - 查 error_log，搜索
upstream sent invalid header或invalid header，若高频出现，说明 Nginx 连响应头都没收全，自然无法做缓存决策 - 用
curl -v http://your-domain/直连 Nginx，观察响应中是否缺失X-Cache、Age等缓存相关 Header，同时检查状态行后是否紧跟着非法字符（可用xxd查看十六进制流）
定位后端哪条路径在吐畸形 Header
不是所有接口都出问题，要聚焦“缓存失效集中爆发”的路径：
- 在对应
location块中临时加日志：log_format cache_debug '$remote_addr [$time_local] "$request" $status $upstream_http_cache_control $upstream_http_etag "$upstream_http_content_type"';，再配access_log /var/log/nginx/cache_debug.log cache_debug; - 重点看
$upstream_http_cache_control字段是否为空、是否含\x20（空格）、\u00A0（不间断空格）或\r\n等异常字节 - 对疑似接口，用
curl -v http://backend:port/path绕过 Nginx 直连后端，用xxd或hexdump -C查原始响应头字节，确认非法字符真实存在位置
快速恢复缓存 + 根因修复双线并行
线上不能停，但也不能只靠临时绕过掩盖问题：
- 紧急缓解：在出问题的
location中加proxy_ignore_headers Cache-Control Expires Set-Cookie;—— 这能让 Nginx 忽略后端传来的非法缓存头，转而用你配置的proxy_cache_valid强制生效；注意这只是兜底，不能替代修复 - 同步修复后端：重点检查人工设置 Header 的地方，比如 Spring Boot 的
Filter中response.setHeader("Cache-Control", "public, max-age=" + ttl)，若ttl是空字符串或 null，就会生成max-age=这种非法值；务必加if (ttl != null && !ttl.trim().isEmpty())校验 - 拦截非法输出：在网关或统一响应包装层增加 Header 白名单和 trim 逻辑，对所有
Set-Cookie、Cache-Control等关键字段值自动去首尾空格、过滤控制符（正则[\x00-\x08\x0B\x0C\x0E-\x1F\x7F]）
预防缓存再次被 Header 毁掉
一次修复不够，得让系统有“免疫能力”：
- 在 CI/CD 流水线中加入 Header 合法性检查：用脚本调用后端接口，提取所有响应头，校验字段名是否符合
[a-zA-Z0-9!#$%&'*+.^_`|~-]+，值是否不含控制字符、首尾空白 - Nginx 层加一层“Header 审计日志”：用
map指令标记含非法字符的响应，例如map $upstream_http_cache_control $bad_cc { "~*[\x00-\x08\x0B\x0C\x0E-\x1F\x7F]" 1; default 0; }，再写入独立日志，持续监控 - 对高风险服务（如带 JWT、链路追踪头的接口），在
location中显式设proxy_buffer_size 32k;和http2_max_field_size 16k;，避免因缓冲区不足导致 Header 截断后内容错位，间接产生非法结构
