2026.09.06

WordPress 排程沒有執行？從 Loopback Request 錯誤定位 WP-Cron

維護 WordPress 時，可能會遇到排程文章沒有發布、外掛工作延遲，或「網站健康狀態」出現 Loopback request failed。執行 wp cron test 時，則可能看到 Error: WP-Cron spawning failed、cURL timeout、403 或 SSL 憑證錯誤。

這類問題和 PHP Fatal error 不同，先不要直接停用全部外掛。WordPress 的 WP-Cron 通常會由網站請求觸發，主機必須能連回自己的 wp-cron.php。以下流程從可觀察的錯誤開始，確認是網址、DNS、TLS、防火牆、WAF，還是主機排程設定造成。

先確認排程是否真的卡住

先記錄受影響的工作，不要只看前台結果。排程文章可到「文章」檢查是否停在未來日期；外掛排程則使用 WP-CLI 列出即將執行的事件：

cd /var/www/html
wp cron event list --due-now
wp cron test

正常時，wp cron test 應回報 Success: WP-Cron spawning is working as expected.。若沒有待執行事件，排程未執行不一定是故障；若有大量 due events，才繼續檢查回呼與執行環境。

直接測試 wp-cron.php 的回呼

從網站主機執行 HTTP 測試，確認主機是否能透過正式網址連回自己。請把網址換成網站實際的 HTTPS 網址：

curl -I -L --max-time 15 "https://example.com/wp-cron.php?doing_wp_cron"

回應不是一定要固定為 200，但不應出現 DNS 解析失敗、連線逾時、TLS 憑證錯誤、401/403，或被 WAF 導向驗證頁。可依結果縮小範圍：

Could not resolve host：檢查主機 DNS、內部解析與 siteurl 是否仍指向舊網域。
Operation timed out 或 cURL error 28：檢查主機防火牆、雲端安全群組、代理伺服器與 WAF 是否阻擋自己連回網站。
403、401 或驗證頁：確認安全外掛、Basic Authentication、Cloudflare/WAF 規則沒有攔截 /wp-cron.php。
SSL certificate problem：檢查正式憑證鏈、主機時間與 PHP/cURL 使用的 CA 憑證；不要在正式環境用關閉 TLS 驗證來掩蓋問題。

若網站前方有反向代理，也要比對 WordPress 的 home、siteurl、HTTP/HTTPS 判斷與代理標頭。可用 wp option get home 和 wp option get siteurl 確認目前設定，不要只看瀏覽器網址。

手動執行前先評估副作用

為了確認 PHP 與 WordPress 是否能執行，可以在低流量時段執行 due events：

wp cron event run --due-now --debug

這不是單純的讀取操作，可能送出通知信、同步資料、清理快取，甚至處理訂單。正式站執行前先記錄事件清單，必要時在測試環境重現；若單一事件失敗，再查看 PHP error log 與該外掛文件，不要反覆重跑造成重複寄信或重複同步。

改用系統 Cron 的設定方式

若主機環境不適合依賴訪客請求觸發 WP-Cron，可以改由系統 Cron 每五分鐘呼叫 WP-CLI。先在 wp-config.php 加入：

define( 'DISABLE_WP_CRON', true );

接著用執行 WordPress 的系統帳號設定 Cron，例如：

*/5 * * * * cd /var/www/html && /usr/local/bin/wp cron event run --due-now --quiet >> /var/log/wp-cron.log 2>&1

請依主機實際路徑調整 wp、網站目錄與日誌位置，並確認系統帳號能讀取 WordPress 檔案及執行 PHP。不要同時保留多組系統 Cron，也不要在尚未確認系統 Cron 正常前就停用原本的 WP-Cron。

驗證、回復與風險

修正後重新執行 wp cron test，再用 wp cron event list 觀察 due events 是否下降，並檢查排程文章、表單通知或外掛同步結果。若改用系統 Cron 後出現權限錯誤、事件沒有執行或負載升高，可先移除 DISABLE_WP_CRON、停用新增的系統 Cron，回到原本設定，再依錯誤逐項處理。

若網站曾長時間累積排程，恢復後可能在短時間內執行大量工作，造成 CPU、資料庫或寄信服務負載上升。建議分批執行並觀察主機監控。排程文章的其他處理方式，可延伸閱讀站內的WordPress 錯失排程實務；若要進行設定變更，也應先依WordPress 備份與還原實務確認可回復的備份。