仅加 proxy_cache_use_stale updating 无效，必须同时启用 proxy_cache_background_update on、proxy_cache_lock on 并设置 proxy_cache_lock_timeout，三者协同才能实现请求合并回源与平滑更新。
只加 proxy_cache_use_stale updating 不能解决请求合并回源问题。它本身不触发更新，也不阻止并发回源——真正起作用的是三者协同：必须同时开启 proxy_cache_background_update on、proxy_cache_lock on，并合理设置 proxy_cache_lock_timeout。
为什么 updating 单独配置无效
updating 只是一个“放行许可”：告诉 Nginx “当缓存条目正处于后台更新状态时，允许返回旧内容”。但若没启用后台更新机制，这个状态永远不会出现。缓存一过期，所有请求仍会同步穿透回源，形成风暴。
- Nginx 不会主动预热或定时刷新缓存，
proxy_cache_background_update是“懒加载式触发”——只有用户请求命中“即将过期”的缓存（例如proxy_cache_valid 200 10m，当前已存 9m50s），才会悄悄发子请求去更新 - 若缓存已彻底过期（被
inactive清理），连旧内容都没了，updating条件自然不满足 - 子请求使用相同
proxy_cache_key，但不带原始请求头（如 Cookie、Authorization），需确保后端能接受无认证刷新
必须配套的三项核心配置
缺一不可，否则 updating 形同虚设：
aperture: the L402 aware reverse proxy
下载
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
-
proxy_cache_background_update on;：启用后台子请求机制，让 Nginx 在缓存临界过期时异步拉新数据 -
proxy_cache_lock on;：限制同一 cache key 最多一个请求去回源；其余请求要么等锁释放，要么走 stale 回退 -
proxy_cache_lock_timeout 5s;：建议设为后端 P95 响应时间（如 4–6 秒），避免等待过久卡顿，也防止超时后大量请求同时炸锅回源
搭配 stale 回退提升容错与体验
仅靠 lock + background_update 还不够健壮。加上更全面的 proxy_cache_use_stale，能让系统在多种异常下继续服务：
proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;- 含义：当首个请求回源失败、超时、正在更新、或上游返回 5xx 时，后续请求可立即返回旧缓存，不排队、不降级、不空转
- 效果：95%+ 的请求可秒级响应，真正需要等锁或回源的请求大幅减少，后端压力收敛明显
实际生效的关键边界条件
这些配置不是“永远有效”，有明确前提：
- 后台更新只对
proxy_cache_valid覆盖的状态生效（如 200 响应缓存 10 分钟）；未定义状态（如 304、非 200/302/404）不会触发 updating - 子请求失败（如超时、502）不会重试，但因有
stale error timeout，不影响主响应可用性 - 子请求不经过
limit_req或limit_conn，可能绕过限流——所以更要靠proxy_cache_lock控制并发数 - 若业务对一致性要求极高（如支付结果页），需评估是否适合用
updating；普通列表页、资讯页、静态资源则非常适用
