WordPress 网站慢，很多人第一反应是：VPS 配置不够，要不要从 1C1G 升到 2C4G？
有时候确实要升级，但更多时候不是 CPU 太差，而是 PHP-FPM、OPcache、Redis、Nginx 缓存、MySQL、插件和图片 没配好。一台 2C2G VPS，如果 WordPress 配置合理，跑个人博客、小型企业站、低流量 WooCommerce 都不应该“点一下后台等十秒”。
这篇不讲怎么安装 WordPress。安装可以看这篇：
本文只解决一个问题：WordPress 已经跑起来了，但在 VPS 上很慢，应该按什么顺序排查和优化。
不要一上来就装缓存插件。先分清是哪个环节慢。
常见慢法有四种：
- 首字节慢（TTFB 高）：页面开始响应就慢，多半是 PHP、数据库、缓存问题；
- 后台慢：wp-admin 打开慢，多半是插件、数据库、外部请求或 PHP 进程不足；
- 前端资源慢：HTML 很快，但图片、CSS、JS 拖后腿；
- 高峰期突然慢：平时正常，一有访问就 CPU、内存、MySQL 飙高。
先在本机测一下首字节：
curl -o /dev/null -s -w 'time_namelookup: %{time_namelookup}\ntime_connect: %{time_connect}\ntime_starttransfer: %{time_starttransfer}\ntime_total: %{time_total}\n' https://example.com/
如果 time_starttransfer 很高，比如 1 秒、2 秒以上，重点看 PHP、数据库和缓存。
再看服务器资源：
top
free -h
df -h
iostat -xz 1
如果 CPU 长期 100%，可以参考：
如果内存经常被打爆，可以参考：
先定位，再优化。否则很容易变成“装了五个缓存插件，网站更慢”。
WordPress 本质上大量请求要跑 PHP。Nginx 很快，但 PHP-FPM 进程池不够，网站一样慢。
先看 PHP-FPM 配置文件位置。不同系统可能是：
/etc/php/8.2/fpm/pool.d/www.conf
/etc/php/8.3/fpm/pool.d/www.conf
/etc/php/8.4/fpm/pool.d/www.conf
关键参数是：
pm = dynamic
pm.max_children = 8
pm.start_servers = 2
pm.min_spare_servers = 2
pm.max_spare_servers = 4
pm.max_requests = 500
pm.max_children 不是越大越好。每个 PHP-FPM 子进程都会吃内存。先看单个进程大概占多少：
ps -ylC php-fpm8.2 --sort:rss
或者：
ps aux | grep 'php-fpm' | grep -v grep
粗略估算：
可给 PHP 的内存 / 单个 PHP-FPM 进程平均内存 = max_children
比如 2GB VPS，系统、Nginx、MySQL、Redis 留掉一部分，给 PHP 可能只有 700MB。如果一个 PHP 进程平均 80MB，pm.max_children 配到 8-10 就差不多。你硬配 50，只会把机器打到 swap。
改完后检查并重载：
php-fpm8.2 -t
sudo systemctl reload php8.2-fpm
如果你之前遇到 502/504，也可以看这篇：
OPcache 是 WordPress 性能优化里最容易被低估的一项。它会缓存 PHP 编译后的字节码，避免每次请求都重新解析 PHP 文件。
检查是否启用：
php -i | grep -i opcache.enable
也可以创建一个临时 PHP 文件看 phpinfo()，但看完马上删掉，不要长期暴露。
常见配置文件：
/etc/php/8.2/fpm/conf.d/10-opcache.ini
一个小型 WordPress 站点可以这样起步：
opcache.enable=1
opcache.enable_cli=0
opcache.memory_consumption=128
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.validate_timestamps=1
opcache.revalidate_freq=60
opcache.save_comments=1
说明一下：
memory_consumption=128对多数中小站够用；- 插件很多、主题很重时可以提高到 192 或 256；
max_accelerated_files不要太小，WordPress 插件文件很多；validate_timestamps=1对普通站点更安全，更新插件后不容易缓存旧代码。
改完重启 PHP-FPM：
sudo systemctl restart php8.2-fpm
如果没有 OPcache，很多缓存插件也救不了后台慢。
WordPress 页面缓存能让前台很快，但后台、登录用户、购物车、动态页面仍然会频繁查数据库。Redis Object Cache 的价值就在这里。
适合上 Redis 的场景：
- 后台很慢；
- 插件多；
- WooCommerce；
- 文章多、分类多；
- 查询数据库次数很多；
- MySQL CPU 或 I/O 经常高。
安装 Redis：
sudo apt update
sudo apt install redis-server
sudo systemctl enable --now redis-server
检查：
redis-cli ping
返回：
PONG
WordPress 侧可以安装 Redis Object Cache 插件，然后在 wp-config.php 里加：
define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_CACHE_KEY_SALT', 'example.com:');
如果你有多个 WordPress 站点共用一个 Redis，WP_CACHE_KEY_SALT 必须不同，否则缓存 key 可能互相污染。
Redis 不要直接暴露公网。之前这篇讲过数据库类服务为什么不要开公网：
检查 Redis 监听：
ss -lntp | grep 6379
应该只监听 127.0.0.1:6379 或内网地址，不要裸奔到公网。
如果你的网站主要是博客、企业站、文档站，页面内容对未登录用户基本一样，那么 Nginx FastCGI Cache 非常有效。
它的作用是：把 PHP 生成好的 HTML 缓存在 Nginx 层。下一次匿名用户访问同一个页面时，直接由 Nginx 返回，不再进 PHP 和 MySQL。
基础思路：
fastcgi_cache_path /var/cache/nginx/wordpress levels=1:2 keys_zone=WORDPRESS:100m inactive=60m max_size=1g;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
在 PHP location 里：
fastcgi_cache WORDPRESS;
fastcgi_cache_valid 200 301 302 10m;
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;
add_header X-FastCGI-Cache $upstream_cache_status always;
再设置哪些请求不要缓存：
set $skip_cache 0;
if ($request_method = POST) {
set $skip_cache 1;
}
if ($query_string != "") {
set $skip_cache 1;
}
if ($request_uri ~* "/wp-admin/|/wp-login.php|/cart|/checkout|/my-account") {
set $skip_cache 1;
}
if ($http_cookie ~* "wordpress_logged_in_|comment_author|woocommerce_items_in_cart|wp_woocommerce_session") {
set $skip_cache 1;
}
注意：WooCommerce、会员站、论坛、学习系统不能无脑全站缓存。购物车、结账、个人中心必须跳过缓存。
测试缓存是否命中：
curl -I https://example.com/
看响应头：
X-FastCGI-Cache: HIT
如果一直是 MISS 或 BYPASS，说明跳过规则、cookie 或缓存路径有问题。
WordPress 插件生态强，但也容易把性能搞乱。
常见错误：
- 同时装多个页面缓存插件；
- 插件缓存和 Nginx FastCGI Cache 同时缓存同一层；
- 开了 Redis Object Cache，又装了另一个对象缓存插件；
- 缓存插件自动生成复杂
.htaccess，但你用的是 Nginx； - 页面优化插件把 CSS/JS 合并到出错。
建议原则：
- 页面缓存：Nginx FastCGI Cache 或一个成熟缓存插件，二选一；
- 对象缓存：Redis Object Cache 一个就够；
- 静态资源优化：图片压缩、延迟加载、关键 CSS，不要过度合并；
- CDN：Cloudflare 负责静态资源和边缘缓存，不要和源站规则打架。
如果你已经接了 Cloudflare，可以顺手看：
WordPress 慢，很多时候不是 PHP 慢，而是数据库被插件拖慢。
打开 MySQL 慢查询日志：
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;
SET GLOBAL log_queries_not_using_indexes = 'ON';
查看慢查询日志位置：
SHOW VARIABLES LIKE 'slow_query_log_file';
也可以在配置文件里持久化：
[mysqld]
slow_query_log=1
long_query_time=1
log_queries_not_using_indexes=0
不要长期打开 log_queries_not_using_indexes=1，它可能让日志暴涨。排查阶段打开，定位后关掉。
常见 WordPress 慢查询来源：
- 插件在
wp_options里塞大量 autoload 数据； - 页面构建器生成过多 meta 查询；
- WooCommerce 订单表历史数据太多；
- 搜索插件、统计插件、相关文章插件做大范围扫描；
wp_postmeta查询没有合适索引；- 数据库和 PHP 在同一台小内存 VPS 上互相抢资源。
查看 autoload 大小：
SELECT SUM(LENGTH(option_value)) / 1024 / 1024 AS autoload_mb
FROM wp_options
WHERE autoload = 'yes';
如果 autoload 数据几十 MB，后台慢很正常。
查看最大 autoload 项：
SELECT option_name, LENGTH(option_value) AS size
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size DESC
LIMIT 20;
不要看到大字段就删。先确认来自哪个插件，备份后再处理。
小 VPS 上 MySQL 调优最怕照抄 16GB/32GB 服务器配置。
1C2G 或 2C4G 的 WordPress 站点，可以重点看：
[mysqld]
innodb_buffer_pool_size=512M
innodb_log_file_size=128M
max_connections=50
table_open_cache=2000
tmp_table_size=64M
max_heap_table_size=64M
这里只是起点，不是万能模板。
innodb_buffer_pool_size 是核心参数。它太小，数据库频繁读盘；太大，PHP 和系统没内存。单机 WordPress 上，通常不要把 MySQL 吃到系统失去余量。
如果是 1C1G：
- MySQL buffer pool 不要贪大；
- PHP-FPM max_children 要保守；
- Redis 可以上，但要限制内存；
- 必要时加 ZRAM/Swap；
- 插件数量要克制。
如果是 2C4G：
- 可以给 MySQL 1G 左右起步；
- PHP-FPM 子进程可以更宽松；
- Redis 128-256MB 足够很多站点；
- FastCGI Cache 命中后压力会明显下降。
WordPress 慢，经常不是“WordPress 慢”，而是某个插件慢。
常见高风险插件类型：
- 页面构建器；
- 统计分析插件；
- 相关文章插件；
- 站内搜索插件；
- 安全扫描插件；
- 备份插件；
- WooCommerce 附加插件；
- 会向外部 API 请求的插件。
排查方式：
- 先备份；
- 在低峰期逐个停用可疑插件；
- 看 TTFB、后台加载、慢查询日志；
- 用 Query Monitor 查看慢查询和钩子；
- 能用服务器层解决的，不要全靠插件。
如果插件停用后速度明显恢复，说明瓶颈不在 VPS，而在应用层。
WordPress 图片多时，VPS 本地磁盘、带宽和 PHP 都会吃压力。
建议：
- 上传前压缩图片；
- 使用 WebP/AVIF；
- 开启 lazy loading；
- 缩略图尺寸不要生成太多；
- 静态资源走 CDN；
- 大量媒体文件考虑对象存储。
什么时候要考虑对象存储，可以看：
如果是个人博客，Cloudflare + 本地磁盘通常够用。如果是图片站、下载站、素材站，把大量文件长期压在 VPS 系统盘上，后面很容易扩容、备份、迁移都麻烦。
如果你的 WordPress 现在已经慢了，按这个顺序做：
curl测 TTFB，确认是后端慢还是静态资源慢；top/free/iostat看 CPU、内存、I/O；- 检查 PHP-FPM
pm.max_children是否过小或过大； - 确认 OPcache 已启用；
- 安装 Redis Object Cache；
- 给匿名页面上 Nginx FastCGI Cache 或成熟缓存插件；
- 打开 MySQL 慢查询日志，找插件和查询问题；
- 清理过大的 autoload options；
- 减少重插件、慢插件、重复缓存插件；
- 图片压缩、CDN、必要时对象存储；
- 如果资源仍然持续打满，再升级 VPS。
这个顺序的好处是：先修最便宜、最常见、最确定的问题。不要一开始就升级机器，也不要一开始就装十个插件。
| VPS 配置 | 适合站点 | 优化重点 |
|---|---|---|
| 1C1G | 个人博客、低流量展示站 | OPcache、页面缓存、少插件、ZRAM |
| 1C2G | 普通博客、小企业站 | Redis、FastCGI Cache、保守 PHP-FPM |
| 2C4G | 多插件 WordPress、小型 WooCommerce | MySQL buffer pool、Redis、慢查询优化 |
| 4C8G+ | WooCommerce、会员站、内容站 | 数据库索引、对象存储、CDN、监控告警 |
如果你还在选机器，可以参考：
不一定。如果是 OPcache 没开、PHP-FPM 配错、插件慢查询、缓存缺失，换机器只能缓解，不能根治。先排查 TTFB、PHP、数据库和缓存，确认资源确实长期不足，再升级。
Redis Object Cache 缓存的是 WordPress 对象和数据库查询结果，主要帮助后台、动态页面和复杂插件。页面缓存缓存的是最终 HTML，主要帮助未登录用户访问前台页面。两者可以一起用，但不要装多个同类插件互相打架。
纯博客、企业站、文档站更适合 Nginx FastCGI Cache，性能好、绕过 PHP。普通用户如果不熟 Nginx，用一个成熟缓存插件更安全。WooCommerce、会员站要非常小心缓存排除规则。
能，但要克制。少插件、轻主题、开启 OPcache、页面缓存、图片优化，必要时加 ZRAM。不要在 1C1G 上硬跑重型页面构建器、WooCommerce、一堆统计插件和本地备份任务。
优先查插件、Redis Object Cache、PHP-FPM 子进程和 MySQL 慢查询。页面缓存通常帮不到后台，因为后台请求不能缓存成静态 HTML。
VPS 上 WordPress 很慢，通常不是一个开关能解决，而是 PHP、缓存、数据库、插件和静态资源共同作用的结果。
最有效的路线是：先用 TTFB 和服务器指标确认瓶颈，再检查 PHP-FPM 和 OPcache，接 Redis Object Cache，给匿名页面做 FastCGI Cache，最后用慢查询日志和插件排查把真正拖慢网站的东西找出来。
等这些都做完，如果 CPU、内存、磁盘 I/O 仍然长期吃满，再升级 VPS。这样花出去的钱才是在解决真实瓶颈，而不是替错误配置买单。