【唐诗】《清平調詞三首 一》 李白：雲想衣裳花想容，春風拂檻露華濃。若非羣玉山頭見，會向瑤臺月下逢。

永夜

没有不值得去解决的问题，也没有不值得去学习的技术！

Troubleshooting Repeated 524 Errors and “Another Update Is Currently in Progress” During a WordPress Core Update

[图3：执行核心升级时返回 524 No Reason Phrase]

作者：

永夜

在

,
Post Views: 6

During a minor WordPress core update, I ran into a fairly typical but easy-to-misread problem: after clicking the core update button in the dashboard, the page kept waiting without a clear result. When I tried again, WordPress reported that “another update is currently in progress.” In some attempts, the request returned a 524 error directly.

At first glance, this looks like a failed WordPress update. After checking it more carefully, however, the issue did not appear to be a partially updated WordPress core. It looked more like the long-running admin update request failed to complete properly while passing through the CDN proxy chain.

The current architecture of my site is roughly as follows:

Plaintext
浏览器
  ↓
EdgeOne
  ↓
Nginx
  ↓
PHP-FPM
  ↓
WordPress

Serving frontend pages through EdgeOne cache works well. But WordPress admin operations such as core updates, plugin installation, and theme updates are long-running PHP requests by nature. If these requests go through a CDN, timeout issues can appear.

[Figure 1: The WordPress dashboard shows that version 7.0.1 is available]
[Figure 1: The WordPress dashboard shows that version 7.0.1 is available]

At the beginning, the WordPress dashboard correctly showed that a new version was available:

Plaintext
当前版本：7.0
可更新至：WordPress 7.0.1-zh_CN

After clicking the update button, the page entered the upgrade process.

[Figure 2: The WordPress update page reports “another update is currently in progress”]
[Figure 2: The WordPress update page reports “another update is currently in progress”]

After waiting for a while and clicking update again, the dashboard showed:

Plaintext
另一更新正在进行。

This message was not the root cause by itself. It only meant that WordPress had not released the core update lock.

When WordPress runs a core update, it writes a lock into the wp_options table:

Plaintext
core_updater.lock

Under normal circumstances, WordPress removes this lock after the update finishes. But if the update request fails, times out, or is interrupted halfway through, the lock may remain in the database. When the update button is clicked again, WordPress assumes that another update is still running.

[Figure 3: The core upgrade request returns 524 No Reason Phrase]
[Figure 3: The core upgrade request returns 524 No Reason Phrase]

I then tried the update again, and the browser returned:

Plaintext
524 No Reason Phrase

The URL being accessed at the time was:

Plaintext
/wp-admin/update-core.php?action=do-core-upgrade

This is not just a normal update page. It is the request that actually performs the WordPress core upgrade. It may need to download the update package, extract it, copy core files, and clean up older files.

Regular admin pages were still accessible, but the upgrade action returned 524. That suggested the problem was likely concentrated in the long-running admin upgrade request itself, rather than the entire website being unavailable.

To confirm whether WordPress had been partially upgraded, I checked the current core version on the server:

Bash
cd /data/wwwroot/www.shuijingwanwq.com
grep "\$wp_version" wp-includes/version.php

The output was:

PHP
$wp_version = '7.0';

This showed that the core files were still on version 7.0 and had not been upgraded to 7.0.1.

Next, I checked whether any leftover update package existed in the site root directory:

Bash
ls -lh /data/wwwroot/www.shuijingwanwq.com | grep wordpress

There was no output, which meant there was no obvious leftover file such as wordpress-*.zip in the site root.

I then checked WordPress’s temporary upgrade directory:

Bash
ls -ld wp-content/upgrade

The output looked like this:

Plaintext
drwxr-xr-x 2 www www 4096 7月 8 13:02 wp-content/upgrade
[Figure 4: The wp-content/upgrade directory exists, but there is no obvious leftover update package]
[Figure 4: The wp-content/upgrade directory exists, but there is no obvious leftover update package]

The directory itself is normal and does not prove that the update package was downloaded successfully. Combined with the previous checks, this update attempt did not leave any obvious temporary upgrade files behind.

I then queried the update lock in the database:

SQL
SELECT option_name, option_value
FROM wp_options
WHERE option_name='core_updater.lock';

The query result confirmed that the following lock existed:

Plaintext
core_updater.lock
[Figure 5: core_updater.lock found in the database]
[Figure 5: core_updater.lock found in the database]

This explained why the dashboard kept showing:

Plaintext
另一更新正在进行。

I then deleted the leftover lock:

SQL
DELETE FROM wp_options
WHERE option_name='core_updater.lock';
[Figure 6: core_updater.lock deleted successfully]
[Figure 6: core_updater.lock deleted successfully]

After deleting it, I queried again:

SQL
SELECT option_name, option_value
FROM wp_options
WHERE option_name='core_updater.lock';

No result was returned, which meant the update lock had been cleared successfully.

