要让proxy_cache_revalidate真正通过304大幅降低回源带宽，核心是Nginx缓存层、源站正确返回干净304、合理设置缓存有效期三者闭环协同；实测静态资源或低频接口复用率达75%–90%，源站返回200则优化完全失效。
要让 proxy_cache_revalidate 真正通过 304 响应大幅降低回源流量成本，核心不是单纯开启指令，而是构建“Nginx 缓存层 + 源站条件响应 + 合理生命周期”三者协同的闭环。实测中，静态资源或低频更新接口在该机制下可实现 75%–90% 的过期缓存复用率，对应回源带宽下降幅度接近这一区间。
源站必须正确支持并返回干净的 304
这是整个机制生效的前提。Nginx 发出带 If-Modified-Since 或 If-None-Match 的验证请求后，若源站返回 200（哪怕内容未变），Nginx 就会下载完整响应体、覆盖本地缓存，优化完全失效。
- 静态文件（.js/.css/.png）：标准 Nginx/Apache 默认启用
Last-Modified，只要不显式关闭，通常天然支持 304 - 动态接口（PHP/Node.js/Python）：需在代码中主动读取
If-Modified-Since头，比对资源最后修改时间；若未变更，必须输出HTTP/1.1 304 Not Modified，且响应体为空、不设Content-Length: 0 - 常见错误：返回 304 时附带空 body 或多余头（如
Transfer-Encoding: chunked），可能触发 Nginx 解析异常，导致缓存降级
缓存有效期设置要匹配业务更新节奏
proxy_cache_revalidate 只在缓存“已过期但尚未被清除”时触发。有效期太短（如 1 秒），会导致高频验证，增加延迟和请求数；太长则失去及时性，还可能让过期缓存滞留太久。
aperture: the L402 aware reverse proxy
下载
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
- 静态资源（JS/CSS/图片）：设为长期有效（如
proxy_cache_valid 200 1y），基本不走 revalidate，靠 URL 版本化更新 - HTML 页面、API 列表页等轻量可变内容：设中等有效期（如
proxy_cache_valid 200 10m），让 revalidate 在过期后自动介入 - 配合
inactive=1h（在proxy_cache_path中），确保冷数据不会无限占用磁盘
必须启用关键配套指令才能防止并发击穿
单独开 proxy_cache_revalidate on 不够，没有锁机制时，多个并发请求同时命中过期缓存，会引发多次上游验证，反而放大源站压力。
-
proxy_cache_lock on：只允许第一个请求发起验证，其余等待并复用结果 -
proxy_cache_lock_timeout 5s：避免锁等待过久，超时后允许一个新请求发起验证 -
proxy_cache_background_update on：在返回旧缓存的同时异步刷新，提升用户体验与 TTFB -
proxy_cache_valid 304 1h：显式缓存 304 响应本身（极小开销），避免每次过期都重复校验
日志与监控要能区分真实 304 复用行为
仅看 access log 中的 304 状态码不够——那可能是客户端直接发来的条件请求，而非 Nginx 自动发起的 revalidate。需结合 Nginx 内置变量确认：
- 开启
add_header X-Cache-Status $upstream_cache_status;，响应头中出现HIT或REVALIDATED才代表机制生效 - 在 error log 中开启
debug级别（临时），可看到类似cache file:/var/cache/nginx/xxx, if-modified-since:"Wed, 20 Apr 2026 08:00:00 GMT"的记录 - 用
curl -I http://your-proxy/path观察响应头中是否含Age被刷新、X-Cache-Status: REVALIDATED
