![[图3：执行核心升级时返回 524 No Reason Phrase]](https://media.shuijingwanwq.com/2026/07/3-28.png)
![[图2，EdgeOne 昨日 L7 访问流量，显示 6.56 GB]](https://media.shuijingwanwq.com/2026/07/2-20-1024x480.png)
![[图4：EdgeOne 按 URL path 开始于 /en/ 筛选后的流量截图]](https://media.shuijingwanwq.com/2026/07/4-24-1024x664.png)
最近在给 WordPress 做一次小版本更新时，遇到了一个比较典型的问题：后台点击核心升级后，页面长时间没有返回结果；再次点击更新时，又提示“另一更新正在进行”；偶尔则直接返回 524。
这类问题看起来像是 WordPress 更新失败，但真正排查下来，问题并不一定出在 WordPress 核心文件本身，而更像是后台升级这个长请求在 CDN 代理链路中没有正常完成。
我的网站当前架构大致是：
浏览器
↓
EdgeOne
↓
Nginx
↓
PHP-FPM
↓
WordPress
前台页面走 EdgeOne 缓存没有问题，但 WordPress 后台的更新、插件安装、主题更新这类操作，本质上属于长时间 PHP 请求。如果这类请求经过 CDN，就有可能遇到超时问题。
![[图1：WordPress 后台提示有 7.0.1 版本可更新]](https://media.shuijingwanwq.com/2026/07/1-30.png)
一开始，WordPress 后台正常显示有新的版本可以更新：
当前版本：7.0
可更新至：WordPress 7.0.1-zh_CN
点击更新后，页面进入升级过程。
![[图2：升级 WordPress 页面提示“另一更新正在进行”]](https://media.shuijingwanwq.com/2026/07/2-29.png)
过了一段时间后，再次点击更新，后台提示：
另一更新正在进行。
这个提示本身并不是最终原因，而是 WordPress 的升级锁还没有释放。
WordPress 在执行核心升级时，会在数据库的 wp_options 表里写入一个锁：
core_updater.lock
正常情况下，升级完成后这个锁会自动删除。可是如果升级请求中途失败、超时或中断，锁就可能残留在数据库里。后续再点击升级，WordPress 就会认为“还有另一个更新正在进行”。
![[图3：执行核心升级时返回 524 No Reason Phrase]](https://media.shuijingwanwq.com/2026/07/3-28-1024x500.png)
之后又尝试了一次升级，浏览器直接返回：
524 No Reason Phrase
当时访问的 URL 是：
/wp-admin/update-core.php?action=do-core-upgrade
这个地址不是普通的更新页面，而是真正执行 WordPress 核心升级动作的请求。它会涉及下载升级包、解压、复制核心文件、清理旧文件等操作。
普通后台页面访问正常，但执行升级动作时返回 524，这说明问题很可能集中在“后台升级长请求”本身，而不是整个网站不可用。
为了确认 WordPress 是否已经半升级，我在服务器上检查了当前核心版本：
cd /data/wwwroot/www.shuijingwanwq.com
grep "\$wp_version" wp-includes/version.php
输出结果是：
$wp_version = '7.0';
这说明核心文件仍然是 7.0，并没有升级到 7.0.1。
接着检查网站根目录是否有残留升级包：
ls -lh /data/wwwroot/www.shuijingwanwq.com | grep wordpress
没有输出，说明根目录下没有 wordpress-*.zip 之类的残留文件。
再检查 WordPress 的升级临时目录：
ls -ld wp-content/upgrade
输出类似：
drwxr-xr-x 2 www www 4096 7月 8 13:02 wp-content/upgrade
![[图4：wp-content/upgrade 目录存在，但没有明显升级包残留]](https://media.shuijingwanwq.com/2026/07/4-28.png)
这个目录本身是正常的，不能说明升级包已经下载完成。结合前面的检查结果，这次升级没有留下明显的临时升级文件。
随后我在数据库中查询升级锁：
SELECT option_name, option_value
FROM wp_options
WHERE option_name='core_updater.lock';
查询结果中确实存在：
core_updater.lock
![[图5：数据库中查询到 core_updater.lock]](https://media.shuijingwanwq.com/2026/07/5-22.png)
这就解释了为什么后台会提示：
另一更新正在进行。
随后删除这个残留锁：
DELETE FROM wp_options
WHERE option_name='core_updater.lock';
![[图6：删除 core_updater.lock 执行成功]](https://media.shuijingwanwq.com/2026/07/6-18.png)
删除后再次查询：
SELECT option_name, option_value
FROM wp_options
WHERE option_name='core_updater.lock';
没有查询到结果，说明升级锁已经清理成功。
![[图7：再次查询 core_updater.lock，结果为空]](https://media.shuijingwanwq.com/2026/07/7-9.png)
清理锁之后，刷新 WordPress 更新页面，后台恢复正常显示：
当前版本：7.0
有新的 WordPress 版本可供升级
![[图8：清理锁后，WordPress 更新页面恢复正常]](https://media.shuijingwanwq.com/2026/07/8-8.png)
到这里可以确认几点：
第一，WordPress 核心文件没有半升级。
第二，wp-content/upgrade 没有明显残留升级包。
第三，文件权限也正常。核心目录权限如下：
ls -ld wp-admin wp-includes
输出结果：
drwxr-xr-x 9 www www 4096 5月 21 12:02 wp-admin
drwxr-xr-x 35 www www 16384 5月 21 12:02 wp-includes
这说明 wp-admin 和 wp-includes 都属于 www 用户，权限不像是问题根源。
第四，普通后台访问是正常的。我用 curl 检查更新页面：
curl -I https://www.shuijingwanwq.com/wp-admin/update-core.php
返回结果中可以看到：
HTTP/2 302
location: https://www.shuijingwanwq.com/wp-login.php?redirect_to=...
eo-cache-status: MISS
这说明 /wp-admin/update-core.php 页面本身可以正常访问，也没有被 EdgeOne 缓存。
真正出问题的是执行升级动作时的这个请求：
/wp-admin/update-core.php?action=do-core-upgrade
它需要较长时间执行，但经过 EdgeOne 后，最终返回了 524。
这次排查后，我没有继续手动覆盖升级。虽然手动升级 WordPress 核心可以解决当前这一次 7.0 到 7.0.1 的问题，但这不是长期方案。
因为后续还会有：
WordPress 核心更新
插件更新
主题更新
翻译文件更新
安全补丁更新
如果每次都手动处理，维护成本会非常高，也容易引入新的风险。
这次真正需要解决的不是“怎么把 7.0.1 手动升上去”，而是：
WordPress 后台管理操作不应该和前台页面访问完全走同一条 CDN 链路。
前台页面适合走 EdgeOne：
用户访问
↓
EdgeOne
↓
缓存页面
↓
源站 WordPress
但后台管理入口更适合单独处理，例如后续可以考虑：
www.shuijingwanwq.com
↓
EdgeOne
↓
前台页面
admin.shuijingwanwq.com
↓
源站 Nginx
↓
WordPress 后台
这样前台继续享受 CDN 加速和缓存，后台则尽量减少 CDN 对长请求、登录态、升级操作、插件安装的干扰。
不过这个方案也不能简单粗暴地直接改域名。WordPress 后台涉及：
siteurl
home
登录 Cookie
后台跳转
REST API
媒体文件路径
插件生成的后台链接
所以后续需要单独规划，而不是临时改一个域名就上线。
这次排查的结论是：
WordPress 本身没有明显损坏；
文件权限正常；
升级锁是升级请求中断后的结果；
524 出现在真正执行核心升级动作时；
问题高度集中在 CDN 代理下的后台长请求超时。
短期处理方式：
不再反复点击后台更新按钮；
如果出现“另一更新正在进行”，先确认并清理 core_updater.lock；
暂时保留 WordPress 7.0，不急着手动升级 7.0.1。
长期优化方向：
前台继续走 EdgeOne；
后台管理入口考虑单独域名或单独访问链路；
避免 WordPress 更新、插件安装这类后台长请求经过 CDN。
这次问题虽然没有直接完成升级，但排查结果比单纯升级成功更有价值。因为它暴露的是站点进入生产运营阶段后，前台访问链路和后台维护链路需要分离的问题。
Linux 服务器运维、部署与线上故障排查
如果你的网站或后端服务部署在 Linux 服务器上，遇到访问异常、Nginx 配置问题、MySQL / Redis 异常、Docker 服务不可用、磁盘占满、CPU / 内存过高等问题，可以联系我做一次远程排查。
适合以下场景：
✅ 网站打不开或访问不稳定
✅ Nginx / PHP-FPM 配置异常
✅ MySQL / Redis 性能或连接问题
✅ Docker 服务部署与维护
✅ 服务器迁移与环境配置
✅ CPU / 内存 / 磁盘异常排查
服务内容：
✅ Linux 环境检查
✅ 网站部署与迁移
✅ Nginx / PHP-FPM / MySQL / Redis 排查
✅ Docker 配置与维护
✅ 服务器性能分析
✅ 长期远程运维支持
如需咨询，请联系我，并注明：Linux 运维咨询。
联系方式：
Telegram：@shuijingwan
微信：13980074657
邮箱：shuijingwanwq@gmail.com
发表回复