WordPress 装了 Redis，为什么还没用上？

Redis 安装完成，不代表 WordPress 已经用上了缓存。

我给 InterServer VPS 上的 WordPress 配置 Redis，原本以为装好服务、启动一下就结束了。结果先碰到 Redis 启动失败，修好之后，又发现 WordPress 还没有接上。

这次把过程记下来：服务为什么起不来，PONG 到底说明什么，以及最后怎么确认网站已经连接。

一、为什么给 WordPress 配置 Redis？

我的网站放在 InterServer VPS 上，服务器还要自己维护。

当时先给 PHP 8.2 补了扩展，再配置 WordPress 的持久对象缓存。Redis 在 2026 年 10 月 27 日启动成功，之后继续完成网站接入；主网站切换到 PHP 8.3、处理套接字权限问题，是后面的维护，具体过程见PHP 升级后 502 的回退与修复记录。本文按 Redis 排查过程展开，不按文章发布日期推断操作顺序。

我没有做严格的前后对比测试，所以这篇不写“速度提升几倍”。先把缓存真正接上，再谈有没有改善。

二、安装完成，Redis 却启动失败

服务器是 Ubuntu。我先检查有没有 Redis：

command -v redis-server

没有输出。

随后模拟安装，确认不会删除现有软件，再安装 Redis。安装过程中，终端出现：

Could not execute systemctl

查看服务：

systemctl is-active redis-server

failed

再试连接：

redis-cli ping

Could not connect to Redis at 127.0.0.1:6379:
Connection refused

软件已经装上，但服务并没有正常运行。

三、日志里的问题，和 WordPress 无关

继续查看 Redis 的启动日志，反复出现：

error while loading shared libraries:
libjemalloc.so.2: failed to map segment from shared object

当时 Redis 连启动都没成功，还没到 WordPress 插件这一步。

我检查了对应库文件，文件存在。直接执行：

redis-server --version

能正常显示版本。

换成 Redis 服务使用的用户：

sudo -u redis /usr/bin/redis-server --version

也能执行成功。

这就有点奇怪了：同一个程序，手动运行正常，交给 systemd 服务启动却失败。

四、最后查到服务的执行路径限制

查看 Redis 的 systemd 配置，里面有：

NoExecPaths=/
ExecPaths=/usr/bin/redis-server /usr/lib /lib

接下来用临时服务做对比。

带上这组路径限制，执行版本检查，出现同样的共享库错误；不带这组限制，版本检查成功。

我还单独测试了：

MemoryDenyWriteExecute=yes

这个测试也成功了。

这些结果把排查范围缩到了执行路径限制上。 不是看到报错，就把所有保护设置一起关掉。

最后，我在这台服务器上增加了一个覆盖文件：

/etc/systemd/system/redis-server.service.d/local-paths.conf

内容是：

[Service]
NoExecPaths=
ExecPaths=

这个改动清除了上述两项路径限制，也意味着放宽了这一部分服务保护。它是我这台机器经过对比测试后的处理，不是每台 Ubuntu 都需要照做。

重新加载 systemd 配置，再启动 Redis：

systemctl daemon-reload
systemctl restart redis-server

这次终于显示：

Active: active (running)
Status: "Ready to accept connections"

五、Redis 返回 PONG，为什么 WordPress 对象缓存还没连接？

再运行：

redis-cli ping

这次返回：

PONG

检查监听地址，Redis 只监听本机：

127.0.0.1:6379
[::1]:6379

服务已经起来了。但继续看数据库：

redis-cli INFO keyspace

只有：

# Keyspace

没有其他内容。

随后检查 WordPress 的对象缓存文件：

wp-content/object-cache.php

当时也不存在。

问题到了第二层：Redis 能连接，不代表 WordPress 已经在使用它。

PONG 只能证明这次 Redis 客户端连接正常，不能替 WordPress 确认缓存状态。

六、让 WordPress 连接 Redis 对象缓存

修改前，我先备份了 wp-config.php，并收紧备份文件的权限。这个文件包含网站配置，不适合随便放在公开目录里。

接着给网站设置单独的 Redis 数据库编号和键名前缀：

define('WP_REDIS_DATABASE', 1);
define('WP_REDIS_PREFIX', 'liuqiangwujinjidian:');

我这次使用的是数据库 1，前缀也用了自己的域名，方便区分。前面的 redis-cli INFO keyspace 是接入前的检查，不能仅凭它当时没有列出键，就判断以后的缓存没有生效。接入后应核对插件连接状态、数据库 1 和实际读写；需要查看数据库 1 时，可使用 redis-cli -n 1 DBSIZE，同时注意键数量也不能单独证明 WordPress 缓存命中。

保存后先检查 PHP 语法，确认没有错误，再通过 WordPress 的 Redis 对象缓存插件完成启用。

最后，后台显示已经连接，网站首页和后台也能正常打开。

到这里，才是 Redis 服务和 WordPress 两边都接上了。

七、这次最容易混淆的三个状态

看到的结果	能说明什么
Redis 安装完成	软件包已经安装
`redis-cli ping` 返回 `PONG`	Redis 能接受这次客户端连接
WordPress 对象缓存显示已连接	网站已接入对象缓存

我这次就是一层一层查下来的。

先解决服务启动失败，再处理 WordPress 接入。如果只看到安装完成就结束，后面网站可能根本没用上。

八、接上缓存，不代表访问速度问题全解决了

后来我用中国电信测试网站，首页和文章页都能正常返回 HTTP 200，也记录了首字节时间和总耗时。

但这些测试是在后面做的，没有同条件的启用前数据，不能把结果全部算在 Redis 身上。

缓存是否生效，要确认；速度有没有提升，也要有对比。

这次维护给我的感受还是一样：VPS 月费只是账单上的成本。从安装、看日志到确认网站真正用上，花掉的时间也得算进去。