keys_zone内存不足会导致X-Cache-Status长期为MISS且无报错，因共享内存存key元数据耗尽后拒绝新key写入；需按QPS×缓存生命周期预估大小，建议上浮20%～30%，并按用途隔离配置。
keys_zone 内存不足会导致缓存失效但不报错
现象是 X-Cache-Status 长期为 MISS，日志里看不到明显错误，proxy_cache_valid 也配置了，但就是不缓存。根本原因常是 keys_zone 共享内存耗尽：Nginx 用这块内存存 key 的哈希值、访问次数、过期时间等元数据，满了就拒绝写入新 key，但不会中断请求或报错。
1MB keys_zone 约支持 8000 个缓存 key；若业务有 50 万活跃 URL，至少要配 64MB（500000 ÷ 8000 ≈ 62.5）。更稳妥的做法是按峰值 QPS × 平均缓存生命周期（秒）预估 key 数量：
- QPS = 2000，平均缓存 5 分钟（300 秒）→ 理论并发 key 数 ≈ 60 万 →
keys_zone=my_cache:76m - 若缓存大量短时效资源（如 API 结果仅缓存 60s），则按 QPS × 60 计算，而非固定生命周期
- 实际部署建议上浮 20%～30%，避免高峰期 key 淘汰抖动
keys_zone 大小和 inactive 参数必须协同调整
inactive 控制“多久没被访问就删”，但它只影响磁盘文件清理，不影响共享内存中 key 元数据的驻留。如果 keys_zone 太小，而 inactive=7d，大量冷 key 会持续占着内存不释放，导致热 key 被挤出——结果是缓存命中率低，且 proxy_cache_path 磁盘目录下文件不少，但内存里 key 表已满。
解决方法是让两者节奏匹配：
- 高 QPS + 短生命周期（如 API 缓存 1–5m）→
keys_zone可稍大，inactive=10m或30m，加速元数据回收 - 低频静态资源（如图片、JS/CSS）→
keys_zone可保守些，inactive=7d合理，但需确保内存够存全部活跃 key - 混合场景强烈建议拆分
keys_zone：一个给 API（api_cache:256m），一个给静态资源（static_cache:64m）
不要复用同一个 keys_zone 给不同 proxy_cache 配置
多个 location 块共用一个 keys_zone 名称（比如都写 proxy_cache my_cache），看似省事，实则埋雷：不同 location 的 proxy_cache_valid、proxy_cache_bypass、proxy_cache_lock 行为会互相干扰。最典型的是，某接口因 proxy_cache_use_stale error 返回了过期缓存，结果把整个 my_cache 共享内存里的 key 状态搞乱，连带影响静态资源缓存判断。
真实线上环境应严格按用途隔离：
-
proxy_cache api_cache;对应keys_zone=api_cache:512m，配proxy_cache_valid 200 302 1m; 404 10s; -
proxy_cache static_cache;对应keys_zone=static_cache:128m，配proxy_cache_valid 200 302 1h; - 哪怕只是测试环境，也别图省事合用——调试时无法单独 purge 某类缓存，
proxy_cache_purge会误伤
用 nginx -t 和 /dev/shm 验证 keys_zone 实际占用
nginx -t 不校验 keys_zone 内存是否足够，只检查语法。真正验证得看运行时状态：
- 确认共享内存是否生效：
ps aux | grep nginx查 worker 进程，再用cat /proc/$(pidof nginx)/maps | grep shm，应看到类似/dev/shm/nginx_my_cache的条目 - 查看当前 key 占用率：
curl -s http://127.0.0.1/nginx_status | grep 'cache:'（需启用 stub_status）或直接读/dev/shm/下对应文件大小 - 如果
/dev/shm/nginx_my_cache接近你配置的keys_zone大小（如配了256m，文件大小达 255MB+），说明内存吃紧，必须扩容
共享内存一旦配小，重启 nginx 才能释放，热重载不生效；所以调优时宁可略大，别卡着下限配。
