5个站点挨个配Nginx缓存花了2小时30个站用include统一模板加版本号策略5分钟搞定页面加载速度还快了47%：站群缓存批量管理不用每个站点重写一遍Nginx配置文件的正确方式

做站群的人早晚会遇到这个问题：网站数量从5个涨到30个，某天发现首页加载要3秒多，Google PageSpeed Insights一片红。然后你打开Nginx配置文件，发现最早的几个站配了expires和gzip，中间一批站只配了gzip没配缓存头，最新的几个站什么缓存配置都没有。补一个站大概20分钟，30个站就是10小时，中间还可能改错一行导致整个站502。

这不是个例。在Google搜索控制台里，页面体验那一栏的Core Web Vitals数据，跟缓存配置好坏有直接关系。一个LCP（最大内容绘制）超过2.5秒的页面，哪怕内容写得再好，排名也很难上去。今天把多站点缓存批量配置这件事从头到尾拆开：缓存策略怎么选、按文件类型怎么分、30个站怎么统一模板化、更新资源怎么让缓存即时失效、CDN缓存和浏览器缓存怎么协同。

一、缓存该管什么：浏览器缓存、服务器缓存、CDN缓存三层各管各的

很多人一说"配缓存"，第一反应就是在Nginx里加一行expires 30d;。这其实只配了浏览器缓存这一个层面。一个完整的缓存体系至少有三层，每层失效机制不一样，配置方式也不同。

三层之间有先后顺序。用户访问一个页面时，先看浏览器本地有没有、没过期就用；本地没有或过期了，请求发到CDN节点；CDN节点有且没过期就直接返回；CDN也没有才回源到你的Nginx服务器。如果源站Nginx还配了proxy_cache，那Nginx也不会每次去后端PHP动态生成，而是拿缓存结果直接返回。

二、按文件类型分缓存时长，一张表就能说清楚

缓存策略的核心原则就一条：内容越"不可变"的，缓存时间越长；内容越可能变的，缓存时间越短或直接不缓存。文件名的稳定性直接决定了你能设多长的缓存。带版本hash的文件名（如logo.a3f2b.png）可以放心设一年；不带版本号的CSS文件设30天都有风险。

这里有一个关键细节：immutable这个指令很多人没加。它的作用是告诉浏览器"这个资源在缓存有效期内绝对不会变"，这样即使用户按了F5强制刷新，浏览器也不会发送带If-Modified-Since的条件请求去服务器验证。对于带hash的静态资源，加了immutable可以减少大量无意义的304响应。

三、Nginx配置怎么写：一个模板文件搞定所有站点

到了实操环节。30个站点，每个站点的server块里都写一遍expires和Cache-Control，改一次就要改30个地方。正确做法是把缓存配置抽成一个独立的conf文件，所有站点用include引用。

先创建缓存策略模板文件。在Nginx配置目录下新建/etc/nginx/conf.d/cache-policy.conf，把所有按文件类型的缓存规则集中写在这里：

# ============================================# 缓存策略统一模板 cache-policy.conf# 所有站点通过 include 引用，改一处全站生效# ============================================# 1. 图片文件：1年强缓存 + immutablelocation ~* \.(png|jpg|jpeg|webp|gif|ico|svg|bmp)$ {expires 365d;add_header Cache-Control "public, max-age=31536000, immutable";add_header Vary "Accept-Encoding";}# 2. 字体文件：1年强缓存location ~* \.(woff2|woff|ttf|eot|otf)$ {expires 365d;add_header Cache-Control "public, max-age=31536000, immutable";add_header Vary "Accept-Encoding";}# 3. 带hash的CSS/JS：1年强缓存 + immutable# 文件名示例：main.a3f2b91.js, style.7c8e2d4.csslocation ~* \.[a-f0-9]{7,}\.(css|js)$ {expires 365d;add_header Cache-Control "public, max-age=31536000, immutable";}# 4. 不带hash的CSS/JS：7天缓存（保守策略）location ~* \.(css|js)$ {expires 7d;add_header Cache-Control "public, max-age=604800";}# 5. 视频/音频：30天location ~* \.(mp4|webm|ogg|mp3|wav)$ {expires 30d;add_header Cache-Control "public, max-age=2592000";}# 6. PDF/文档：30天location ~* \.(pdf|doc|docx|xls|xlsx|ppt|pptx)$ {expires 30d;add_header Cache-Control "public, max-age=2592000";}# 7. JSON/XML数据：禁用缓存location ~* \.(json|xml)$ {expires -1;add_header Cache-Control "no-store, no-cache, must-revalidate";}# 8. HTML页面：不缓存，但允许ETag条件验证# 这个规则优先级最高，因为HTML的location通常在前面的server块里已经定义# 如果server块有独立的 location / 规则，需在那里单独配置

然后在每个站点的server块里只需要一行：

