关键是要关闭proxy_cache_lock，改用proxy_cache_use_stale updating与proxy_cache_background_update配合实现无锁流式缓存；缓存键应精简为"$scheme$host$uri"等稳定维度，并忽略Set-Cookie、Vary、Cache-Control等干扰头以确保命中率。
要让 proxy_cache 在流式响应（如 SSE、长连接 API、Next.js SSR 流式渲染）中真正降低 TTFB（首字节时间）毛刺，关键不是“缓存整个响应”，而是让 Nginx 在缓存有效期内**跳过回源、立即建立连接并透传字节流**——这要求缓存策略与流式语义对齐，而非套用静态资源那一套。
必须关闭阻塞式缓存锁
流式场景下，proxy_cache_lock on 会强制等待首个请求完整返回才释放缓存，彻底破坏流式意义。Nginx 不支持对“正在传输中的流”加锁复用，所以：
- 直接禁用：
proxy_cache_lock off; - 若仍需防击穿，改用
proxy_cache_use_stale updating+proxy_cache_background_update on：用户请求立刻拿到旧缓存流，后台悄悄刷新 - 绝不可配
proxy_cache_lock_timeout，它在此场景无实际约束力，反而干扰调试判断
缓存键必须排除动态干扰因子
流式接口常带临时 token、trace_id、时间戳等 query 或 header，若写进 proxy_cache_key，会导致命中率归零。应只保留稳定维度：
WebChat Voice Proxy
下载
⚠️ 已弃用 — 该技能已拆分为两个独立技能，以提升模块化程度：**webchat-https-proxy**（HTTPS/WSS 反向代理）和 **webchat-voi...**
- 推荐键：
proxy_cache_key "$scheme$host$uri";（去掉$args和所有 cookie/header 变量） - 若业务允许按路径级缓存（如
/api/live-feed全局一致），甚至可简化为：proxy_cache_key "$uri"; - 务必配合
proxy_ignore_headers Set-Cookie Vary，避免上游乱设的头导致缓存被跳过
显式允许流式响应进入缓存
默认情况下，Nginx 对非 200/301/302 响应不缓存；而流式接口常返回 200 OK 但带 Content-Type: text/event-stream 或 application/json-seq。只需确保：
-
proxy_cache_valid 200 5m;已存在（无需额外声明 MIME 类型） - 上游响应中不要带
Cache-Control: no-cache或max-age=0；如有，用proxy_ignore_headers Cache-Control覆盖 - 不依赖
ETag或Last-Modified，流式内容通常无稳定校验值，proxy_cache_revalidate在此场景无效且增加延迟
验证是否真正绕过源站
流式缓存生效的标志是：TTFB 稳定在亚毫秒级，且无后端处理耗时。验证方式：
- 加调试头：
add_header X-Cache-Status $upstream_cache_status; - 用
curl -v请求，观察响应头中X-Cache-Status: HIT是否持续出现 - 检查 Nginx error log（设为 info 级），搜索
cache miss或upstream sent no valid response等线索 - 对比开启前后
time curl -s URL | head -c 1的耗时分布，毛刺应明显收敛
