proxy_cache_lock_age 是首个回源完成后禁止新回源的冷却期（默认5秒），防止缓存未稳时重复触发；它与 proxy_cache_lock_timeout 分阶段生效：前者控“写入后静默期”，后者控“等待首个结果最大时长”。
proxy_cache_lock_age
不是“等待超时”，而是“允许第二个回源请求触发的冷却时间”。它和
完全不同，作用机制容易混淆——调错会导致缓存更新变慢或并发回源激增。
明确 proxy_cache_lock_age 的真实作用
当第一个请求因缓存 MISS 触发回源并写入缓存后，Nginx 默认会“锁住”该 key 一段时间（默认 5 秒），期间即使缓存已写入、后续请求能直接 HIT，也不会放行新的回源请求。这个“锁住期”就是
控制的。
它的意义在于：防止在缓存刚写入但尚未稳定（比如响应头未完全校验、文件未刷盘）时，立刻有新请求因条件变化（如 header 差异、stale 判定不一致）再次触发回源。本质上是给缓存一个“安全沉淀窗口”。
值设得太小（如 1s）：刚写入就可能被新请求绕过，导致重复回源或 stale 响应被误判
值设得太大（如 30s）：在热点缓存频繁失效场景下，会人为拉长“只允许一个回源”的窗口，拖慢整体更新节奏
合理范围通常是 3–10 秒，具体取决于后端响应稳定性与缓存内容更新频率
与 proxy_cache_lock_timeout 协同配置
控制的是“等待首个回源完成的最大时长”，而
控制的是“首个回源完成后，多久内禁止第二个回源”。二者不是叠加关系，而是分阶段生效：
阶段一（MISS 初始）：多个请求同时到达 → 只放行第一个，其余等待 ≤
阶段二（首个完成）：缓存写入成功 → 进入
冷却期，期间新 MISS 请求仍会等待（而非立即回源）
阶段三（冷却结束）：若此时缓存已过期或被清理，下一个请求才可再次触发回源
例如：
表示：等待最多 5 秒看第一个结果；一旦它完成，接下来 8 秒内即使缓存失效，也不允许新请求去回源——除非超时或主动 bypass。
高负载下需配合 stale 和 background update
单靠调整这两个 lock 参数无法解决高并发缓存更新压力。真正有效的组合是：
启用
：让缓存过期后继续服务旧内容，后台静默刷新
搭配
：后台更新失败或卡住时，仍可用旧缓存顶住流量
把
设为略大于典型后台更新耗时（如后台平均 4s，则设为 6s），确保背景更新有机会完成再开放新回源
这样既避免了用户等待，又限制了并发回源数量，比单纯拉长 lock timeout 更健壮。
验证是否生效的关键检查点
配置后不能只看日志有没有“LOCK”字样，要抓取实际行为：
用
或自定义 header 输出
状态，确认 MISS 是否被合并
观察后端 access log 中同一 URI 的并发请求数量是否明显下降（比如从 50+ 降到个位数）
检查 Nginx error log 是否出现
，如有，说明
过短，而非
问题
注意：若 upstream 返回了
或配置了
，lock 机制会直接跳过，需同步排查响应头控制逻辑
proxy_cache_lock_timeoutproxy_cache_lock_ageproxy_cache_lock_timeoutproxy_cache_lock_ageproxy_cache_lock_timeoutproxy_cache_lock_ageproxy_cache_lock_timeout 5s; proxy_cache_lock_age 8s;proxy_cache_background_update on;proxy_cache_use_stale error timeout updating http_502 http_503;proxy_cache_lock_age$upstream_http_x_cacheHIT/MISS/EXPIRED/STALEcache lock timeoutproxy_cache_lock_timeoutlock_ageCache-Control: no-cacheproxy_ignore_headers