proxy_cache_lock_age控制缓存刷新冷却期，防止高频重刷；它不决定客户端等待时长，真正控制等待的是proxy_cache_lock_timeout。

proxy_cache_lock_age 不是控制“等待响应”的参数，它管的是锁释放后多久才允许下一次更新尝试。很多人误以为它影响客户端等待时长，其实真正决定等待行为的是 proxy_cache_lock_timeout。lock_age 的作用是防止刚刷新完缓存，立刻又被另一个请求抢锁重刷——这在高并发热点场景下特别容易引发无效回源震荡。

proxy_cache_lock_age 的真实定位

它是一个“冷却期”机制，和锁本身无关，也不参与请求排队逻辑。它的值只在以下两个环节起效：

• 当前请求完成回源、写入缓存、释放锁之后
• 下一个同 cache key 的请求试图获取锁时，Nginx 会检查距离上次成功写入缓存是否已超过 lock_age 秒

如果没超，该请求直接跳过锁逻辑（不等、不回源），转而走 proxy_cache_use_stale 流程（比如返回陈旧缓存）；如果已超，才重新进入锁竞争流程。

Umbrel Proxy Manager

高效管理与交互 Umbrel 代理服务，支持 Docker 容器。自动发现运行服务，将内部 Docker IP 映射为可访问的外部地址。

下载

合理设置 proxy_cache_lock_age 的关键原则

• 必须大于等于 proxy_cache_valid 设置的主缓存有效期：否则刚缓存生效就被判定“可刷新”，等于白设。例如 proxy_cache_valid 200 5m，lock_age 至少设为 300s 或略高（如 330s）。
• 不宜过大：设成 10 分钟以上，可能让缓存长期无法更新，尤其当上游内容实际已变更但 Nginx 还在“冷却中”。
• 推荐值范围通常是 cache_valid × 1.1 ~ 1.5：比如缓存 2 分钟，lock_age 设 150s；缓存 10 分钟，设 660s（11 分钟）。

配合 proxy_cache_lock_timeout 才能闭环

单设 lock_age 没用，必须和 lock_timeout 协同：

• proxy_cache_lock_timeout 2s：客户端最多等 2 秒，超时就走 stale
• proxy_cache_use_stale updating：确保超时后能安全返回旧内容
• proxy_cache_lock_age 330s：330 秒内不允许多次刷新，避免高频抖动

这样组合下来，效果是：

• 热点 key 在首次回源后，330 秒内所有新请求都直接返回旧缓存（不等、不争锁、不回源）
• 第 331 秒起，首个请求再次触发锁+回源，其余请求继续等或走 stale
• 整个过程对用户透明，后端压力被压到极低水平

实际配置片段（可直接用）

location /api/ {
    proxy_cache my_cache;
    proxy_cache_valid 200 5m;
    proxy_cache_lock on;
    proxy_cache_lock_timeout 2s;
    proxy_cache_lock_age 330s;
    proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
}

这个配置在模型下载、配置接口、首页 HTML 等典型热点路径上实测稳定，既防雪崩，又保新鲜度。