缓存穿透是请求数据在redis和数据库中均不存在，导致每次查询都绕过缓存直击数据库；击穿是热点key过期瞬间大量并发请求同时回源查库；雪崩是大批key集体失效或redis宕机致流量全涌向数据库。
缓存有效期被代理链中间节点篡改，本质是响应头里的 Cache-Control 或 Expires 在经过 CDN、反向代理（如 Nginx）、WAF 或网关时被意外重写或覆盖。这类问题不会报错，但会导致边缘缓存不命中、回源激增、命中率骤降——你查 Redis 或源站逻辑都正常，却始终“缓存不生效”。排查关键不是看最终结果，而是抓取整条链路上每个环节的真实响应头。
一、先确认是否真被篡改：比对原始响应与终端响应
用 curl -I 分两步抓包：
- 直接请求源站（绕过所有代理）：
curl -I http://your-origin.com/path
记下返回的Cache-Control（比如public, max-age=3600）和Expires - 再请求线上域名（走完整代理链）：
curl -I https://your-domain.com/path
对比两者Cache-Control是否一致。若变成no-cache、max-age=0或消失，说明中间某层动了手脚。
二、逐级定位篡改点：从边缘到源站倒推
腾讯云 EdgeOne、Cloudflare、阿里云全站加速等平台，都支持在控制台查看“实际生效的缓存策略”和“X-Cache-Status”响应头。重点看这些字段：
-
X-Cache: MISS from edge+X-Cache-Status: BYPASS→ 表明边缘节点明确拒绝缓存，大概率是响应头含no-cache、no-store或Set-Cookie -
X-Edge-Cache: HIT但X-Cache-Status: HIT-STALE→ 缓存存在但已过期，说明max-age被缩短或s-maxage未生效 - 若使用自建 Nginx 反向代理，检查配置中是否有
proxy_cache_valid强制覆盖、或proxy_hide_header Cache-Control+add_header重写行为
三、常见篡改源头与自查项
以下几类中间件最常“好心办坏事”：
-
CDN 平台规则引擎：EdgeOne、Cloudflare 的缓存规则若设置了“忽略源站头”，会丢弃
Cache-Control，改用规则里填的固定值；若开启“强制缓存”，可能把所有响应统一设为max-age=86400，覆盖源站意图 -
WAF 或安全网关：部分 WAF 默认对含
Set-Cookie或Vary头的响应插入Cache-Control: private，防止敏感内容被共享缓存 -
API 网关 / Spring Cloud Gateway：若配置了全局
response.setHeader("Cache-Control", "no-store")，或用了某些限流插件自动添加no-cache - 源站自身重定向：比如 HTTP → HTTPS 跳转时，301 响应默认无缓存头，而某些网关会把跳转响应也当成可缓存资源处理，导致后续请求被错误缓存
四、验证与修复建议
定位到具体环节后，修复要分两步走：
-
临时验证：在对应中间件上关闭“自动重写缓存头”选项，或添加一条高优先级规则，显式
pass-through Cache-Control头（EdgeOne 支持“保留源站响应头”开关） -
长期治理：源站响应头尽量用
Cache-Control: public, max-age=3600, s-maxage=7200明确区分浏览器与共享缓存；避免只写Expires，因部分代理不识别该头；对动态接口，统一加Cache-Control: no-cache，而非依赖中间件默认行为
