欢迎光临
我们一直在努力
当前位置：莱卡云 小知识 正文

WordPress WP-Cron 不执行怎么办？定时任务排查教程

2026-10-10 分类：小知识 阅读(1) [编辑] [删除]

1. WP-Cron 是什么？

WP-Cron 是 WordPress 内置的定时任务系统。

WordPress 核心、主题和插件可以通过 WP-Cron 安排需要在未来执行的任务，例如：

  • 发布计划文章
  • 检查 WordPress 更新
  • 检查主题和插件更新
  • 执行自动备份
  • 发送定时邮件
  • 清理临时数据
  • 运行 WooCommerce 或其他插件任务
  • 生成统计数据
  • 执行缓存清理

WP-Cron 和 Linux 系统中的 Cron 并不完全相同。

Linux Cron 会按照设定时间主动运行，而 WordPress 默认通常是在网站收到访问请求时，检查是否存在已经到期的计划任务。

因此如果网站访问量非常低，或者 WordPress 无法向自身发起回环请求，定时任务就可能延迟甚至长期不执行。

2. WP-Cron 不执行有哪些表现？

比较常见的表现包括：

  • 计划文章到了时间仍然没有发布
  • WordPress 显示“错过计划”
  • 自动备份插件没有按时运行
  • 邮件通知没有发送
  • 缓存插件没有自动清理
  • 网站地图没有定时更新
  • WooCommerce 计划任务堆积
  • 插件后台提示 Cron 不工作
  • 站点健康提示回环请求失败

遇到这些问题时，不建议一开始就删除 WordPress 数据库中的 Cron 数据。

应该先确认 WP-Cron 当前状态和具体失败原因。

3. 进入 WordPress 网站目录

首先通过 SSH 登录服务器，然后进入 WordPress 根目录。

例如：

cd /www/wwwroot/example.com

查看当前目录：

ls -la

正常情况下应该能够看到：

wp-admin
wp-content
wp-includes
wp-config.php
wp-cron.php

如果没有这些文件，说明当前目录可能不是 WordPress 根目录。

后面的 WP-CLI 命令应在正确的 WordPress 目录中执行。

4. 检查 WP-CLI 是否可用

执行：

wp --info

查看当前 WordPress 版本：

wp core version

如果使用 root 用户执行 WP-CLI，部分环境需要添加：

--allow-root

例如：

wp core version --allow-root

如果服务器中没有全局 wp 命令，但网站目录中存在：

wp-cli.phar

可以使用：

php wp-cli.phar --info

后续命令也可以把 wp 替换成：

php wp-cli.phar

5. 测试 WP-Cron 是否能够正常启动

使用WP-CLI检查WordPress Cron计划任务

执行：

wp cron test

root 用户可以执行：

wp cron test --allow-root

正常情况下可能看到：

Success: WP-Cron spawning is working as expected.

这说明 WordPress 当前能够正常触发 WP-Cron。

如果出现 HTTP 403、连接失败、超时或其他错误，说明 WordPress 的 Cron 启动过程存在异常。

需要继续检查：

  • DISABLE_WP_CRON
  • 回环请求
  • 防火墙
  • CDN 或 WAF
  • Basic Auth
  • DNS
  • HTTPS 证书
  • Nginx 或 Apache 配置

6. 查看当前所有计划任务

执行：

wp cron event list

root 用户：

wp cron event list --allow-root

可以只显示常用字段：

wp cron event list \
  --fields=hook,next_run_relative,recurrence \
  --allow-root

可能看到：

hook                 next_run_relative   recurrence
wp_version_check     8 minutes           12 hours
wp_update_plugins    8 minutes           12 hours
publish_future_post  now                 Non-repeating
backup_job           2 hours             1 day

其中：

hook

表示计划任务名称。

next_run_relative

表示距离下一次执行还有多长时间。

recurrence

表示执行周期。

如果某个任务长期显示：

now

或者已经超时很久，通常说明它已经到期但没有正常执行。

7. 手动执行当前已到期的任务

可以执行：

wp cron event run --due-now

root 用户：

wp cron event run --due-now --allow-root

该命令会运行当前已经到期的 Cron 事件。

正常情况下可能看到：

Executed the cron event 'wp_version_check'
Executed the cron event 'publish_future_post'
Success: Executed a total of 2 cron events.

