wp-cron 关掉之后，蜘蛛再也不会触发你的定时任务

翻访问日志的时候发现，POST /wp-cron.php 每天都在被各种 IP 请求，其中一大半是蜘蛛和扫描器。

原因是 WordPress 的定时任务本身就是"伪定时"——它没有系统级调度，靠有人访问网站时顺带触发。

一、wp-cron 是怎么工作的

每次有请求进来，WordPress 在 wp-includes/cron.php 里检查：距离上次执行超过 60 秒了吗？超过就发一个非阻塞的 HTTP 请求给自己，也就是 POST /wp-cron.php。

这个请求不等结果（blocking => false），所以页面不会卡。但它确实发生了。

二、问题出在哪

三个：

1. 蜘蛛也会触发。搜索引擎爬 100 个页面，就可能触发 100 次检查。次数一多，PHP-FPM 进程被占满
2. 低流量站点任务不准。没人访问就不执行。说好每小时跑的备份，可能一天只跑了一次
3. 敏感任务被提前触发。有些插件把发邮件、同步数据挂在 cron 上，蜘蛛一爬就打乱节奏

我这边实测：关掉之前，日志里 wp-cron.php 一天 40 次左右，其中 30 次来自非本站 IP。

三、关掉

在 wp-config.php 里加一行：

define('DISABLE_WP_CRON', true);

位置要在 /* That's all, stop editing! */ 这行之前。

加完网站功能不变，只是不再有"访问触发"的 cron。

四、用系统 crontab 接回来

宝塔面板 → 计划任务 → 添加，或者直接命令行 crontab -e：

*/5 * * * * curl -s -o /dev/null "https://你的域名/wp-cron.php?doing_wp_cron" > /dev/null 2>&1

几个细节：

• doing_wp_cron 参数必须带。不带的话 WordPress 会当成普通访问，可能又去触发别的逻辑
• 用 curl 不用 wget，wget 默认会往当前目录写文件
• -o /dev/null 丢掉响应体，-s 静默，避免 crontab 每天给你发一堆邮件
• 间隔别小于 5 分钟，WordPress 内部的最小粒度就是按分钟算的

五、用 wp-cli 更干净

如果服务器装了 wp-cli，直接跑内部命令，连 HTTP 都不走：

*/5 * * * * cd /www/wwwroot/你的站点 && /www/server/php/81/bin/php wp-cron.php > /dev/null 2>&1

好处是不依赖域名解析、不依赖 SSL 证书、不受防火墙影响。缺点是不能跨服务器。

六、验证

看任务列表：

wp cron event list

每行都有 next_run_gmt，正常的话应该都在未来几分钟内。

再看日志，wp-cron.php 的来源 IP 应该只剩你自己服务器的：

grep "wp-cron.php" /www/wwwlogs/你的域名.log | awk '{print $1}' | sort | uniq -c

如果还有一堆外网 IP，说明 DISABLE_WP_CRON 没生效——检查是不是加在了 wp-config.php 的错误位置，或者被缓存了。

七、几个坑

1. 忘了关，又配了 crontab。两套一起跑，任务执行两次。表现是重复发邮件、重复生成缩略图、重复推送。

2. crontab 里的 PHP 路径写错。宝塔的 PHP 在 /www/server/php/81/bin/php，不是 /usr/bin/php。写错就是静默失败，crontab 不会报错，你也不会收到任何通知。

3. 站点开了强制 HTTPS，crontab 用 http 访问。会 301 到 https，而 curl 默认不跟随跳转，任务就断在半路。加 -L 或者直接用 https。

4. 备份类任务跑到一半超时。PHP 默认 max_execution_time 是 30 秒，大站备份跑不完。要么在脚本里 set_time_limit(0)，要么干脆挪到 CLI 里跑。

wp-cron 不是"定时任务"，是"访问触发的顺带任务"。只要理解这一点，要不要关、怎么配，就都没疑问了。