如何通过 proxy_cache_revalidate 利用 ETag 指令显著降低回源带宽损耗-Nginx-PHP中文网

proxy_cache_revalidate 是 Nginx 缓存验证指令，自动根据后端响应头（ETag 或 Last-Modified）发起 If-None-Match/If-Modified-Since 条件请求，缓存过期后轻量验证复用，节省带宽依赖源站正确返回 304。

如何通过 proxy_cache_revalidate 利用 etag 指令显著降低回源带宽损耗

proxy_cache_revalidate 本身不处理 ETag，也不能“利用 ETag 指令”——ETag 是 HTTP 响应头字段，不是 Nginx 的配置指令；而 proxy_cache_revalidate 是一个真实存在的 Nginx 缓存指令（截至 2026 年仍有效），但它不主动选择用 ETag 还是 Last-Modified，而是由 Nginx 根据后端响应自动决定：若响应含 ETag，它就发 If-None-Match；若含 Last-Modified，就发 If-Modified-Since；两者都存在时，通常优先用 If-None-Match。

它真正的作用是：在缓存过期后，不直接丢弃旧内容，而是发起一次轻量条件请求验证是否还能复用。节省带宽的前提，是源站正确返回 304 Not Modified，且响应体为空、仅含头部（约 200–500 字节）。若源站总返回 200，那这个机制不仅不省带宽，反而增加回源次数和延迟。

所以，想靠它显著降低回源带宽损耗，关键不在“怎么配 proxy_cache_revalidate”，而在于整个链路是否闭环支持协商缓存。

aperture: the L402 aware reverse proxy

安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。

下载

必须确保源站正确响应 ETag 验证

后端必须为资源生成稳定、语义准确的 ETag（如基于内容哈希，而非时间戳或随机值）
收到 If-None-Match 请求头时，需严格比对值：完全匹配 → 返回 304，不输出任何响应体，不设 Content-Length: 0（可能触发 Nginx 解析异常）
静态文件（.js/.css/.png）由标准 Web 服务器（Nginx/Apache）托管时，通常默认支持；动态接口（Node.js/PHP/Python）需手动实现校验逻辑

Nginx 端要启用并协同关键配置

开启验证：proxy_cache_revalidate on;
配合锁机制防并发击穿：proxy_cache_lock on; + proxy_cache_lock_timeout 200ms;
设置合理缓存有效期，避免过短导致高频验证：
例如对 HTML 列表页：proxy_cache_valid 200 10m;
缓存路径中启用 inactive 清理冷数据：proxy_cache_path ... inactive=1h;

不要忽略更高效的带宽节省手段

proxy_cache_revalidate 只在“缓存已过期”时生效，属于兜底行为；真正大幅降带宽（70%+）靠的是：
高命中率：扩大可缓存方法（如 proxy_cache_methods GET HEAD POST;）、缓存常见错误码（proxy_cache_valid 404 1m;）
长而可控的缓存时长：后端返回 Cache-Control: public, s-maxage=3600，让 Nginx 缓 1 小时，浏览器只缓 60 秒
精准缓存键：用 map 过滤无意义参数（如 utm_source），避免缓存碎片化