很多人第一次给 Nginx 配缓存，往往能抄出一份可运行配置，却说不清缓存到底存到哪里、什么响应会被缓存、不同请求又是怎么区分的。本文就用一组最基础的配置，把缓存区域、缓存策略和上线前检查拆开说明，读完后你不仅能把策略配起来，也能判断哪些参数应该按业务继续调整。

Nginx 缓存配置先看哪几个指令

在反向代理场景里，Nginx 的缓存策略通常围绕三个核心指令展开：proxy_cache、proxy_cache_valid、proxy_cache_key。前者决定“用哪个缓存区”，中间这个决定“缓存多久”，最后这个决定“哪些请求算同一个缓存对象”。

如果这三项没有配清楚，缓存即使能工作，也很容易出现命中率低、缓存混用或者过期策略不合理的问题。

先在 http 块里定义缓存区域

第一步是在 nginx.conf 的 http 块中定义缓存区域：

http {
    # ...
    proxy_cache_path /tmp/nginx levels=1:2 keys_zone=my_cache:10m max_size=1g inactive=60m use_temp_path=off;
    # ...
}

这条 proxy_cache_path 指令决定了缓存文件放在哪里，以及这块缓存区的基本容量和淘汰方式。这里定义了一个名为 my_cache 的缓存区域，物理路径是 /tmp/nginx。

这条 proxy_cache_path 分别控制什么

可以按字段来理解这条配置：

• /tmp/nginx：缓存文件的存放路径。
• levels=1:2：控制缓存目录层级，避免单目录下文件过多。
• keys_zone=my_cache:10m：定义缓存区名称为 my_cache，并分配 10MB 内存存放缓存键元数据。
• max_size=1g：限制缓存最大磁盘容量为 1GB。
• inactive=60m：缓存项在 60 分钟内未被访问，就会被视为失效。
• use_temp_path=off：不走临时目录，直接写入缓存目录。

这一步更像是在给后续策略准备“缓存仓库”。如果缓存区本身没有先定义好，后面的 proxy_cache my_cache; 就无从引用。

在 server 块中绑定具体缓存策略

缓存区定义完成后，再到 server 块里给请求真正套用缓存规则：

server {
    # ...
    location / {
        proxy_pass http://backend_server;
        proxy_cache my_cache;
        proxy_cache_valid 200 302 10m;
        proxy_cache_valid 404 1m;
        proxy_cache_key "$scheme$request_method$host$request_uri";
        add_header X-Proxy-Cache $upstream_cache_status;
    }
    # ...
}

这段配置表示：所有进入这个 location / 的请求，都会先转发到 http://backend_server，并使用前面定义好的 my_cache 缓存区。

按状态码设置不同缓存时长

proxy_cache_valid 用来给不同响应状态设置缓存时间：

• proxy_cache_valid 200 302 10m;：200 和 302 响应缓存 10 分钟。
• proxy_cache_valid 404 1m;：404 响应只缓存 1 分钟。

这种写法的价值在于，缓存不是“一刀切”。正常页面可以适当放长，错误页则通常要更短，避免异常结果被长时间保留。

为什么要单独定义 proxy_cache_key

proxy_cache_key 决定一条请求最终对应哪个缓存键：

proxy_cache_key "$scheme$request_method$host$request_uri";

这里把 $scheme、$request_method、$host 和 $request_uri 组合在一起，作用是把不同协议、不同请求方法、不同主机名以及不同 URI 的请求区分开。

如果缓存键设计得过于简单，原本不该共用缓存的请求就可能读到同一份结果；如果设计得过细，又可能导致缓存碎片太多，命中率下降。这个示例属于比较常见、也比较稳妥的基础写法。

用响应头判断缓存有没有命中

这一行配置主要是为了排查效果：

add_header X-Proxy-Cache $upstream_cache_status;

加上后，响应头里会出现 X-Proxy-Cache 字段，常见值包括 HIT 和 MISS。这能帮助你快速确认请求到底是命中了缓存，还是回源到了上游服务。

保存后先测试，再重新加载 Nginx

配置写完后，不要直接重载，先测试语法：

sudo nginx -t
sudo nginx -s reload

sudo nginx -t 用于检查配置是否合法；确认无误后，再通过 sudo nginx -s reload 让新策略生效。

生产环境里该怎么继续调整

上面的示例已经能形成一套可用的基础缓存策略，但在线上环境里，通常还需要根据业务进一步细调。

• 静态资源：可以适当延长缓存时间，减少回源压力。
• 动态页面：应缩短缓存时间，必要时直接禁用缓存。
• 缓存路径和容量：根据磁盘空间与访问量调整 /tmp/nginx、max_size=1g 等参数。
• 失效时间：结合内容更新频率调整 inactive=60m 和各类 proxy_cache_valid。

归根结底，Nginx 缓存策略并不复杂，难点主要在于把“缓存区定义”“缓存时长”和“缓存键设计”这三件事配合起来。只要先理解每个指令各自控制的范围，后续针对静态资源、动态接口或异常响应做精准控制就会容易很多。