nginx不原生采用lru算法，其缓存淘汰本质是时间驱动：proxy_cache_valid控制有效期，inactive删除长期未访问文件，max_size超限时按fifo+过期优先清理。
Nginx 本身**不原生采用 LRU 算法作为缓存过期策略**。它的默认缓存淘汰机制是基于**时间驱动（time-based）** 的，而非访问热度或使用频次。所谓“Nginx 使用 LRU”，是一种常见误解——实际配置中若看到类似行为，通常是人为模拟或第三方模块介入的结果。
nginx 缓存真正的过期控制方式
Nginx 的 proxy_cache 模块依赖三类时间参数协同工作，共同决定缓存是否可用或是否应被清理：
-
缓存有效期（
proxy_cache_valid）：指定某类响应状态码（如 200、404）可缓存的最长时间。超时后，该缓存条目变为“过期但未删除”，后续请求会触发后台校验（revalidate）或直接回源刷新。 -
缓存最大保留期（
inactive参数）：在proxy_cache_path中设置，例如inactive=60m。它表示：**如果一个缓存文件在 60 分钟内没有任何请求命中（即完全未被访问），Nginx 的 cache manager 进程就会将其物理删除**。这是最接近“LRU 思想”的机制，但它只看“是否被访问”，不记录访问顺序，也不维护链表结构。 -
缓存总大小限制（
max_size）：当磁盘缓存占用超过设定上限，Nginx 会启动清理流程。此时它**优先删除最早创建且已过期的文件**（按文件修改时间mtime），而不是按“最久未访问”排序。这本质上是 FIFO（先进先出）+ 过期优先的混合策略，不是 LRU。
为什么 nginx 没有内置 LRU 实现
实现严格 LRU 需要持续追踪每个缓存项的最后访问时间，并在内存中维护有序结构（如双向链表 + 哈希表），这对高并发反向代理场景存在明显瓶颈：
- 每次请求都要更新元数据并调整链表位置，带来额外锁竞争和内存开销；
- 磁盘缓存的 I/O 特性（随机读写慢、顺序删除快）与 LRU 要求的频繁重排序不匹配；
- Nginx 设计哲学强调轻量、确定性与低延迟，
inactive参数已能覆盖绝大多数冷热分离需求，无需复杂算法。
如何在 nginx 场景中近似实现 LRU 效果
若业务确需更精细的热度感知淘汰（例如 CDN 边缘节点保护热点资源），可通过以下方式逼近 LRU 行为：
-
缩短
inactive时间窗口：设为 5–10 分钟，加快冷数据清理速度，使缓存池更倾向保留近期活跃内容； -
配合
proxy_cache_use_stale：允许在后台更新时继续提供旧缓存，降低因频繁淘汰导致的回源冲击； -
使用外部缓存层（如 Redis + LRU）：将高频动态内容前置到支持
allkeys-lru淘汰策略的 Redis 中，Nginx 仅作静态资源代理； -
定制模块或 Lua 脚本（OpenResty）：通过
lua_shared_dict维护访问时间戳与权重，结合定时任务模拟 LRU 排序逻辑，但需自行承担性能与一致性成本。
与其他系统对比：LRU 真正在哪起作用
真正广泛落地 LRU 的场景集中在**内存受限且访问模式高度局部化**的系统中：
-
Redis：通过
volatile-lru/allkeys-lru策略，在内存满时淘汰最久未使用的 key； - 浏览器缓存：Chromium 内核用 LRU 管理内存中的 script/CSS 解析结果；
- LevelDB/RocksDB Block Cache：用 LRU 高效管理内存中热数据块，减少磁盘随机读；
-
操作系统页缓存：Linux 的
page reclaim机制虽非纯 LRU，但借鉴其思想设计了多级 LRU list（active/inactive anon/file）。
