proxy_cache_revalidate 不是带宽节省主力，真正实现70%+带宽下降靠高命中率缓存、合理s-maxage控制及源站正确返回304；它仅在缓存过期后发起一次条件请求，不提升命中率，且依赖源站支持。
proxy_cache_revalidate 不是带宽节省主力，单独开启它无法实现 70% 带宽下降；真正起效的是高缓存命中率 + 合理的 s-maxage 控制 + 源站正确返回 304。
proxy_cache_revalidate 实际行为：只在过期后发一次条件请求
它不是“自动保鲜”，而是“过期后必须验证”。启用 proxy_cache_revalidate on 后，Nginx 仅在缓存状态为 EXPIRED 时，向源站发起带 If-Modified-Since 或 If-None-Match 的 GET 请求。源站返回 304 Not Modified 才复用本地响应体，否则接收完整 200 并更新缓存。
这意味着：
- 它不提升
HIT率，只把部分EXPIRED转成revalidated（日志中可见） - 每次过期都强制回源一次，增加请求数和延迟，尤其在源站慢或并发高时
- 若源站未返回
304（比如没设Last-Modified、ETag 计算错误、或直接返回200），则完全无效
为什么“70% 带宽节省”常被误归因于 revalidate
实测中某些静态资源场景确实出现高比例 304，但这是源站支持良好 + 缓存生命周期设置合理 + 内容低频更新共同作用的结果，不是 proxy_cache_revalidate 单独功劳。
容易踩的坑包括：
WebChat Voice Proxy
下载
⚠️ 已弃用 — 该技能已拆分为两个独立技能，以提升模块化程度：**webchat-https-proxy**（HTTPS/WSS 反向代理）和 **webchat-voi...**
- 源站动态接口未检查
If-Modified-Since头，一律返回200 - 缓存有效期太短（如
proxy_cache_valid 200 1s），导致高频验证，反而放大源站压力 - 没配
proxy_cache_lock on，多个并发请求同时触发验证，形成“缓存穿透风暴” - 误以为开启该指令就能替代
s-maxage，结果后端返回Cache-Control: max-age=60，Nginx 只缓 1 分钟，根本轮不到 revalidate 发挥作用
真正节省带宽的三件套配置
要稳定达成 70%+ 的后端带宽下降，必须组合以下配置，且顺序和依赖关系不能错：
- 后端响应头加
Cache-Control: public, s-maxage=3600, max-age=60—— 浏览器缓 1 分钟，Nginx 缓 1 小时，大幅提升HIT比例 - Nginx 配置兜底：
proxy_cache_valid 200 302 1h，覆盖无响应头或头不合法的情况 - 统一缓存键：
proxy_cache_key "$scheme$host$request_uri"，避免参数顺序/大小写/空格导致重复缓存 - 对静态资源启用长期缓存：
location ~* \.(js|css|png|jpg|gif)$ { proxy_cache_valid 200 24h; }
此时 proxy_cache_revalidate 才有存在意义：它只是在那 1 小时之后、内容又恰好未变时，帮你省下几百字节的响应体传输 —— 但前提是源站真能稳定返回干净的 304。
如何确认 revalidate 是否真的在工作
别只看 Nginx 日志里的 revalidated 字样，重点验证三点：
- 源站是否真实收到带
If-Modified-Since的请求（查源站 access log） - 源站是否返回了严格符合规范的
304（无Content-Length、无响应体、有Date头） - 对比开启前后，源站的
netstat -an | grep :或 Prometheus 中| wc -l nginx_upstream_requests_total是否显著下降 —— 如果只降了几个百分点，说明 revalidate 覆盖场景有限，应优先优化缓存覆盖率和时长
最常被忽略的一点：revalidate 的收益高度依赖源站能力。你调得再细，源站不返回 304，它就只是个摆设。
