缓存命中率取决于请求特征、配置规则、缓存键设计与状态流转；需清洗无意义参数、分层设置过期时间、拦截不缓存请求、记录并分析$upstream_cache_status以精准调优。
缓存命中逻辑不是“开了 proxy_cache 就自动变高”的事，而是由请求特征、配置规则、缓存键设计、状态流转共同决定的。调优重点不在堆空间或加内存，而在让“该进缓存的进得准、该留久的留得住、该命中的不绕路”。
缓存键（proxy_cache_key）必须收敛且稳定
默认的 $scheme$host$request_uri 看似合理，但极易被无意义参数破坏一致性——比如带跟踪用的 ?utm_source=xxx、时间戳 ?t=1718234567 或随机 token，会导致同一资源生成多个缓存副本。
- 用
map提前清洗 URI：剥离 query 中的非语义参数，只保留影响内容的字段（如?id=123&lang=zh） - 对 Cookie 或 Header 做精准控制：除非业务强依赖（如用户等级），否则避免把
$cookie_user_id直接写进 key - 静态资源建议固定 key：例如
proxy_cache_key "$uri";，忽略大小写和 query，配合proxy_ignore_headers Cache-Control;防后端干扰
缓存生命周期要分层分级，不能一刀切
所有响应共用一个 proxy_cache_valid 200 10m 是命中率低的主因之一。不同内容更新节奏差异极大，强制统一过期只会导致频繁回源或内容陈旧。
- HTML 页面：按业务更新周期设为 1–5 分钟，配合后端主动 purge 或 stale-while-revalidate
- API 接口：区分读写，只缓存 GET 类只读接口；对用户专属数据（如 /api/profile）禁用缓存或使用细粒度 key
- 静态文件（js/css/img）：直接设为 1 年，并在文件名中嵌入哈希（
main.a1b2c3.js），前端用Cache-Control: public, max-age=31536000
主动干预未命中路径，减少无效回源
MISS 不等于必须转发——有些请求本就不该缓存，有些则可降级兜底；放任它们穿透，既浪费后端资源，又污染缓存统计。
- 用
proxy_cache_bypass拦截明确不缓存的请求：例如含X-No-Cache头、或匹配/admin/.*的路径 - 用
proxy_cache_min_uses 2防止冷请求占位：只有被访问至少两次才入库，避免缓存大量一次性的搜索页或错误路径 - 对 404、50x 响应也做短时缓存（
proxy_cache_valid 404 1m; proxy_cache_valid 500 502 503 504 10s;），防雪崩式重试打垮后端
命中状态必须可观测、可归因
没有监控的缓存调优就像蒙眼开车。光看整体命中率数字没用，关键要拆解 “谁没命中？为什么没命中？”
- 在日志中固定记录
$upstream_cache_status，例如：log_format cache_fmt '$remote_addr [$time_local] "$request" $status $body_bytes_sent "$upstream_cache_status"'; - 定期用脚本统计各状态占比：
awk '{print $9}' access.log | sort | uniq -c | sort -nr - 重点关注
BYPASS（规则误拦）、EXPIRED（过期太短）、MISSTOCACHE（未达 min_uses）等细分原因，而非只盯 HIT/MISS 总比
