这样部署 WordPress，让网站获得秒开级性能

想让 WordPress 接近秒开，缓存不能只靠一个插件，得在服务器上把缓存一层层配好。这篇指南以一台 Linux VPS 为例，从 PHP 的 OPcache、Redis 对象缓存，到 Nginx FastCGI Cache 页面缓存，再到 Cloudflare CDN，完整部署一套经得起速度测试的架构，所有配置都可以直接照抄。

文中的示例环境是宝塔面板下的一台 Linux VPS：Nginx、PHP 8.3-FPM、MariaDB、WordPress，示例域名 example.com，网站目录 /www/wwwroot/example.com。换成 CloudPanel、Docker 或手动编译的环境时，配置文件路径和服务名会有差异，但配置思路不变。域名、目录、参数都是示例，动手前替换成你自己的实际环境。

为什么 WordPress 网站会越用越慢

一个 WordPress 站点刚上线时通常很快，随着插件越装越多、内容越堆越厚，页面打开时间会从 1 秒慢慢涨到 3 秒、5 秒。问题不在 WordPress 本身，而在它的默认请求流程：每一次访问，整条链路都要从头跑一遍。

每来一个访客，WordPress 都要重新加载主题和插件、把 PHP 代码重新编译、向 MySQL 发起查询，再拼出一份 HTML。访客一多，或者服务器配置不高，慢就慢在每一步都在实时计算，谁也没法偷懒。要提速，就得给这条链路加上缓存，让重复的工作只做一次。

高性能 WordPress 需要从四个层面一起优化：

这篇指南把前三层完整部署到服务器上，网络层给出开启建议。四个层面都做对了，网站才谈得上真正接近秒开。

先看清推荐架构再动手

优化的思路很直接：让尽量多的请求在离用户近、开销小的环节结束。静态文件交给 Cloudflare CDN 就近返回，整个页面的 HTML 由 Nginx FastCGI Cache 缓存，只有缓存没命中的请求才会真正跑到 PHP 和 MySQL 那里，而 PHP 的编译结果和数据库查询结果，又分别被 OPcache 和 Redis 接住。

后面的正文按六步走：装好环境、开启 OPcache、装 Redis、接入缓存插件、配置 FastCGI Cache、验证结果。

装好基础环境

这套方案的前提，是一台能装 Nginx 和 PHP-FPM 的 Linux 服务器。手上还没有的话，可以按网站访客的位置来选：访客主要在海外，买 Hostinger 这类海外服务商的 VPS，起步 2 核 2GB 就够跑完整套架构；访客主要在国内，腾讯云轻量应用服务器 的节点离用户更近，同样规格的 Linux 套餐也够用。系统装 Ubuntu 或 Debian 都行，教程按 Debian 系命令写。

• 系统：Ubuntu 或 Debian
• Web 服务器：Nginx
• PHP：8.3-FPM
• 数据库：MariaDB

用宝塔面板的话，在软件商店里依次安装 Nginx、MariaDB、PHP 8.3，然后在网站菜单添加站点、上传 WordPress 即可。后面的配置都在两个地方改：站点配置文件和 PHP 设置。用 CloudPanel、Docker 或手动编译的读者，文件路径和服务名不同，配置内容可以直接沿用。

开启 PHP OPcache

WordPress 是 PHP 写的，而 PHP 每执行一次请求，都要把用到的代码重新编译成字节码，插件越多编译量越大。OPcache 是 PHP 自带的字节码缓存，把编译结果放进内存，第二次执行直接复用，省掉重复编译的时间。

宝塔里安装：进入 PHP 8.3 的设置页，在安装扩展里找到 opcache 并安装，面板会提示重启 PHP。然后在 PHP 配置文件的末尾追加下面这些行：

opcache.enable=1
opcache.memory_consumption=128
opcache.interned_strings_buffer=32
opcache.max_accelerated_files=30000
opcache.revalidate_freq=60
opcache.validate_timestamps=1
opcache.fast_shutdown=1
opcache.enable_cli=1
opcache.jit=0

保存后重启 PHP 服务生效。memory_consumption 和 max_accelerated_files 是给中小站点准备的，主题插件特别多的站可以再调大一些。

安装 Redis，服务端和扩展缺一不可

Redis 在整套架构里当对象缓存后端，存放 WordPress 的对象和数据库查询结果，减少对 MySQL 的重复访问。它需要两部分配合：先装好 Redis Server，再给 PHP 装上 redis 扩展，两个缺一不可，只装一个都不会生效。

• Redis Server：在宝塔软件商店搜索 Redis 并安装。装完后在终端执行 redis-cli ping，返回 PONG 说明服务正常。
• PHP Redis 扩展：进入 PHP 8.3 设置页，在安装扩展里找到 redis 并安装，装完同样要重启 PHP。

redis-cli ping

正常返回：

PONG

让 WordPress 用上 Redis Object Cache

服务端就绪后，回到 WordPress 后台装插件：

1. 进入插件菜单，搜索 Redis Object Cache，安装并启用。
2. 进入设置菜单下的 Redis 页面，点击 Enable Object Cache 按钮。
3. 页面显示 Status: Connected，说明对象缓存已经连上。

插件默认连接本机的 6379 端口，不需要填任何配置。只有把 Redis 装在别的机器上时，才需要改 Host 和 Port 两项。

配置 Nginx FastCGI Cache，把页面缓存下沉到服务器

注意，FastCGI Cache 不是 WordPress 插件，而是 Nginx 服务器自带的功能。它把整个页面的 HTML 缓存成文件，命中时 Nginx 直接把文件返回，PHP、WordPress、MySQL 全都不参与。相比插件类页面缓存，它不占 PHP 进程，是整套方案里提速最明显的一步，配置也分三步。