[Figure 7: Querying core_updater.lock again returns an empty result]
[Figure 7: Querying core_updater.lock again returns an empty result]

After clearing the lock and refreshing the WordPress update page, the dashboard returned to its normal state:

Plaintext
当前版本：7.0
有新的 WordPress 版本可供升级
[Figure 8: After clearing the lock, the WordPress update page returns to normal]
[Figure 8: After clearing the lock, the WordPress update page returns to normal]

At this point, I could confirm several things:

First, the WordPress core files were not partially upgraded.

Second, there was no obvious leftover update package under wp-content/upgrade.

Third, file permissions also looked normal. The core directory permissions were as follows:

Bash
ls -ld wp-admin wp-includes

The output was:

Plaintext
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

This showed that both wp-admin and wp-includes belonged to the www user. Permissions did not look like the root cause.

Fourth, normal admin access was working. I used curl to check the update page:

Bash
curl -I https://www.shuijingwanwq.com/wp-admin/update-core.php

The response showed:

Plaintext
HTTP/2 302
location: https://www.shuijingwanwq.com/wp-login.php?redirect_to=...
eo-cache-status: MISS

This showed that the /wp-admin/update-core.php page itself was accessible and was not being cached by EdgeOne.

The real problem appeared when the actual upgrade action was executed through this request:

Plaintext
/wp-admin/update-core.php?action=do-core-upgrade

This request needs more time to complete. After going through EdgeOne, it eventually returned 524.

After this investigation, I did not continue with a manual core overwrite. Manually upgrading WordPress core might solve this one update from 7.0 to 7.0.1, but it is not a long-term solution.

Because there will continue to be:

Plaintext
WordPress 核心更新
插件更新
主题更新
翻译文件更新
安全补丁更新

If every update has to be handled manually, the maintenance cost becomes too high and new risks can easily be introduced.

The real problem to solve this time was not “how to manually upgrade to 7.0.1,” but rather:

Plaintext
WordPress 后台管理操作不应该和前台页面访问完全走同一条 CDN 链路。

Frontend pages are suitable for EdgeOne:

Plaintext
用户访问
  ↓
EdgeOne
  ↓
缓存页面
  ↓
源站 WordPress

But the admin entry point is better handled separately. For example, I may consider:

Plaintext
www.shuijingwanwq.com
  ↓
EdgeOne
  ↓
前台页面

admin.shuijingwanwq.com
  ↓
源站 Nginx
  ↓
WordPress 后台

In this setup, the frontend can continue to benefit from CDN acceleration and caching, while the backend can reduce CDN interference with long-running requests, login sessions, updates, and plugin installation.

That said, this solution should not be implemented by simply changing the admin domain in a rough way. The WordPress backend involves:

Plaintext
siteurl
home
登录 Cookie
后台跳转
REST API
媒体文件路径
插件生成的后台链接

So this needs to be planned carefully later, instead of casually changing a domain and pushing it live immediately.

My conclusion from this investigation is:

Plaintext
WordPress 本身没有明显损坏；
文件权限正常；
升级锁是升级请求中断后的结果；
524 出现在真正执行核心升级动作时；
问题高度集中在 CDN 代理下的后台长请求超时。

Short-term handling:

Plaintext
不再反复点击后台更新按钮；
如果出现“另一更新正在进行”，先确认并清理 core_updater.lock；
暂时保留 WordPress 7.0，不急着手动升级 7.0.1。

Long-term optimization direction:

Plaintext
前台继续走 EdgeOne；
后台管理入口考虑单独域名或单独访问链路；
避免 WordPress 更新、插件安装这类后台长请求经过 CDN。

Although this issue did not directly end with a successful upgrade, the investigation was more valuable than simply completing the update. It revealed a broader operational problem: once a WordPress site enters a real production stage, the frontend delivery path and the backend maintenance path may need to be separated.

系列导航

需要长期技术维护或远程问题排查？

我是拥有 15+ 年经验的 PHP / Go 后端工程师，长期关注已有系统维护、Bug 修复、性能优化、服务器排查、WordPress 网站维护和小功能迭代。

如果你的项目遇到以下情况，可以先从一次小问题排查开始合作：

  • ✅ PHP / Laravel / Yii2 老项目无人维护
  • ✅ Go / Gin 后端接口需要排查或优化
  • ✅ WordPress 网站访问慢、报错或插件冲突
  • ✅ Nginx / MySQL / Redis / Linux 服务器异常
  • ✅ CDN / Cloudflare / DNS / HTTPS 配置问题
  • ✅ 需要长期远程技术支持或兼职维护

更多介绍请查看：关于我 & 合作

微信：13980074657
邮箱：shuijingwanwq@gmail.com
Telegram：@shuijingwan
GitHub：https://github.com/shuijingwan

评论

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

这个站点使用 Akismet 来减少垃圾评论。了解你的评论数据如何被处理。

更多文章