用 map 动态控制 proxy_cache_valid 是最轻量实时的防击穿手段，可依请求或响应特征秒级分级缓存，需配合 lock、限流、stale 等机制及正确配置验证。
直接用 map 动态控制 proxy_cache_valid 是避免突发流量击穿网关最轻量、最实时的手段。它不依赖 reload、不依赖上游改响应头，只要请求或响应里有可识别信号，就能立刻切换缓存策略，把“强防线”真正变成“活防线”。
按请求特征快速分级缓存
突发流量往往自带指纹：特定 UA（如爬虫工具）、固定渠道参数、特殊设备类型或热点路径。用 map 把这些信号转成 $cache_ttl，再喂给 proxy_cache_valid，就能实现秒级响应。
- 识别
curl、httpie、wget等工具请求，设 TTL = 5s，防刷穿 - 匹配
/promo/、/hot/、/v2026/类 URI，设 TTL = 24h，让热点内容稳住边缘 - 对带
?source=seeding或X-Force-Fresh: true的请求，强制 TTL = 0s，跳过缓存直连后端 - 移动端非微信/QQ 内置浏览器，设 5m；主流浏览器或微信 UA，设 30m–1h
配置要点：正则顺序必须由细到粗，热度规则写在前面；default 不可省略，否则变量为空会导致 proxy_cache_valid 失效。
按上游响应特征动态降级
⚠️ 已弃用 — 该技能已拆分为两个独立技能，以提升模块化程度：**webchat-https-proxy**（HTTPS/WSS 反向代理）和 **webchat-voi...**
当后端开始吃紧，缓存策略要主动“让位”或“托底”，而不是被动等失败。
- 检测到
upstream_status为 502/503，立即将同类请求 TTL 提升至 60s，缓解雪崩压力 - 若
upstream_http_content_type是application/json且响应体 > 1MB，TTL 设为 0s，防止大响应挤占 cache zone - 对
image/*类型，基础 TTL 设为 1h；若 URL 含?v=20260526这类时间戳，额外 +5m 宽限期
⚠️ 注意：$upstream_http_* 和 $upstream_status 只在 proxy_pass 执行后可用，必须配合 proxy_buffering on 和 proxy_cache_use_stale updating，才能让 map 在缓存决策阶段读取到值。
关键配套机制不能少
光调 proxy_cache_valid 不够，得配上“锁”和“闸”，形成组合防护：
-
proxy_cache_lock on;防止同一 key 的大量并发请求同时回源 -
limit_req zone=hotburst burst=100 nodelay;对热点路径加限流，兜住缓存未命中时的冲击 -
proxy_cache_use_stale error timeout updating http_502 http_503;源站异常时仍可返回旧缓存，保服务可用 -
proxy_cache_key中加入$cache_ttl或$arg_source，隔离不同策略的缓存键，避免混用误伤
验证是否生效，加一行调试头：add_header X-Cache-TTL $final_ttl always;
用 curl -I 查看响应头，确认值符合预期。若为空，重点检查 map 的 default 是否遗漏、正则是否被前置规则截断。
不复杂但容易忽略