如果手动执行成功，但 WordPress 平时不会自动执行，通常说明：

任务本身可以运行，但自动触发机制存在问题。

接下来应该重点检查回环请求或 DISABLE_WP_CRON。

8. 单独执行指定的 Cron Hook

如果只想测试某一个 Hook，可以先找到它的名称。

例如：

wp cron event list --allow-root

然后执行：

wp cron event run Hook名称 --allow-root

例如：

wp cron event run wp_version_check --allow-root

不要随意运行不了解用途的插件任务。

部分任务可能会：

  • 发送邮件
  • 执行备份
  • 清理数据
  • 同步订单
  • 调用第三方接口
  • 生成大量文件

正式网站操作前，应先确认 Hook 的实际作用。

9. 检查 DISABLE_WP_CRON

打开：

wp-config.php

搜索：

grep -n "DISABLE_WP_CRON" wp-config.php

如果看到：

define( 'DISABLE_WP_CRON', true );

说明 WordPress 默认的访客触发 Cron 已经被关闭。

这不一定是错误。

很多正式网站会主动关闭默认 WP-Cron，再通过 Linux 系统 Cron 定期执行。

但如果关闭 WP-Cron 后，又没有设置系统 Cron，计划任务就不会自动运行。

如果没有配置系统任务，不应只保留：

define( 'DISABLE_WP_CRON', true );

10. wp cron test 提示 WP-Cron 已禁用

如果设置了：

define( 'DISABLE_WP_CRON', true );

再执行：

wp cron test

可能会提示 WP-Cron 已禁用。

这种情况并不一定代表任务系统损坏。

因为该命令测试的是 WordPress 默认的 Cron 启动机制，而当前站点已经主动关闭了它。

此时应该继续确认：

Linux 系统 Cron 是否已经正确配置。

11. 检查系统 Cron 是否存在

Linux系统Cron定时调用WordPress wp-cron.php

查看当前用户的定时任务：

crontab -l

如果使用的是网站用户，还要切换到对应用户后检查。

例如：

crontab -u www -l

如果没有任何任务，而 wp-config.php 又设置了：

define( 'DISABLE_WP_CRON', true );

那么 WP-Cron 很可能没有任何自动触发来源。

12. 使用系统 Cron 调用 wp-cron.php

可以编辑系统 Cron：

crontab -e

加入：

*/5 * * * * curl -fsS "https://example.com/wp-cron.php?doing_wp_cron" >/dev/null 2>&1

将：

example.com

替换成实际网站域名。

这条任务表示：

每 5 分钟请求一次 wp-cron.php。

如果服务器没有安装 curl，也可以根据实际环境使用 wget：

*/5 * * * * wget -q --delete-after "https://example.com/wp-cron.php?doing_wp_cron" >/dev/null 2>&1

配置完成后查看：

crontab -l

确认任务已经保存。

13. 使用 WP-CLI 作为系统 Cron

如果网站服务器已经安装 WP-CLI，也可以直接通过系统 Cron 执行到期任务。

例如：

*/5 * * * * cd /www/wwwroot/example.com && /usr/local/bin/wp cron event run --due-now --quiet --allow-root

需要根据实际环境修改：

  • WordPress 路径
  • WP-CLI 路径
  • 运行用户
  • 是否需要 --allow-root

查看 WP-CLI 实际路径：

which wp

例如输出：

/usr/local/bin/wp

如果可以，正式网站更建议使用网站所属用户运行任务，而不是长期使用 root。

14. 系统 Cron 应该多久执行一次？

普通网站可以考虑：

每 5 分钟

或者：

每 10 分钟

执行一次。

例如：

*/5 * * * * 命令

表示每 5 分钟运行一次。

如果站点存在对时间要求较高的任务，例如：

  • 计划文章
  • 订单状态处理
  • 定时邮件
  • 队列任务
  • 备份任务

可以根据业务需要设置更合适的间隔。

不建议在不了解网站任务量的情况下每分钟执行大量耗时任务。

15. 检查 wp-cron.php 是否可以访问

可以在服务器上执行：

curl -I "https://example.com/wp-cron.php?doing_wp_cron"

如果返回：

HTTP/2 200

通常说明该地址可以访问。

如果返回：

403 Forbidden