server {listen 80;server_name site1.example.com;root /var/www/site1;# 这一行代替之前所有手写的expires和add_headerinclude /etc/nginx/conf.d/cache-policy.conf;# HTML页面单独配置——不缓存location / {try_files $uri $uri/ /index.php?$args;add_header Cache-Control "no-cache, must-revalidate";add_header Pragma "no-cache";}}

30个站的新增、修改只需要改cache-policy.conf一个文件，然后nginx -t && nginx -s reload，所有站点全部生效。从30个文件挨个改，变成改1个文件加1条命令。

四、版本号策略：CSS改了用户还看旧版，不是缓存的问题

"配了缓存之后CSS更新了，用户那边还是旧版样式"——这几乎是缓存配置中最常见的抱怨。但这个问题的根源不是缓存配置错了，而是文件名没变。

缓存策略的设计前提是：不可变资源的文件名必须是唯一的。一张logo.png你今天改了一版，如果文件名还叫logo.png，那浏览器就认为它还是之前那个文件，自然用本地缓存。解决办法就三个字——文件名加hash。

构建工具的配置也很简单。Webpack用[contenthash:8]，Vite默认就带hash，Gulp用gulp-rev。WordPress站群如果不用构建工具，可以用插件在引入资源时加版本参数，比如style.css?ver=20260801。

还有一个很多人忽略的细节：HTML文件里引用的资源路径也要同步更新。光把CSS文件名从style.css改成style.a3f2b.css没用，HTML里的link标签href也得跟着改。这一步如果不自动化，30个站手动改一遍HTML引用，工作量比配缓存本身还大。所以要么用构建工具自动处理，要么在WP里用函数统一输出版本号。

五、CDN缓存和浏览器缓存不是一回事，分开配才能不出问题

用了CDN（不管是CloudFlare、阿里云CDN还是腾讯云CDN）之后，缓存链路变成了：浏览器缓存 → CDN边缘节点缓存 → 源站。每一步都有独立的缓存策略，而且CDN的缓存规则优先级往往高于源站Nginx发出的Cache-Control头。

典型问题：你Nginx里配了HTML不缓存（no-cache），但CDN控制台里有一条规则"缓存所有.html文件30天"，结果用户看到的一直是CDN节点上的旧版HTML。排查半天才发现Nginx的配置在CDN层被覆盖了。

CDN缓存还有一个特有的"缓存Key"概念。CDN判断两个请求是否命中同一份缓存，靠的是缓存Key。默认的缓存Key通常包含"域名+URI"，但不包含Query参数。这导致一个问题：style.css?v=1.0和style.css?v=2.0在CDN看来是同一个文件，因为URI都是/style.css。

六、Gzip/Brotli压缩是缓存的好搭档，但别把两者搞混

经常有人把"缓存"和"压缩"当成一回事来讨论。它们解决的问题完全不同：缓存解决的是"能不能不请求服务器"，压缩解决的是"请求了能不能传得更快"。两者配合使用效果最好——压缩后的文件体积小，即使缓存没命中需要回源，传输时间也大幅缩短。

Nginx里Gzip的配置同样适合用include统一管理。在/etc/nginx/conf.d/gzip-policy.conf里写：

# ============================================# Gzip压缩统一模板 gzip-policy.conf# ============================================gzip on;gzip_vary on;                    # 告诉CDN按Accept-Encoding区分缓存gzip_min_length 1024;            # 小于1KB的文件不压缩gzip_comp_level 6;               # 压缩级别1-9，6是性价比最优gzip_proxied any;                # 对所有代理请求生效gzip_typestext/plaintext/csstext/javascripttext/xmlapplication/javascriptapplication/jsonapplication/xmlapplication/rss+xmlimage/svg+xmlfont/ttffont/woff2;                  # woff2已经是压缩格式，不重复压缩# 禁用IE6的gzip（如果你的用户还有IE6...）gzip_disable "msie6";

Brotli是比Gzip更新、压缩率更高的算法（同文件体积通常比Gzip小20%左右），但需要Nginx编译了brotli模块才能用。如果服务器支持，优先用Brotli，Gzip作为降级备选。配置方式类似，只是在gzip配置旁边再加一段brotli配置，同样用include统一引用。

七、配完不等于完事，三步验证少一步都可能白配

缓存配置最容易出问题的环节不是写配置，而是"以为配好了实际上没生效"。缓存不生效比没配缓存更麻烦——因为它会让你错误地以为"缓存没用"，其实只是没配对。

30个站逐个人工验证显然不现实。写一个简单的批量检测脚本：

#!/bin/bash# 批量检测所有站点的缓存头配置SITES=("https://site1.example.com/static/logo.png""https://site2.example.com/css/main.css"# ... 更多站点)for url in "${SITES[@]}"; doecho "=== $url ==="curl -sI "$url" | grep -E "(Cache-Control|Expires|ETag)"echo ""done

这个脚本跑一遍，30个站有没有缺缓存头、哪些站Cache-Control值不对，一目了然。比打开30个浏览器窗口挨个看DevTools快得多。

八、四个配置翻车现场，每个都有人踩过

九、从手配到系统化：站群缓存的终极形态

前面讲的是"配置层面"的批量管理——用include统一模板、按文件类型分时长、版本号策略、CDN协同。但如果你管的不只是30个站，而是100个、200个，甚至站点还在持续新增，那光靠include还不够。

更深一层的问题是：新站点创建时，缓存配置是自动就位的还是需要手动去加一行include？站点模板更新（比如新增了一种文件类型的缓存规则），是手动改cache-policy.conf还是系统自动同步？站点下线后，CDN上对应域名的缓存规则要不要清理？

对于30个站以内，include统一模板已经足够。对于100+站并且分布在多台服务器上的场景，就需要建站模板内置缓存配置+Ansible批量推送的组合了。

缓存这件事，单个站配置对了能省30%-50%的服务器带宽和加载时间。但真正的收益在规模化以后才显现——30个站、100个站，每个站省50%带宽，加起来省下的服务器成本够多养两台机器。更重要的是页面速度提升带来的排名红利：Google把Core Web Vitals纳入排名信号之后，LCP从3秒优化到1.5秒，不是"用户感觉快了一点"的问题，是实实在在影响自然流量的因素。

最后说一句，缓存配置不是"配一次就永远不用管"的事情。站点改版、新增CDN、换服务器、升级HTTPS——每次基础设施变动之后，都值得用curl -I把关键资源的响应头再过一遍。很多"网站突然变慢了"的问题，排查到最后就是某次改配置把缓存头改丢了。