需配置keys_zone=1300m以稳定支撑千万级URL缓存，按1MB存8000个key计算得出；目录层级设levels=1:2防IO瓶颈；须规避不可热扩容、跨文件系统、内存磁盘职责混淆三大硬约束。
要让
的
内存区域稳定支撑千万级代理资源（比如日均 1000 万唯一 URL），关键不是堆内存，而是
按 key 实际数量精准计算 + 预留缓冲 + 规避硬限制
。
先算清你需要多少 MB 的 keys_zone
存的是每个缓存项的 key 字符串、过期时间、访问计数等元数据，
不存响应体
。实测经验：
✅
1MB 共享内存 ≈ 存 8000 个唯一 key
所以：
日均 1000 万个唯一请求 → 至少需要
向上取整，建议设为
（即 1.3GB）
⚠️ 注意：这个数字基于你实际使用的
粒度。
如果用了
（带完整参数），key 数量可能比仅用
多几倍；务必用日志验证：
目录层级必须匹配高 key 量场景
千万级 key 意味着缓存文件可能超百万甚至千万个。单目录放太多文件会严重拖慢 inode 查找。
✅ 推荐固定用
：
第一级：MD5 最后 1 位 → 16 个目录（0–9,a–f）
第二级：往前取 2 位 → 每个一级目录下最多 256 个子目录
最终单个叶子目录平均承载几千文件，IO 压力可控
❌ 避免
或
：前者退化成单层海量文件，后者生成冗余目录但没实质收益。
绕不开的三个硬约束，千万不能踩
不可热扩容
：
一旦写死，重启 Nginx 才生效；运行中无法增大。上线前必须一次估足，别留“后续再加”的侥幸。
不跨文件系统
：
路径和它的上级挂载点必须在同一磁盘分区。否则会出现
错误，缓存直接失效。
内存与磁盘职责分离
：
只管 key 索引，
才管磁盘用量。即使
装不下所有 key，Nginx 会淘汰旧 key（LRU），但只要磁盘没满、文件还在，命中仍可能成功——只是索引丢了，得重新生成 key 并回源。
一个稳妥的千万级配置示例
说明：
需是独立大容量 SSD 分区，确保有足够 inodes 和 IOPS
比默认 60m 更激进，加快冷 key 清理，缓解 keys_zone 压力
强制跳过临时目录拷贝，减少跨设备风险和延迟
不复杂但容易忽略
proxy_cache_pathkeys_zonekeys_zone10,000,000 ÷ 8000 ≈ 1250 MBkeys_zone=my_cache:1300mproxy_cache_key$scheme$host$uri$is_args$args$uri# 统计带完整 query 的唯一请求（Nginx 默认 access.log 格式）
awk -F'"' '{print $2}' access.log | awk '{print $1,$2}' | sort -u | wc -llevels=1:2levels=1levels=2:2:2keys_zone=my_cache:1300mproxy_cache_pathInvalid cross-device linkkeys_zonemax_sizekeys_zoneproxy_cache_path /data/nginx_cache
levels=1:2
keys_zone=my_cache:1300m
inactive=45m
max_size=50g
use_temp_path=off;/data/nginx_cacheinactive=45muse_temp_path=off