可能被以下配置阻止：

  • Nginx 或 Apache 规则
  • CDN
  • WAF
  • 防火墙
  • 安全插件
  • Basic Auth
  • IP 白名单

如果返回：

404 Not Found

需要确认：

  • 域名是否指向正确网站
  • WordPress 路径是否正确
  • wp-cron.php 是否存在
  • Nginx 网站根目录是否正确

16. 什么是 WordPress 回环请求？

WordPress排查WP-Cron回环请求失败

回环请求是指：

WordPress 服务器向自己的网站地址发起请求。

WP-Cron 默认需要通过回环请求启动 wp-cron.php。

站点健康中的以下问题，也可能和回环请求有关：

您的站点无法完成回环请求

如果回环请求失败，可能影响：

  • WP-Cron
  • 计划文章
  • 插件定时任务
  • 主题或插件编辑检查
  • 其他依赖 WordPress HTTP API 的功能

17. 在站点健康中检查回环请求

登录 WordPress 后台，进入：

工具 → 站点健康 → 状态

查看是否存在：

您的站点无法完成回环请求

如果有相关错误，应记录具体提示。

常见错误包括：

cURL error 6

表示域名解析失败。

cURL error 7

表示无法连接目标地址或端口。

cURL error 28

表示请求超时。

403

表示请求被拒绝。

不同错误对应的排查方向不同。

18. 回环请求 403 怎么排查？

如果执行：

wp cron test --allow-root

提示 HTTP 403，可以继续执行：

curl -I https://example.com/wp-cron.php

如果仍然返回 403，重点检查：

  • CDN 安全规则
  • WAF
  • Nginx deny 规则
  • Apache 访问控制
  • WordPress 安全插件
  • Basic Auth
  • IP 白名单
  • 防盗链配置

如果公网域名经过 CDN，而源站本机访问会被拦截，可以继续测试源站回环。

例如：

curl -I http://127.0.0.1/wp-cron.php \
  -H "Host: example.com"

如果本机 Host 测试正常，而公网域名返回 403，问题通常位于 CDN、WAF 或公网代理层。

19. 回环请求 DNS 解析失败怎么办？

首先检查域名解析：

getent hosts example.com

或者：

dig example.com

确认域名解析到了正确服务器。

如果服务器无法解析自己的域名，可以检查：

cat /etc/resolv.conf

如果域名刚刚修改解析，也可能存在 DNS 缓存或传播延迟。

不要在不了解服务器网络结构的情况下随意修改 /etc/hosts。

只有明确知道域名应该指向哪个地址时，才考虑临时增加主机解析进行测试。

20. HTTPS 证书会影响 WP-Cron 吗？

会。

如果 WordPress 网站使用 HTTPS，但证书存在：

  • 过期
  • 域名不匹配
  • 证书链不完整
  • TLS 配置异常

服务器向自己发起 HTTPS 回环请求时可能失败。

可以检查：

curl -Iv https://example.com/wp-cron.php

重点查看：

  • SSL certificate problem
  • certificate expired
  • unable to get local issuer certificate
  • hostname mismatch

应该修复 HTTPS 证书本身，而不是长期关闭证书验证。

21. Basic Auth 会阻止 WP-Cron 吗？

测试站、开发站或后台可能配置了 HTTP Basic Auth。

如果服务器访问：

https://example.com/wp-cron.php

时也需要输入用户名和密码，WordPress 回环请求可能被拦截。

可以测试：

curl -I https://example.com/wp-cron.php

如果返回：

401 Unauthorized

说明请求需要认证。

这时可以：

  • 调整 Basic Auth 规则
  • 为 wp-cron.php 配置例外
  • 使用带认证信息的系统 Cron
  • 使用本地 WP-CLI 执行任务

不要把 Basic Auth 账号密码直接写进公开文章或不安全脚本。

22. 防火墙和安全组会影响回环请求吗？

有可能。

例如服务器访问自己的公网 IP 或域名时，需要经过：

  • 本地路由
  • 云平台网络
  • 防火墙
  • CDN
  • WAF
  • 反向代理

如果其中任何一层阻止请求，回环就可能失败。

可以分别测试：

curl -I https://example.com/wp-cron.php

和：

curl -I http://127.0.0.1/wp-cron.php \
  -H "Host: example.com"

通过结果对比，判断问题发生在本机 Web 服务还是公网链路。

