Nginx中应按资源类型精准配置Cache-Control:带哈希的静态资源设max-age=31536000,immutable;普通静态资源设max-age=604800,must-revalidate;HTML设no-cache,must-revalidate;需置于精确匹配location块并加always参数,配合sendfile、gzip等优化提升性能。

直接在 Nginx 的 location 块中用 add_header Cache-Control 控制浏览器怎么存 JS、CSS、图片等静态资源,比只设 expires 更精准、更可靠。
区分资源类型设置不同缓存策略
不同静态资源更新频率不同,缓存方式也应区别对待:
-
带哈希指纹的文件(如
app.a1b2c3.js、style.f4e5d6.css):内容发布后永不变更,可设为长期不可变缓存:add_header Cache-Control "public, max-age=31536000, immutable" always; -
普通静态资源(如
logo.png、icon.svg):更新不频繁但无哈希,建议设为 7 天并允许验证:add_header Cache-Control "public, max-age=604800, must-revalidate" always; -
HTML 文件(尤其是 SPA 入口页):骨架常变,禁止强缓存,每次需校验:
add_header Cache-Control "no-cache, must-revalidate" always;
写在正确的位置,避免被覆盖
Cache-Control 头必须加在最终响应的 location 块里,否则可能被更高优先级的配置覆盖:
Linux 安全审计工具,检查 SSH 配置、开放/监听端口、防火墙规则(ufw/iptables/nftables)、失败登录尝试、sudoers 权限...
- 优先使用精确匹配(如
location = /index.html)或正则匹配(如location ~* \.(js|css|png|jpg)$),不要依赖泛用的location / - 加上
always参数,确保即使返回 304 或错误状态码时头也不丢失 - 若用了
if或多个嵌套location,建议把add_header放在最内层、最匹配的块中
配合基础优化提升交付效率
光设缓存头还不够,这几项系统级配置能加快静态文件读取和传输:
-
sendfile on;:启用内核零拷贝,减少内存复制开销 -
tcp_nopush on;:配合 sendfile,等数据包填满再发,降低网络小包数量 -
open_file_cache max=10000 inactive=30s;:缓存文件句柄和元数据,减少stat()系统调用 -
gzip on;和gzip_types text/css application/javascript image/svg+xml;:对文本类资源压缩,减小体积
验证是否生效
改完配置别急着 reload,先测试再上线:
- 运行
sudo nginx -t检查语法 - 执行
sudo systemctl reload nginx平滑重载 - 用
curl -I https://yoursite.com/style.css查看响应头,确认出现Cache-Control且值符合预期 - 打开浏览器开发者工具 → Network 标签页,刷新页面,观察静态资源状态码是否为
200 (from disk cache)或304










