宝塔多个 WordPress 共用 Redis 配置教程：解决 Redis Object Cache 缓存冲突、站点白屏问题（完整踩坑记录）

前言

最近在一台服务器上部署多个 WordPress 网站，为了提高性能，决定让多个站点共用一个 Redis 实例作为对象缓存。

服务器环境：

• 宝塔 Linux 面板
• Nginx
• PHP 8.2
• MySQL
• Redis 7.x
• Redis Object Cache（Till Krüss）

服务器上有两个独立的 WordPress 网站：

site-a.com
site-b.com

本以为安装 Redis Object Cache 插件，配置一下就结束了。

结果却因为一个不起眼的配置位置，导致两个站点缓存互相影响，折腾了几个小时才最终定位问题。

这篇文章完整记录整个排查过程，希望大家少踩坑。

---

问题现象

测试过程如下：

操作	结果
Site A 开启 Redis	✅ 正常
Site B 不开启 Redis	✅ 正常
Site A + Site B 同时开启 Redis	❌ Site A 白屏、后台异常
关闭 Site B Redis	✅ Site A 恢复正常

最开始甚至出现：

• 后台空白
• 前台异常
• 两个站点缓存互相影响
• 关闭其中一个站点 Redis 后恢复正常

第一反应就是：

Redis 缓存冲突了。

---

第一轮排查

按照网上绝大多数教程配置：

define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_DATABASE', 0);

define('WP_CACHE_KEY_SALT', 'site-a.com:');

第二个站点：

define('WP_CACHE_KEY_SALT', 'site-b.com:');

Redis 插件后台诊断页面也显示：

WP_CACHE_KEY_SALT:
site-a.com:

看起来一切正常。

但是问题依旧。

---

第二轮排查

开始怀疑：

• Redis 数据库冲突
• MySQL 数据库冲突
• object-cache.php 文件不同
• Redis 插件版本不同
• PHP 版本问题

逐一检查：

✅ 两个网站数据库独立

site_a_db
site_b_db

✅ object-cache.php

MD5 完全一致。

✅ Redis Object Cache

插件版本一致。

全部排除。

---

第三轮排查

真正开始查看 Redis。

进入 Redis：

redis-cli

执行：

SELECT 0

KEYS *

结果发现：

wp:posts:1
wp:options:alloptions
wp:users:1
wp:terms:10

全部都是：

wp:

根本没有：

site-a.com:
site-b.com:

说明：

虽然插件后台显示：

WP_CACHE_KEY_SALT

但是 Redis 实际生成 Key 的时候根本没有使用。

---

一个被很多教程忽略的大坑

排查过程中，我发现很多博客、论坛，甚至不少 AI 教程都会告诉你：

把 Redis 配置添加到 wp-config.php 最后一行即可。

例如：

require_once ABSPATH . 'wp-settings.php';

// Redis 配置
define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_DATABASE', 0);
define('WP_CACHE_KEY_SALT', 'site-a.com:');

这就是整个问题的根源。

很多人理解的"最后一行"，实际上已经是在：

require_once ABSPATH . 'wp-settings.php';

之后。

而 WordPress 在执行这一行时，就已经开始加载核心程序。

Redis Object Cache（object-cache.php）也是在这里初始化的。

也就是说：

Redis 初始化完成以后，

你才定义：

WP_REDIS_HOST
WP_REDIS_PORT
WP_REDIS_DATABASE
WP_CACHE_KEY_SALT

已经晚了。

虽然插件后台诊断页面仍然能够读取这些常量，因此你会看到：

WP_CACHE_KEY_SALT:
site-a.com:

让人误以为配置已经成功。

实际上 Redis 初始化时根本没有读取到这些配置。

所以很多人会陷入一个误区：

插件后台显示正常，但 Redis 实际并没有按照你的配置工作。

---

真正原因

我当时的配置就是这样：

require_once ABSPATH . 'wp-settings.php';

