彻底解决WordPress站点健康问题

再次建站的时候,虽然没有重装系统,但是却把系统的php版本升级到了8.4。也放弃了之前编译的php7.4版本的结巴分词,而是直接启了个python的服务

不过,有的东西确一直没解决,那就是从之前的7.4,到现在的8.4版本,站点健康在响应速度慢的时候就会显示:

页面缓存通过保存和提供静态页面使得用户访问时不需要每次都调用页面,进而改善了您站点的速度和性能。

页面缓存会通过查找已启用的页面缓存插件的同时向主页发起三次请求并查找一个或多个下列的 HTTP 客户端响应标头,来确定页面缓存的存在。

cache-control, expires, age, last-modified, etag, x-cache-enabled, x-cache-disabled, x-srcache-store-status, x-srcache-fetch-status.
 服务器响应时间的中位数是 718 毫秒,其应当小于推荐的 600 毫秒临界值。
 未检测到客户端缓存响应标头。
 未检测到页面缓存插件。

虽然,已经开启了redis object cache,但是这个东西时常出现,看着总是不爽。于是下定决心要解决这个问题,其实主要就是nginx的配置问题。通过下面的方法配置就ok了。

1.在 nginx.conf 的 http {} 块中添加(仅需一次)

fastcgi_cache_path /var/cache/nginx/wordpress
    levels=1:2
    keys_zone=WORDPRESS:64m
    max_size=256m
    inactive=60m
    use_temp_path=off;

如果目录不存在,先创建:/var/cache/nginx/wordpress

2.创建wordpress-php-with-cache.conf

# 1. 复制本文件为 wordpress-php-with-cache.conf(去掉 .example),并放到与 zhongxiaojie.conf 同一目录(如 vhost/)
# 2. 若 PHP 版本或路径不同,请修改 fastcgi_pass(见下方说明)
# 3. 在 zhongxiaojie.conf 的 443 server 块中,用 include wordpress-php-with-cache.conf 替换 include enable-php-pathinfo.conf 或 include enable-php.conf
# 4. 若 fastcgi.conf 找不到,请将 include 改为 Nginx 配置目录下的绝对路径,如 /etc/nginx/fastcgi.conf
# 5. 执行:mkdir -p /var/cache/nginx/wordpress && chown -R www:www /var/cache/nginx/wordpress
# 6. nginx -t && nginx -s reload

# fastcgi_pass 常见取值(按实际修改):
#   PHP 8.4 FPM(常见):unix:/run/php/php8.4-fpm.sock
#   PHP 8.2 FPM:        unix:/run/php/php8.2-fpm.sock
#   宝塔:               unix:/tmp/php-cgi-74.sock 等

location ~ [^/]\.php(/|$)
{
    try_files $uri =404;

    fastcgi_pass unix:/run/php/php8.4-fpm.sock;

    # ------ 页面缓存:跳过后台、登录、订阅等 ------
    set $skip_cache 0;
    if ($request_uri ~* "/wp-admin/|/wp-login\.php|/xmlrpc\.php|wp-.*\.php|/feed/|sitemap(_index)?.xml|/cart/|/checkout/|/my-account/") {
        set $skip_cache 1;
    }
    if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_logged_in|woocommerce_") {
        set $skip_cache 1;
    }
    fastcgi_cache_bypass $skip_cache;
    fastcgi_no_cache $skip_cache;

    # ------ FastCGI 缓存(依赖 nginx.conf 中 fastcgi_cache_path WORDPRESS)------
    fastcgi_cache WORDPRESS;
    fastcgi_cache_key $scheme$request_method$host$request_uri;
    fastcgi_cache_valid 200 301 302 60m;
    fastcgi_cache_use_stale error timeout updating http_500 http_503;
    fastcgi_cache_lock on;
    fastcgi_cache_lock_timeout 5s;

    fastcgi_index index.php;
    include fastcgi.conf;

    # ------ 检测工具要求的客户端缓存响应头 ------
    add_header X-Cache-Status $upstream_cache_status;
    add_header X-Cache-Enabled "1";
    add_header Cache-Control "public, max-age=3600";
}

3.在网站的配置文件中引入上面的配置信息vim /usr/local/nginx/conf/vhost/zhongxiaojie.com.conf

include wordpress-php-with-cache.conf;

重启nginx 就ok啦

 


You may also like

31 comments

  1. Level 3
    Google Chrome 109.0.0.0 Google Chrome 109.0.0.0 Windows 10 x64 Edition Windows 10 x64 Edition cn中国–北京–北京

    还以为灵妹妹彻底重构python版了。

      1. Level 2
        Google Chrome 144.0.0.0 Google Chrome 144.0.0.0 Windows 11 x64 Edition Windows 11 x64 Edition jp日本–Tokyo–Tokyo

        我用的FreshRSS来订阅,之前那个正常,现在这个新的添加不了;有空再折腾个RSS工具用来备用

  2. Level 1
    Firefox 147.0 Firefox 147.0 Windows 10 x64 Edition Windows 10 x64 Edition sgSingapore–Singapore–Singapore

    我用的ESA,直接在ESA的规则-在HTTP响应中添加标头 添加 x-cache-enabled: ESA
    这样就骗过检测,不报这个问题了。

  3. Level 1
    Google Chrome 144.0.0.0 Google Chrome 144.0.0.0 Mac OS X  10.15.7 Mac OS X 10.15.7 cn中国–湖北–武汉

    我的博客受 CloudCone 事件的影响,也被删库了。不对,准确点说,是整个服务器的数据全丢了。

      1. Level 1
        Google Chrome 144.0.0.0 Google Chrome 144.0.0.0 Mac OS X  10.15.7 Mac OS X 10.15.7 unknownHong Kong–Hong Kong–Hong Kong

        是的,因为我平时习惯用 VSCode 写文章,所以本地都有原始 Markdown 文件的归档。于是我就强行手动把内容给恢复了,但可惜的是,评论、分类和标签之类的相关数据就全都没了。

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注