proxy_cache_lock 不适用于纯静态资源防雪崩，因其仅作用于代理回源场景；静态资源应由 nginx 直接服务（如 root/try_files），而非 proxy_pass 回源；仅当静态资源需动态生成或鉴权（即伪静态）时，才需配合 proxy_cache、lock、stale 及统一 key 等策略协同防击穿。

直接说结论：proxy_cache_lock 本身不解决静态资源回源雪崩，因为它根本不该用在静态资源上。真正要防雪崩，得先让静态资源 不走回源——Nginx 必须自己响应，而不是转发给后端。

静态资源不该触发 proxy_cache_lock

proxy_cache_lock 只对「缓存未命中且走代理」的请求起作用。而静态文件（.js、.css、.png 等）本应由 Nginx 直接读取磁盘返回，压根不经过 proxy_pass 和后端。一旦你发现这些资源还在回源，说明配置出错了：

• 检查 location 是否误配了正则匹配 + proxy_pass，例如：
  location ~* \.(js|css|png)$ { proxy_pass http://backend; } → 这是典型错误，必须删掉
• 改用 try_files 或 root 显式服务静态文件，比如：
  location /static/ { alias /data/www/static/; expires 1y; add_header Cache-Control "public, immutable"; }
• 用 curl -I 验证响应头：状态码 200 + 没有 X-Powered-By、Server: nginx 后没带 upstream 信息，才说明真由 Nginx 直接返回

只有极少数“伪静态”场景才需要 lock

当静态资源需动态生成或权限控制时（如带签名的临时图片、鉴权 PDF），它就不再是纯静态，而是走后端处理。这时才可能并发回源，才需要 proxy_cache_lock：

FastAPI Flask Proxy

FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。

下载

• 确保已定义缓存区：
  proxy_cache_path /var/cache/nginx/proxy_cache keys_zone=static_cache:256m inactive=1h use_temp_path=off;
• 在对应 location 中启用缓存与锁：
  

  proxy_cache static_cache;<br>proxy_cache_lock on;<br>proxy_cache_lock_timeout 5s;

• 统一 key，剔除干扰参数：
  proxy_cache_key "$scheme$host$request_uri";（忽略 ?t=xxx、?v=1.2.3 等）
• 屏蔽后端干扰头：
  proxy_ignore_headers Set-Cookie Cache-Control Expires;

光开 lock 不够，必须加 stale 和长有效期兜底

lock 只能把并发变串行，但首个请求失败或超时，等待队列里的请求仍会放弃并各自回源。所以必须搭配容错策略：

• 允许返回过期缓存应对异常：
  proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
• 为这类资源设较长缓存时间：
  proxy_cache_valid 200 302 24h;（MISS 越少，锁竞争越弱）
• 开启后台异步更新：
  proxy_cache_background_update on;（避免用户卡在等待中）

验证是否真生效

别只看配置，要观测实际行为：

• 加响应头：add_header X-Cache-Status $upstream_cache_status;
• 并发压测同一 URL（如 ab -n 30 -c 15），观察后端 access log —— 开启 lock 后应仅记录 1 条，而非 15 条
• 首次请求返回 MISS，紧随其后的请求若返回 HIT 或 STALE，说明锁+stale 协同生效；若仍是 MISS，说明 key 不一致或 location 未命中缓存配置