登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  文章 >  软件教程

开发工具 Nginx 设置缓存头 怎样处理

来源:17golang原创

时间:2026-10-22 06:49:33 206浏览 收藏

开发工具 Nginx 设置缓存头,通常不是把一条 add_header 放进任意位置就结束了。先按资源类型划分缓存策略,再把配置放在实际命中的 server 或 location 中,最后直接查看响应头,才能判断是否生效。

官方地址:https://nginx.org/

下面的示例只讨论静态资源缓存,不把登录接口、个性化接口和带敏感数据的响应放进公共缓存。

静态文件可以使用较长的 max-age,动态接口通常使用不缓存策略。配置后要以真实请求返回的响应头为准;如果嵌套的 location 重新声明了 add_header,父级同名配置可能不再按预期继承。

先确定要缓存什么

先把资源分成两组:带内容指纹的 JavaScript、CSS、字体和图片适合长缓存;HTML、接口 JSON 或会随用户变化的内容则应缩短缓存,必要时直接禁止缓存。这样做比给整个站点统一加一个月的缓存时间更容易回滚。

资源建议方向核对重点
带版本文件名的静态资源public, max-age=31536000, immutable文件名变更后再发布新内容
普通静态文件短一些的 max-age更新后是否能及时看到新文件
动态接口和 HTMLno-cache 或按业务设置不能把用户数据放进公共缓存

在正确作用域设置缓存头

静态文件可以单独放在资源路径的 location 中。下面的配置使用 Nginx 原生的 add_header,并保留中文注释说明资源边界;expires 会同时参与 Expires 和 Cache-Control 的生成。

server {
    listen 80;

    # 只给带指纹的静态资源设置较长缓存,避免影响接口响应
    location ~* \.(?:css|js|png|jpg|jpeg|gif|svg|woff2)$ {
        # 让浏览器和共享缓存保存一年,发布时用新文件名刷新内容
        add_header Cache-Control "public, max-age=31536000, immutable";
        expires 365d;
    }

    # 动态页面不沿用静态资源的缓存策略
    location /api/ {
        add_header Cache-Control "no-cache";
        expires -1;
        proxy_pass http://app_backend;
    }
}
Nginx 静态资源缓存头配置入口与作用域的原创界面说明图
图1:操作示意图,查看静态资源 location、缓存字段和作用域之间的配置关系;这是原创说明图,不是软件截图。

这里的关键不是把两个指令机械地复制到所有路径,而是让静态资源和动态接口进入不同的匹配范围。add_header 默认只对一组指定状态码添加响应头;如果错误响应也必须带上该字段,可以按需加上 always,但要先确认这符合你的错误页策略。

保存后重新加载,再核对返回头

改完配置后,使用部署环境已有的配置检查和重新加载流程。示例命令只展示操作意图,不代表本文在本机执行过:

# 先检查配置语法,再让工作进程加载新配置
nginx -t
nginx -s reload

随后请求一个明确的静态文件,重点看响应头而不是只看页面是否能打开:

# 只查看响应头,便于确认缓存策略和过期时间
curl -I https://example.com/assets/app.js

预期可以看到类似下面的字段。具体日期会随请求时间变化,判断时优先看缓存策略和资源类型是否匹配:

HTTP/1.1 200 OK
Cache-Control: public, max-age=31536000, immutable
Expires: Tue, 22 Oct 2027 00:00:00 GMT
Nginx 响应头中 Cache-Control 与 Expires 的结果核对原创界面说明图
图2:结果示意图,核对请求状态、Cache-Control、Expires 和嵌套作用域提醒;这是原创说明图,不是运行截图。

缓存头不生效时先查这几处

一是匹配范围不对。 请求路径没有进入预期的 location,配置自然不会出现。先对照请求 URL 和资源后缀,再看实际命中的 server 配置。

二是被子级配置改变了继承。 Nginx 的 add_header 有继承规则:当前层一旦声明了自己的 add_header,父层的声明不一定继续生效。尤其要检查正则 location、代理路径和专门处理错误页的配置。

三是状态码不在默认范围。 默认情况下,add_header 并不是对所有状态码都生效。若只在 404 或 500 响应上看结果,不能直接据此判断静态资源配置失败。

四是上游响应头参与了最终结果。 反向代理场景里还要看上游是否返回了自己的缓存字段,以及 Nginx 是否在代理层修改或隐藏了它们。最终判断仍以客户端收到的响应头为准。

相关问题

为什么浏览器仍然请求静态文件?缓存头只影响缓存复用,不保证浏览器永远不发请求;资源可能被手动刷新、缓存已过期,或请求带有重新验证条件。

expires 365d 和手写 Cache-Control 会冲突吗?它们分别参与不同的响应头生成。若手写策略与过期时间表达的意图不一致,先统一缓存目标,再保留最容易核对的一组配置。

什么时候不应该设置 public?含用户身份、权限结果或个性化数据的响应不要直接按公共缓存处理,应结合接口语义选择 private、no-cache 或完全不缓存。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>