第一步：在 Nginx 主配置里声明缓存区域

编辑 Nginx 主配置文件（示例路径 /www/server/nginx/conf/nginx.conf，这是宝塔的默认路径，按实际环境调整），在 http 大括号内加入：

fastcgi_cache_path /www/server/nginx/fastcgi_cache levels=1:2 keys_zone=WORDPRESS:100m inactive=60m max_size=1g;

这一行声明了缓存文件存放目录，以及缓存区域的名字和容量：keys_zone=WORDPRESS:100m 给缓存区域命名并分配 100MB 内存索引，inactive=60m 表示 60 分钟内没被访问的缓存会被清理，max_size=1g 限制磁盘占用上限为 1GB。后面站点配置里引用的 WORDPRESS 就是这里定义的名字。

第二步：在站点配置里启用缓存

打开宝塔网站菜单里对应站点的配置文件，找到 location ~ \.php$ 这一段，在大括号内加入：

fastcgi_cache WORDPRESS;
fastcgi_cache_valid 200 1d;
fastcgi_cache_valid 301 302 10m;
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;
add_header X-FastCGI-Cache $upstream_cache_status;

fastcgi_cache WORDPRESS 引用主配置里声明的缓存区域；fastcgi_cache_valid 200 1d 表示正常页面缓存 1 天，301、302 跳转缓存 10 分钟；最后一行把缓存命中状态写进响应头，用来验证是否生效。这里用到的 $skip_cache 变量还没有定义，下一步补上。

第三步：排除不该缓存的请求

在同一个 location 里，先定义变量再追加三条判断：

set $skip_cache 0;
if ($request_method = POST) {
    set $skip_cache 1;
}
if ($http_cookie ~* "wordpress_logged_in") {
    set $skip_cache 1;
}
if ($request_uri ~* "/wp-admin/") {
    set $skip_cache 1;
}

POST 请求（评论提交、表单操作）、带登录 Cookie 的请求、wp-admin 后台的请求都必须绕过缓存，否则会出现评论发完不显示、登录状态串号这类怪问题。set $skip_cache 0; 要先于 if 判断执行，位置别放错。

保存后先测试配置，再重载 Nginx：

nginx -t
systemctl reload nginx

nginx -t 输出 syntax is ok 才说明配置没有语法错误，有问题它会指出具体的行号。面板环境也可以直接点重载按钮，命令名随系统和面板略有不同。

WP Super Cache 这类页面缓存插件就别开了

FastCGI Cache 和 WP Super Cache 干的是同一件事：缓存整页 HTML。同时开等于服务器上存在两套页面缓存，改完文章一套更新了，另一套还在吐旧页面，问题出在哪里很难查。

再叠加 Cloudflare CDN 和图片优化

前三层缓存解决的是服务器内部的开销。访客离服务器远、图片体积大，这部分要靠网络层补上。

接入 Cloudflare CDN

免费套餐就包含 CDN 缓存、Brotli 压缩和 HTTP/3。域名接入 Cloudflare 后，静态请求由边缘节点就近返回，动态请求回源到 Nginx，和前面的 FastCGI Cache 各管一段。接入后建议把安全响应头也一起配了，步骤可以看这篇Cloudflare 安全响应头配置。

静态资源缓存设长

CSS、JS、图片这类文件路径稳定，浏览器缓存时间可以放心设长。文件名带版本号的资源（CSS 和 JS 打包后常见）缓存一年都没问题，更新时文件名变了，浏览器自然会去拉新文件。

图片转 WebP 或 AVIF

图片通常是 WordPress 最大的体积来源。上线前把图片转成 WebP 或 AVIF 格式再压缩一遍，配合 CDN 分发，首屏体积能降下一大半。主题不支持自动转换的话，用图片插件批量处理一次即可。

验证缓存是否真的生效

配置都做完后，先别急着宣布完工，FastCGI Cache 和 Redis 各有各的验证方法，按下面两步确认。

先验证 FastCGI Cache。在服务器上执行下面的命令，把域名换成你自己的：

curl -I https://example.com

第一次执行，返回头里是 X-FastCGI-Cache: MISS，第二次执行同样的命令，应该变成 X-FastCGI-Cache: HIT。看到 HIT 就说明页面已经由 Nginx 直接从缓存返回，之后的请求不再惊动 PHP 和数据库。

再看 Redis。登录 WordPress 后台，进入工具 → 网站健康 → 信息，在列表里找到 Redis，显示 Connected 说明对象缓存已经生效。如果显示无法连接，回头检查 Redis Server 是否在运行、PHP 的 redis 扩展是否装好。

最终配置和适合的场景

全部做完后，一个站点从外到内是这样的结构：

• 网络层：Cloudflare CDN，静态资源就近返回
• Web 服务器：Nginx，页面 HTML 命中 FastCGI Cache
• PHP 运行层：PHP 8.3-FPM 加 OPcache，字节码免重复编译
• 数据层：MariaDB 加 Redis Object Cache，查询结果进 Redis
• 应用层：WordPress 本身

这套架构适合企业官网、SEO 博客、内容营销网站、技术博客这类以读为主的站点，中小型 WordPress 站都在范围内。服务器层、PHP 层、缓存层、网络层一起优化之后，即使是 2 核 2GB 的小 VPS，静态资源走 CDN、页面命中 FastCGI Cache，绝大多数请求都不会真正压到 PHP 和 MySQL，打开速度自然接近秒开。

性能之外，上线前别忘了安全：登录保护、后台访问限制和 Cloudflare Security Rules 这些，可以对照WordPress 安全加固指南逐项检查。还想再从内容和插件层面压一压，之前写过一篇提升 WordPress 网站速度的 15 个技巧，偏轻量优化，两篇一起看基本就覆盖全了。