proxy_cache_lock_age 是 nginx 1.7.8 引入的缓存锁优化参数，设定首请求独占锁的最大时长，超时后允许第二个请求并发回源，缓解高并发下因首请求延迟导致的排队阻塞问题。
proxy_cache_lock_age 是 Nginx 1.7.8 引入的关键调优参数，专用于缓解大规模缓存更新时“单请求锁太久导致后续请求长时间阻塞”的问题。它不替代 proxy_cache_lock_timeout，而是与其协同：前者控制“多久后允许第二个请求也去回源”，后者控制“等待锁释放的最长时间”。在热点接口缓存批量失效、模型文件首次拉取、或上游响应缓慢等场景下，合理设置 proxy_cache_lock_age 能显著提升吞吐与用户体验。
理解 lock_age 的作用机制
当 proxy_cache_lock on 启用后，默认只有第一个未命中缓存（MISS）的请求能回源；其余请求排队等待。但若这个首请求因网络抖动、后端慢或大文件传输耗时过长，所有排队请求就会卡住——直到超时或首请求完成。
proxy_cache_lock_age 改变了这一行为：它设定一个“首请求最长可独占锁的时间”。一旦超过该时间，Nginx 会**主动放行第二个请求也去回源**（仍保持锁逻辑，即第三个请求继续等前两个之一完成），形成有限度的“并发回源”。
这相当于把“串行回源”软化为“最多 N 个并发回源”，N 取决于 lock_age 和实际响应耗时，而非固定值。
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
典型配置与取值建议
该指令必须与 proxy_cache_lock 同级启用，常见搭配如下：
proxy_cache_lock on;-
proxy_cache_lock_timeout 5s;—— 等待锁释放上限，超时则各自回源 -
proxy_cache_lock_age 3s;—— 首请求运行满 3 秒后，第二个请求即可出发
取值逻辑：
- 设为 1–3 秒：适合响应快（如毫秒级 API）、但并发量极高的场景，避免首请求微小延迟引发大面积排队
- 设为 5–10 秒：平衡型选择，覆盖多数后端平均响应（如 2–6 秒），既防卡死又不放大回源压力
- 不建议设为 0 或过小（如 100ms）：会导致频繁触发多路回源，失去锁的意义；也不建议 >15s：基本等同于没开 lock_age
配合 stale 策略降低 lock_age 触发频率
单纯靠 lock_age 治标，结合 proxy_cache_use_stale 才能治本。例如：
proxy_cache_use_stale error timeout updating http_500;- 当首请求正在回源（
updating状态），而第二个请求到达时，若此时已有旧缓存且未过期，Nginx 可直接返回旧内容，根本无需等待或触发 lock_age - 这样既规避了锁等待，又保障了用户可见性，大幅减少对
lock_age的依赖
验证是否生效的关键指标
启用后需通过日志和响应头确认行为符合预期：
- 添加
add_header X-Cache-Status $upstream_cache_status;，观察是否出现UPDATING状态（表示请求进入锁等待队列） - 检查 access log 中相同 key 的多个请求，时间戳间隔是否趋近于
lock_age值（说明第二请求确实在 age 超时后发出） - 对比开启前后，后端 access log 的并发请求数：理想情况是“从数十并发降至 2–4 路”，而非完全归零（这是 lock_age 设计的本意）
