proxy_cache_lock 不能单独解决缓存击穿，仅在同 key 瞬时未命中时生效，需结合 cache_path、proxy_cache、cache_key 优化、lock_timeout、stale 机制及日志验证构成完整防护链。

proxy_cache_lock 不能单独解决缓存击穿引发的回源雪崩，它只在“同一缓存 key 瞬时未命中”时起作用——也就是热点资源刚好过期、大量请求同时抵达的那几秒。要真正缓解这种场景，必须把锁当作一个环节，嵌入到完整的缓存防护链中。

基础配置：锁得有地方落脚

没有缓存区，lock 就是空转：

• 在 http 块中定义缓存路径和共享内存区，例如：
  proxy_cache_path /var/cache/nginx/proxy_cache levels=1:2 keys_zone=my_cache:512m inactive=3h use_temp_path=off;
• keys_zone 名称（如 my_cache）后续会被引用，大小按每 1MB 支持约 8000 个 key 估算
• 确保磁盘路径存在，且 Nginx 进程有读写权限（Linux/macOS 下注意 SELinux 或 umask 限制）
• 在目标 location 中必须启用缓存：
  proxy_cache my_cache; —— 这是 lock 生效的前提

精准锁定：让同一类请求共用一把锁

锁不是全局互斥，而是按 cache key 绑定。key 不一致，就等于没锁：

WebChat Voice Proxy

⚠️ 已弃用 — 该技能已拆分为两个独立技能，以提升模块化程度：**webchat-https-proxy**（HTTPS/WSS 反向代理）和 **webchat-voi...**

下载

• 默认 key 包含 $args，/api/product?id=1001 和 /api/product?id=1002 是两个独立 key，各自触发回源
• 若想对所有商品查询统一加锁，显式简化 key：
  proxy_cache_key "$scheme$host:/api/product";
• 剔除干扰项更稳妥：
  proxy_cache_key "$scheme$host$request_uri";（忽略全部 query 参数）
• 避免将 Cookie、随机 header（如 $http_x_trace_id）或时间戳参数（?t=1715446200）加入 key

设好超时与退路：不卡用户，也不压垮后端

锁本身不加速后端，只控制并发节奏。超时和 stale 才决定系统是否稳得住：

• proxy_cache_lock_timeout 5s：推荐 3–8 秒。太短（如 1s），等待请求快速放弃锁并发回源；太长（如 30s），用户明显卡顿
• proxy_cache_use_stale error timeout updating http_500–504：当首个请求回源失败、超时或正在更新时，后续请求可直接返回旧缓存（stale），避免全部排队或降级失败
• proxy_cache_valid 200 302 30s：对 API 接口延长有效时间，从源头减少 MISS 次数；静态资源可设为 1h 甚至更久

验证是否真生效：别靠猜，看日志和响应头

配置完必须验证，否则等于没配：

• 在 location 中添加：
  add_header X-Cache-Status $upstream_cache_status;
• 用 curl -I 查看响应头：首次请求应为 X-Cache-Status: MISS，紧随其后的并发请求应出现 HIT（说明锁成功复用结果）或仍为 MISS（说明 key 不一致或配置未生效）
• 压测验证：用 ab -n 20 -c 10 并发请求同一 URL，开启 lock 后，后端访问日志应仅记录 1 条，而非 10 条