/**
 * Redis 配置
 */
define('WP_REDIS_HOST','127.0.0.1');
define('WP_REDIS_PORT',6379);
define('WP_REDIS_DATABASE',0);
define('WP_CACHE_KEY_SALT','site-a.com:');

看起来没有任何问题。

实际上：

Redis 初始化的时候：

WP_REDIS_HOST
WP_REDIS_DATABASE
WP_CACHE_KEY_SALT

全部都还没有定义。

因此：

Redis 自动使用默认配置。

---

正确写法

Redis 配置必须放到：

/* Add any custom values between this line and the "stop editing" line. */

下面。

例如：

define( 'WP_DEBUG', false );

/* Add any custom values between this line and the "stop editing" line. */

/**
 * Redis 配置
 */
define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_DATABASE', 0);

// 每个站点必须唯一
define('WP_CACHE_KEY_SALT', 'site-a.com:');

/* That's all, stop editing! Happy publishing. */

require_once ABSPATH . 'wp-settings.php';

第二个站点：

define('WP_CACHE_KEY_SALT', 'site-b.com:');

即可。

---

修改以后不要忘记这三步

第一步：删除 Drop-in

删除两个站点：

wp-content/object-cache.php

---

第二步：清空 Redis

redis-cli

SELECT 0

FLUSHDB

QUIT

---

第三步：重新启用 Redis

建议：

先开启 Site A。

确认正常以后。

再开启 Site B。

---

如何验证是否真正成功？

不要只看插件后台。

进入 Redis：

redis-cli

执行：

KEYS *

如果看到：

site-a.com:wp:posts:279
site-a.com:wp:terms:39

site-b.com:wp:posts:52
site-b.com:wp:term_meta:2

说明：

缓存已经完全隔离。

如果还是：

wp:posts
wp:terms
wp:users

说明：

你的配置根本没有真正生效。

记住：Redis 中实际生成的 Key，才是判断是否生效的唯一标准。

---

Redis 数据库到底要不要分 DB？

很多教程建议：

Site A → DB0

Site B → DB1

Site C → DB2

实际上：

官方 Redis Object Cache 更推荐：

所有站点：

DB0

不同站点：

WP_CACHE_KEY_SALT

不同即可。

例如：

site-a.com:

site-b.com:

blog.example.com:

shop.example.com:

这样：

几十个 WordPress 网站都可以共用一个 Redis。

无需分 DB。

管理更方便。

---

这次踩坑最大的收获

整个排查过程中，我一直怀疑：

• Redis 服务异常
• Redis 数据库冲突
• MySQL 数据库冲突
• object-cache.php 文件不同
• PHP Bug
• 插件版本问题

最后发现：

真正的问题只有一个。

Redis 配置放错了位置。

更准确地说：

不是写在 wp-config.php 最后一行，而是必须写在 require_once ABSPATH . 'wp-settings.php'; 之前。

这是很多教程都没有说明清楚的地方，也是导致我排查数小时的真正原因。

---

总结

多个 WordPress 网站共用 Redis，只需要牢记四点：

✅ Redis 配置必须放在 wp-settings.php 加载之前。

✅ 每个站点必须设置唯一的 WP_CACHE_KEY_SALT。

✅ 不要轻信"放到 wp-config.php 最后一行"的教程，要确认是在 require_once ABSPATH . 'wp-settings.php'; 之前。

✅ 不要只相信插件后台，一定要进入 Redis 查看实际生成的 Key。

只要满足以上几点，即使几十个 WordPress 网站共用同一个 Redis 实例、同一个 DB0，也不会发生缓存冲突。

---

踩坑总结

很多技术问题，并不是配置写错了，而是配置写对了位置却放错了时机。

插件后台显示正常，并不代表程序初始化时已经读取到了配置。

与其一直盯着插件诊断页面，不如直接进入 Redis 查看实际生成的 Key。

数据不会骗人，Redis 中的 Key 才是真正的答案。