FastCGI缓存不生效的关键原因在于缓存路径权限错误、fastcgi_cache_key设计不当、fastcgi_ignore_headers缺失及fastcgi_cache_valid未在location块中配置；需确保目录可写、键值稳定、忽略后端干扰头，并正确定义缓存有效期。
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 里。
