Nginx边缘缓存CMS页面的关键是“缓什么、怎么缓、怎么不缓错”:只缓匿名页、哈希静态资源和公开API,用map跳过敏感路径,proxy_cache_key剥离干扰参数,按页面类型分级设置有效期,并借助ngx_cache_purge主动清理。
直接用 Nginx 做边缘缓存,能让 CMS 页面从几百毫秒降到几十毫秒,关键不在“加缓存”,而在“缓什么、怎么缓、怎么不缓错”。CMS 动态内容多,但大量页面实际是静态或半静态的——首页、栏目页、文章详情页(无登录态/未评论)完全可缓存。真正卡顿的不是 PHP,而是反复查数据库、渲染模板、拼接 HTML 的过程。边缘缓存把这些结果提前存好,用户请求时跳过后端,直取缓存。
CMS 不是所有页面都能缓,缓错了会暴露用户信息或显示过期内容。重点缓存三类:
main.a1b2c3.js),这类资源可长期缓存Cache-Control: public, max-age=3600
要避开:登录态页面、购物车、评论提交页、后台接口。Nginx 可通过 map 指令识别并跳过缓存:
map $request_uri $skip_cache { ~*/wp-admin/ 1; ~*/wp-login.php 1; ~*?s= 1; default 0;}
CMS 经常带跟踪参数(?utm_source=xxx、?ref=abc),若直接用 $request_uri 当缓存键,会导致同一页面被存成几十个副本。正确做法是剥离无关参数:
$scheme$host$uri 作为主键,忽略所有查询参数$http_user_agent 的简化标识(如是否含 Mobile)?lang=zh 切换,把 $arg_lang 显式纳入缓存键示例配置:
proxy_cache_key "$scheme$host$uri$is_args$arg_lang";
CMS 内容更新频率差异大,不能一刀切设 1 小时或 1 天。推荐按内容类型分级:
proxy_cache_valid 200 15m),平衡更新及时性与并发压力proxy_cache_valid 200 24h),除非 CMS 有手动清缓存机制proxy_cache_valid 404 1m),防止爬虫反复扫死链接拖垮后端同时启用 proxy_cache_use_stale,当源站 PHP 偶尔超时或返回 502 时,仍可返回旧缓存,保障可用性。
等缓存自然失效太被动。CMS 发布新文章、修改栏目后,应立刻让对应 URL 缓存失效。Nginx 自身不支持按 URL 清除,需借助 ngx_cache_purge 模块:
--add-module=/path/to/ngx_cache_purge
location ~ /purge(/.*) { allow 127.0.0.1; allow 192.168.1.0/24; deny all; proxy_cache_purge my_cache "$scheme$host$1";}
CMS 后台发布成功后,调用 curl -X PURGE http://your-cms.com/purge/article/123 即可精准清除。