根本原因是缓存未真正生效：fastcgi_cache_bypass或fastcgi_no_cache绕过所有请求，或fastcgi_cache_key包含动态参数导致命中率趋近于0。
为什么加了 FastCGI 缓存网站还是不快
根本原因往往是缓存没真正生效——fastcgi_cache 配置写了，但 fastcgi_cache_bypass 或 fastcgi_no_cache 把所有请求都绕过去了，或者缓存键（fastcgi_cache_key）把用户身份、Cookie、参数全塞进去，导致命中率接近 0。
常见错误现象：curl -I 查看响应头没有 X-FastCGI-Cache: HIT；后台日志里大量 MISS 或 BYPASS；页面刷新后服务器 CPU 照样飙升。
- 检查是否在
location ~ \.php$块里漏掉了fastcgi_cache_use_stale或fastcgi_cache_valid，缺任意一个都会让缓存策略失效 - 宝塔默认的 PHP 项目常带
Set-Cookie（比如 WordPress 登录态、WooCommerce 购物车），只要响应头含Set-Cookie，Nginx 默认就不缓存——必须显式用fastcgi_ignore_headers Cache-Control Expires Set-Cookie才能压住 -
fastcgi_cache_key别直接抄网上的通用模板，例如$scheme$request_method$host$request_uri看似稳妥，但一旦 URL 带 UTM 参数或随机时间戳，缓存就完全失效
宝塔面板里怎么配才不踩坑
宝塔的「网站」→「设置」→「配置文件」编辑入口，改的是站点级 Nginx 配置，但 FastCGI 缓存必须在 http 块全局定义，否则会报 unknown directive "fastcgi_cache"。很多人卡在这一步，反复保存配置却没效果。
实操建议：
- 进宝塔「软件商店」→「Nginx」→「设置」→「配置修改」，在
http块开头加缓存区定义：fastcgi_cache_path /www/server/nginx/cache/fastcgi levels=1:2 keys_zone=WORDPRESS:256m inactive=1d max_size=1g;
- 确保站点配置中
location ~ \.php$块内包含完整缓存指令，尤其不能漏掉fastcgi_cache WORDPRESS和fastcgi_cache_valid 200 301 302 1h; - 宝塔自带的防 CC 规则有时会插入
if ($cookie_PHPSESSID) { ... }这类逻辑，它会触发 Nginx 的“if is evil”问题，导致缓存被跳过——删掉或改用map方式判断更安全
WordPress 场景下缓存策略怎么调
WordPress 不是静态站，登录用户、评论区、购物车都得动态处理，硬全量缓存会出内容错乱。关键不是“开不开”，而是“哪些路径放行、哪些强制不缓存”。
典型做法：
- 用
fastcgi_cache_bypass排除动态行为：fastcgi_cache_bypass $cookie_wp_logged_in_$cookie_user; fastcgi_no_cache $cookie_wp_logged_in_$cookie_user;
（注意变量名要和实际 Cookie 名一致，WordPress 默认是wordpress_logged_in_*） - 对 wp-admin、wp-login.php、wp-comments-post.php 这些路径，直接
location ~ /(wp-admin|wp-login\.php|wp-comments-post\.php) { fastcgi_cache off; } - 首页和文章页可缓存，但需过滤 UTM、fbclid 等追踪参数：在
fastcgi_cache_key中用$request_uri而非$args，避免参数污染缓存键
缓存清理和调试怎么看效果
缓存配完不等于跑通，必须验证是否真在用、清得掉、不出错。宝塔没提供 FastCGI 缓存状态页，得靠命令和日志交叉确认。
快速验证方式：
- 查缓存目录大小：
du -sh /www/server/nginx/cache/fastcgi/，从 0 变成几百 MB 才算开始落盘 - 加响应头方便观察：
add_header X-FastCGI-Cache $upstream_cache_status;
，然后curl -I https://yoursite.com看返回头是不是HIT/MISS/BYPASS - 手动删缓存用
rm -rf /www/server/nginx/cache/fastcgi/*，别信宝塔「清除缓存」按钮——它只清浏览器和代理层，不碰 FastCGI - 如果出现
502 Bad Gateway且 error.log 提示upstream sent too big header，大概率是 FastCGI 缓存头过大，加一句fastcgi_buffer_size 128k;就能解决
最麻烦的其实是缓存键设计和动态逻辑排除，这两块没调准，其他都白搭。尤其是多语言插件、会员系统这类扩展，它们加的 Cookie 或 header 往往藏得深，得抓包比对真实请求头才能定位。
