调大 keys_zone 内存容量并精简缓存键设计，避免元数据频繁淘汰和路径遍历开销；增大 keys_zone 减少假性 miss，简化 proxy_cache_key 降低哈希开销，优化 levels 减轻 inode 查找压力，禁用 use_temp_path 消除冗余系统调用。
核心是调大 keys_zone 内存容量并精简缓存键设计，避免元数据频繁淘汰和路径遍历开销。
增大 keys_zone 容量，减少 key 淘汰导致的假性 MISS
keys_zone 专用于存储缓存键（key）及其元数据（如过期时间、状态），不存响应体。容量不足会强制淘汰旧 key，即使对应文件还在磁盘上，也会造成“缓存存在但查不到”的假性 MISS，引发回源压力。
- 64MB 可容纳约 12 万～25 万个 key（每个 key 占 256–512 字节），适合热点 URL 在 10 万级的场景
- 若业务有 50 万以上高频 URL（如商品页、用户主页），建议直接设为 128m 或 256m
- 用
nginx -T | grep keys_zone确认实际分配值；监控proxy_cache_miss指标，长期高于 15% 就要优先检查 keys_zone 是否偏小
简化 proxy_cache_key，降低哈希与比对开销
缓存键越长、变量越多，计算 hash、字符串比对、内存占用就越高。默认 $scheme$proxy_host$request_uri 已较合理，但仍有优化空间：
aperture: the L402 aware reverse proxy
下载
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
- 避免无意义变量：如不用
$args就别加，尤其当 URL 带大量随机参数（?t=123456789）时，会导致同一资源被拆成多个 key - 统一大小写或过滤空格：后端可能返回不同格式的 header，可在 key 中标准化，例如
proxy_cache_key "$scheme$request_method$host$uri";（去掉$args和易变 header） - 对 API 类接口，可按业务维度聚合：比如只取
/api/v1/user/(\d+)中的 ID 段，用正则提取后构造 key，而非完整$request_uri
调整目录层级 levels，减轻 inode 查找压力
proxy_cache_path 的 levels 参数影响磁盘目录结构，间接影响内存中路径解析和 key 查找效率：
-
levels=2（即最多 256 个一级子目录）比levels=1:2（最多 4096 个二级子目录）路径更扁平，减少多级目录遍历开销 - 高并发小文件场景下，深路径（如
levels=1:2:2）会显著增加内核 inode 查找耗时，尤其在 HDD 或负载高的 NVMe 上 - 配合更大的 keys_zone（如 256m），能进一步提升 key 元数据的内存命中率，减少磁盘元数据读取
禁用 use_temp_path，消除冗余内存与系统调用
虽然 use_temp_path 主要影响 I/O 路径，但它也带来额外内存和上下文开销：
- 开启时，Nginx 需为每个响应维护临时文件句柄、两次 write 系统调用、一次 rename，涉及更多内存分配与锁竞争
- 关闭后（
use_temp_path=off），响应直写目标缓存路径，减少中间状态管理，key 的创建与文件落盘更同步，元数据更新更轻量 - 注意：必须确保
proxy_cache_path所在分区有足够空间且权限正确，否则缓存会静默失败