23. 缓存插件会影响 WP-Cron 吗？

部分缓存、安全或优化插件可能影响：

  • 回环请求
  • WordPress HTTP API
  • wp-cron.php
  • REST API
  • 登录验证

如果问题发生在安装或更新某个插件以后，可以先做好备份，然后：

  1. 暂时停用最近变更的插件。
  2. 重新运行 wp cron test。
  3. 逐个恢复插件。
  4. 找出发生冲突的插件。

不要在正式网站中一次性删除全部插件。

可以先在维护时间内进行排查。

24. 主题也可能造成回环请求失败吗？

可能。

某些主题会在 WordPress 加载期间执行额外代码。

如果主题代码出现：

  • Fatal Error
  • 无限循环
  • 外部请求超时
  • 数据库异常

也可能影响 WP-Cron。

可以在测试环境临时切换到 WordPress 默认主题进行对比。

正式网站切换主题可能影响页面显示，应先做好备份并选择合适时间操作。

25. PHP Fatal Error 会导致 Cron 不执行

查看 WordPress 调试日志：

wp-content/debug.log

如果已经开启日志，可以执行：

tail -n 100 wp-content/debug.log

也可以查看 PHP-FPM 日志。

例如：

journalctl -u php8.2-fpm -n 100 --no-pager

实际 PHP 版本需要根据服务器环境修改。

如果某个 Cron Hook 执行时触发 Fatal Error，任务可能每次都失败。

这时应该先修复具体插件或主题错误。

26. 检查 PHP 最大执行时间

部分备份、同步和邮件任务运行时间较长。

如果 PHP 限制过低，任务可能在完成前被终止。

可以查看：

php -i | grep max_execution_time

不过，网站使用的 PHP-FPM 配置可能和命令行 PHP 不同。

还需要检查实际 Web 环境中的：

max_execution_time
memory_limit

不要只为了让任务完成就无限增加 PHP 资源限制。

应该先确认任务本身是否存在异常或死循环。

27. 检查服务器内存和磁盘空间

服务器资源不足也可能导致定时任务失败。

查看内存：

free -h

检查磁盘：

df -h

检查 inode：

df -i

如果磁盘已经达到 100%，WordPress 可能无法：

  • 写入缓存
  • 生成备份
  • 创建临时文件
  • 更新数据库
  • 保存日志

如果内存不足，PHP-FPM 进程也可能被系统终止。

28. 计划文章显示“错过计划”怎么办？

先检查文章状态：

wp post list \
  --post_status=future \
  --fields=ID,post_title,post_date \
  --allow-root

然后查看是否存在：

publish_future_post

任务：

wp cron event list \
  --fields=hook,next_run_relative,args \
  --allow-root

如果 Cron 系统恢复后，可以执行：

wp cron event run --due-now --allow-root

然后再次检查计划文章是否已经发布。

不要直接修改大量文章的数据库时间。

29. 插件 Cron 任务堆积怎么办？

执行：

wp cron event list --allow-root

如果发现大量相同 Hook，可能是：

  • 插件重复注册任务
  • 插件停用时没有清理任务
  • 任务每次执行失败
  • Cron 长期没有正常运行

不要直接执行：

wp cron event delete --all

这会删除全部计划任务，可能影响 WordPress 和其他插件。

应该先确认具体 Hook 属于哪个插件，再决定是否删除、修复或重新注册。

30. WooCommerce 任务和 WP-Cron 是一回事吗？

WooCommerce 及部分插件会使用自己的计划任务管理机制，例如 Action Scheduler。

它们可能仍然依赖 WP-Cron 触发，但后台界面和任务队列与普通 WP-Cron 事件不同。

如果 WooCommerce 订单、邮件或后台任务异常，还需要进入：

WooCommerce → 状态 → 计划操作

查看是否存在：

  • 失败
  • 待处理
  • 过期
  • 长时间运行中

不要只查看 wp cron event list 就认为所有插件队列都正常。

31. 使用系统 Cron 后是否还需要 DISABLE_WP_CRON？

如果已经设置可靠的系统 Cron，可以在：

wp-config.php

中加入：

define( 'DISABLE_WP_CRON', true );

这样可以避免每次访问页面都尝试触发 WP-Cron。

但必须确保系统 Cron 已经正常工作。

