proxy_cache需分层配置才能优化回源带宽：静态资源设长TTL并配immutable，HTML设短TTL+revalidate，动态接口原则上不缓存，低频资源启用min_uses和map跳过，配合lock、stale、background_update防击穿，最后通过X-Cache-Status和流量监控验证效果。
直接配置 proxy_cache 本身不能“自动优化回源带宽成本”，关键在于分层控制缓存对象、精准设定生命周期、防止无效回源，并让缓存真正被复用。全站加速项目中，不同资源特性差异大，统一策略反而浪费空间或引发一致性风险。
按资源类型分层设置缓存策略
静态资源（.js、.css、.png、.woff2、矢量瓦片等）更新极少，应设长 TTL：
-
proxy_cache_valid 200 304 1y;（一年内不主动回源） - 配合
Cache-Control: public, immutable响应头，浏览器和 Nginx 都不会发起条件请求 - 若无法改文件名，启用
proxy_cache_revalidate on;，在过期后轻量验证是否可复用
HTML 页面（首页、列表页、详情页）需兼顾新鲜度与性能：
-
proxy_cache_valid 200 304 10m;（10 分钟后进入可验证状态） - 搭配
proxy_cache_revalidate on;，过期后发If-None-Match或If-Modified-Since请求 - 必须确保后端返回稳定
ETag（如内容 MD5）或Last-Modified，否则 304 永远不生效
动态接口（含用户态、实时数据、登录态相关）原则上不缓存：
aperture: the L402 aware reverse proxy
下载
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
- 显式跳过：
proxy_cache_bypass $cookie_user_id $arg_nocache; - 若需兜底降级，仅缓存错误响应：
proxy_cache_valid 404 500 502 503 504 1m; - 避免缓存
POST，除非确认幂等且无副作用
控制缓存写入门槛，避免低频资源污染缓存池
高频访问才值得落盘，否则磁盘 IO 和内存开销得不偿失：
-
proxy_cache_min_uses 3;：同一 URL 至少被请求 3 次，第 3 次响应才写入缓存 - 对埋点、上报、A/B 实验等低频路径，用
map显式关闭缓存：map $request_uri $skip_cache { ~*\/track\/|~*\/abtest\/ 1; default 0; }<br>proxy_cache_bypass $skip_cache;
防击穿、保可用，减少无效回源次数
缓存失效瞬间的并发请求会打爆源站，必须设防：
-
proxy_cache_lock on;：同一 key 的首个未命中请求回源，其余等待 -
proxy_cache_lock_timeout 200ms;：超时后放行，避免长时间阻塞 -
proxy_cache_use_stale updating error timeout http_500;：缓存正在更新或源站异常时，仍返回旧内容 -
proxy_cache_background_update on;：后台异步更新缓存，前台不感知
验证是否真实节省带宽
配置只是开始，必须观测实际效果：
- 加响应头：
add_header X-Cache-Status $upstream_cache_status;，查看是HIT、MISS还是UPDATING - 用
curl -I检查关键资源是否返回304，响应体是否为空，仅含头部（约 200–500 字节） - 对比开启前后源站的流量监控：重点关注
200响应字节数下降比例，而非请求数
