Linux下Nginx配置FastCGI缓存教程

Linux下Nginx的FastCGI缓存看似简单，实则极其敏感——哪怕只漏掉`fastcgi_ignore_headers`、路径权限配置错误或`fastcgi_cache_valid`未置于location块中，缓存就会彻底静默失效；本文直击WordPress等动态站点缓存失效的四大核心陷阱：缓存目录权限与结构规范、`fastcgi_cache_key`中`$args`的精准控制与干扰参数过滤、强制忽略后端`Cache-Control`/`Set-Cookie`等破坏性响应头，以及`fastcgi_cache_valid`在具体location中的强制落地，并提供可验证的调试方法（如检查`X-FastCGI-Cache`响应头和缓存文件生成），助你真正让PHP-FPM压力下降50%以上。

FastCGI缓存能显著降低 PHP-FPM 压力，但配置错一步就完全不生效——关键不在 fastcgi_cache 开关，而在 fastcgi_cache_key 和响应头过滤的组合逻辑。

fastcgi_cache_path 必须提前创建目录且权限正确

路径不存在或 Nginx 用户无写权限会导致缓存静默失效，nginx -t 不报错，error.log 里也只有一行模糊的 open() "/tmp/wpcache/..." failed (13: Permission denied)。

• 先手动创建并授权：sudo mkdir -p /tmp/wpcache/{temp,levels}（注意：levels=1:2 要求子目录结构存在）
• 确保 Nginx worker 进程用户（通常是 www-data 或 nginx）有读写权限：sudo chown -R www-data:www-data /tmp/wpcache
• max_size 建议设为磁盘可用空间的 10%～20%，避免填满根分区；inactive=1d 表示 1 天内未被访问的缓存条目自动清理

fastcgi_cache_key 决定缓存是否命中，别漏掉关键变量

默认的 $scheme$request_method$host$request_uri 看似完整，但实际中常因 Cookie、Query 参数或协议升级导致重复缓存或击穿。

• WordPress 类站点建议加 $args：fastcgi_cache_key "$scheme$request_method$host$request_uri$args"，否则 ?s=xxx 搜索页全被当成同一缓存
• 若需忽略某些参数（如跟踪用的 utm_*），得靠 map 预处理 $args，不能只靠 fastcgi_ignore_headers
• 绝对不要包含 $cookie_* 或 $http_user_agent——除非你真要按设备/登录态做差异化缓存，否则直接废掉共享性

fastcgi_ignore_headers 是缓存生效的“开关级”配置

PHP 脚本或框架（如 Laravel、WordPress 插件）常输出 Cache-Control: no-cache 或 Set-Cookie，Nginx 默认会尊重这些头并跳过缓存——哪怕你写了 fastcgi_cache_valid 也没用。

• 必须显式禁用：fastcgi_ignore_headers Cache-Control Expires Set-Cookie
• 如果后端返回了 X-Accel-Expires，它会覆盖 fastcgi_cache_valid，此时要加 fastcgi_hide_header X-Accel-Expires 才可控
• fastcgi_cache_use_stale 可以兜底：比如加 error timeout http_500，让出错时仍返回旧缓存，避免雪崩

location 块里漏掉 fastcgi_cache_valid 就等于没配

fastcgi_cache 指令只是启用缓存区域，真正控制“哪些状态码缓多久”的是 fastcgi_cache_valid，它必须出现在 location 块里，且优先级高于 http/server 层的同名指令。

• 最简可用组合：fastcgi_cache WORDPRESS; fastcgi_cache_valid 200 302 10m; fastcgi_cache_valid any 1m;
• 不要写 fastcgi_cache_valid 200 1h 却漏掉 302——重定向响应（如登录跳转）也会进缓存，不加会导致无限重定向
• WordPress 后台（/wp-admin/）这类路径必须用 fastcgi_cache_bypass $arg_nocache; 或匹配 URI 排除，否则管理员看到的是别人缓存的页面

缓存是否真在工作，别只看配置文件——用 curl -I http://yoursite.com 检查响应头有没有 X-FastCGI-Cache: HIT 或 MISS；再查 /tmp/wpcache/ 下是否有生成的哈希目录和文件。最常被忽略的是：缓存路径权限、fastcgi_ignore_headers 缺失、以及 fastcgi_cache_valid 没写在具体 location 里。

今天关于《Linux下Nginx配置FastCGI缓存教程》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于Linux的内容请关注golang学习网公众号！