正确顺序建议是：

  1. 先配置系统 Cron。
  2. 手动测试系统 Cron。
  3. 确认任务可以正常执行。
  4. 最后再设置 DISABLE_WP_CRON。

不要先关闭 WP-Cron，然后忘记配置替代任务。

32. 如何确认系统 Cron 真的执行了？

可以暂时把输出写入日志文件。

例如：

*/5 * * * * cd /www/wwwroot/example.com && /usr/local/bin/wp cron event run --due-now --allow-root >> /tmp/wp-cron.log 2>&1

等待几分钟后查看：

tail -n 100 /tmp/wp-cron.log

确认任务确实被执行。

验证完成后，可以根据实际需要调整日志策略，避免日志文件无限增长。

33. 多站点怎么执行 Cron？

WordPress Multisite 需要指定具体站点或使用网络参数。

例如：

wp cron event run --due-now \
  --url=https://site.example.com \
  --allow-root

如果需要跨所有站点执行，并且当前 WP-CLI 命令支持，可以使用对应的网络选项。

多站点环境中不要只在主站执行后，就默认所有子站任务都已经完成。

34. WP-Cron 快速排查顺序

建议按照下面的顺序排查：

第一步：进入正确网站目录

cd /www/wwwroot/example.com

第二步：测试 Cron 启动机制

wp cron test --allow-root

第三步：查看任务列表

wp cron event list --allow-root

第四步：执行到期任务

wp cron event run --due-now --allow-root

第五步：检查 wp-config.php

grep -n "DISABLE_WP_CRON" wp-config.php

第六步：检查系统 Cron

crontab -l

第七步：测试 wp-cron.php

curl -I "https://example.com/wp-cron.php?doing_wp_cron"

第八步：检查站点健康回环请求

工具 → 站点健康

第九步：检查插件、主题和 PHP 错误

tail -n 100 wp-content/debug.log

35. 常见问题对照表

问题现象优先检查
计划文章不发布publish_future_post、WP-Cron
wp cron test 成功Cron 启动机制基本正常
wp cron test 提示禁用DISABLE_WP_CRON
手动运行成功，自动不执行回环请求或系统 Cron
返回 403WAF、防火墙、安全插件
返回 401Basic Auth
cURL error 6DNS 解析
cURL error 7连接或端口
cURL error 28请求超时
插件任务大量堆积插件 Hook 或任务执行失败
低流量网站任务延迟使用系统 Cron
系统 Cron 不执行路径、用户、权限、命令

36. 搭建 WordPress 的服务器建议

如果 WordPress 同时运行：

  • WooCommerce
  • 自动备份
  • 邮件任务
  • 缓存预热
  • 数据同步
  • 多个定时插件

需要考虑：

  • PHP-FPM 进程
  • MySQL 性能
  • 内存
  • 磁盘 I/O
  • Cron 任务运行时间

如果需要搭建 WordPress 网站，可以根据访问量和插件数量选择莱卡云 Linux 云服务器。

查看官网购买链接： https://www.lcayun.com

如果站点回环请求因端口或防火墙无法访问，可以继续参考：

相关阅读： 云服务器端口不通怎么办？

37. 总结

WordPress WP-Cron 不执行时，首先执行：

wp cron test --allow-root

确认 WP-Cron 启动机制是否正常。

然后查看当前计划任务：

wp cron event list --allow-root

手动执行已经到期的任务：

wp cron event run --due-now --allow-root

如果手动执行成功，但自动任务仍然不运行，应重点检查：

  • DISABLE_WP_CRON
  • 系统 Cron
  • 回环请求
  • CDN/WAF
  • Basic Auth
  • DNS
  • HTTPS
  • 插件或主题冲突

对于访问量较低或对任务时间要求较高的网站，可以使用 Linux 系统 Cron 定期调用：

wp-cron.php

或者直接执行：

wp cron event run --due-now

配置系统 Cron 后，再根据需要关闭 WordPress 默认的访客触发机制。

正确排查顺序是：

任务列表 → 手动执行 → WP-Cron 测试 → DISABLE_WP_CRON → 系统 Cron → 回环请求 → 插件与服务器资源。

赞(0)
未经允许不得转载：莱卡云 » WordPress WP-Cron 不执行怎么办？定时任务排查教程
分享到

相关推荐