WordPressサイトヘルスの「cURL error 28: Operation timed out」は、WordPressから外部または自サイトへのHTTP通信が制限時間内に完了しなかったエラーです。更新確認、REST API、外部API、バックアップ先通信など、失敗したURLと所要時間をログで特定し、タイムアウト値だけを延ばす前にDNS・SSL・WAF・相手先応答を確認します。
最初に結論：失敗URLと通信方向を特定し、DNS・SSL・遮断を順に確認する
- サイトヘルスのエラー全文とURL、秒数を保存する
- 同時刻のWordPressデバッグログとPHPログを確認する
- 自サイト向けか外部サービス向けかを分ける
- DNS解決、SSL証明書、WAF・Basic認証を確認する
- 原因修正後に該当機能とサイトヘルスを再実行する
「28」は通信が規定時間で終わらなかった結果で、原因名ではありません。相手先障害、名前解決、IPv6経路、SSL検証、ファイアウォール、重い自サイト処理まで候補があります。
cURL error 28で確認すべき通信先
WordPressはwp_remote_getなどを通じてWordPress.org、ライセンスサーバー、決済、メール、REST API、自サイトのループバックへ接続します。エラー文のURLと「after 10001 milliseconds」などの時間が、どの機能のどこで待ったかを示します。
| 確認結果 | 疑う場所 | 次の行動 |
|---|---|---|
| wp-jsonや自サイトURL | ループバック・REST API | サイトヘルスとWAFを確認 |
| api.wordpress.org | DNS・外向き通信・一時障害 | 名前解決と公式稼働状況を確認 |
| 特定プラグインのAPI | 相手先・認証・製品設定 | 製品ログと資格情報を確認 |
| SSL certificate文言もある | 証明書チェーン・時刻 | 証明書とサーバー時刻を確認 |
最初の10分で確認する4項目
- WordPress管理画面の「ツール」→「サイトヘルス」→「ステータス」を開き、cURL error 28の全文、発生時刻、接続先URL、待機時間を記録します。
- 「ダッシュボード」→「更新」で更新情報を再取得し、WordPress.org向け通信だけが失敗するのか確認します。
- ログアウト状態の別ブラウザでトップ、問題ページ、フォームを一度ずつ開き、公開ページ全体も遅いかを分けます。
- 同じ時刻のWAF・PHPエラー・バックアップや定期処理のログを照合し、変更前の状態を残します。
公開ページが正常で更新確認だけが失敗するなら、サイト全体の停止とは限りません。反対に、管理画面と公開ページの両方が遅く、複数の外部通信が同時に失敗する場合は、特定プラグインだけでなくDNSやサーバー負荷を優先して確認します。
WAFを確認するときは全体を長時間OFFにしない
WAFやセキュリティ機能のログで、エラーと同じ時刻・同じ接続先が遮断されていないか確認します。該当記録がないままWAF全体を停止しても原因の切り分けにはなりません。除外が必要な場合は公式サポートの案内に従い、対象URLやルールを最小範囲に限定し、確認後は元の状態へ戻します。
PHP処理やサーバー負荷を確認する条件
同じ時間帯に公開ページも遅い、PHPエラーログにメモリ不足がある、バックアップなどの重い処理が重なっている場合は、サーバーのCPU・メモリ・同時実行処理を確認します。タイムアウト値だけを大きくすると原因を隠すことがあるため、先に遅い処理と発生時刻を特定してください。
手順1：エラー全文からURLと時間を読む
サイトヘルスの項目を展開し、ホスト名、ポート、タイムアウト秒数、併記されたSSLやDNS文言を保存します。エラーが出た画面だけでなく、その直前に行った更新・送信・API同期も記録します。
同じ時刻のPHPログに呼び出し元プラグインのパスがあれば、機能を特定できます。URLに認証情報が含まれる場合は伏せてサポートへ共有します。
手順2：自サイトへのループバックを確認する
「ツール → サイトヘルス」でREST APIとループバックの両方を確認します。Basic認証、メンテナンスモード、WAF、IP制限がサーバー自身からのアクセスを拒否していないかを見ます。
https://自サイト/wp-json/
が未ログインでJSONを返すか確認します。404や403ならパーマリンク、セキュリティ設定、REST制限を切り分けます。
手順3：DNS・SSL・外向き通信を確認する
対象ホストが正しいIPへ名前解決できるか、SSL証明書の期限と中間証明書が正しいかを確認します。サーバー時刻のずれもTLS検証へ影響します。
外部サービス一件だけなら相手先の障害情報とAPI制限を確認します。すべての外向き通信が止まる場合はサーバーのファイアウォール、プロキシ、DNSをサポートへ確認します。
タイムアウト延長を最後にする理由
大容量処理など正常に時間がかかる根拠がある場合だけ、製品の公式設定で待ち時間を段階的に延ばします。相手が応答しない状態で延長すると、管理画面やcronの待ち時間が長くなります。
修正後は更新確認、予約処理、該当API、サイトヘルスを再実行し、処理時間も記録します。エラーが消えても機能結果が届かなければ未解決です。
同じ28番でも、失敗したURLで原因の候補が変わるんですね。数字だけ検索して、紹介された設定を全部試そうとしていたので少し恥ずかしいです。
原因を早く直したくて数字へ目が行くのは自然だよ。自サイトならループバック、外部ならDNS・SSL・WAF・相手先というように、通信方向を分けられたのが大きいね。
もう一度実行したら成功する時もあって、直ったのか偶然なのか迷います。一回エラーが消えただけで終わりにしたら、予約処理の時にまた止まりそうです。
その迷いは大事だよ。時刻と処理時間を残して数回確認し、同じURLだけ失敗するかを見よう。一時的なら相手先や負荷、毎回なら遮断や名前解決を疑いやすくなるね。
失敗URL別に確認する場所を変える
wp-jsonや自サイトURLで止まる場合
エラーのURLが自サイトの
/wp-json/
やトップページなら、WordPressが自分自身へ接続するループバック通信を確認します。まずログアウトした別ブラウザで対象URLを開き、JSONが表示されるか、403・401・500のどれになるかを記録してください。401ならBasic認証、403ならWAFやセキュリティプラグイン、500ならPHPログを優先します。
サイトヘルスの「REST APIで予期しない結果が発生しました」と同時に出る場合は、WAFを恒久的に無効化せず、発生時刻と対象ルールを照合します。一時解除で再検査したら、確認後に元へ戻し、必要な通信だけ許可できるかサーバー会社へ相談します。
api.wordpress.orgで止まる場合
api.wordpress.org
への通信は、WordPress本体・テーマ・プラグインの更新確認に使われます。更新画面を再読み込みし、同じホストだけが毎回失敗するかを確認してください。一度だけ失敗して次は成功するなら、WordPress.org側の一時的な混雑や経路遅延も候補です。
毎回失敗し、ほかの外部APIにも接続できない場合は、サーバーから外向きのHTTPS通信全体を疑います。エラー全文、発生時刻、接続先ホスト、PHPバージョンを添え、「サーバーから443番ポートの外向き通信とDNS解決を確認したい」とサポートへ伝えると調査範囲が明確になります。
特定プラグインのAPIだけで止まる場合
決済、フォーム、バックアップ、ライセンス認証など特定製品のドメインだけが失敗するなら、サイト全体よりその製品の設定を先に見ます。APIキーの有効期限、接続先URL、契約状態、相手先の障害情報を確認し、プラグインの再保存や再認証は公式手順がある場合だけ行ってください。
本番サイトで全プラグインを停止する必要はありません。ステージング環境かトラブルシューティングモードで対象製品だけを切り分け、同じ操作で成功・失敗が変わるかを比較します。停止しても同じURLでタイムアウトするなら、プラグイン競合より通信経路や相手先を優先できます。
SSL certificateの文言も出る場合
タイムアウトと一緒に証明書検証の文言があるときは、待ち時間よりSSLを先に直します。対象URLをブラウザで開き、証明書の有効期限、ホスト名、中間証明書を確認してください。サーバー時刻が大きくずれている場合も、有効期間の判定に失敗します。
「SSL検証を無効にする」コードは診断の近道に見えますが、本番の解決策にはしません。証明書チェーンやCA情報を直したうえで、同じAPI操作とサイトヘルスを再実行し、警告が消えて実際の通信結果まで返ることを確認します。
管理画面へ入れる場合・入れない場合の進め方
管理画面へ入れる場合
サイトヘルス、対象機能の設定画面、更新履歴を先に確認し、直前の変更を一件だけ戻します。変更後は未ログイン画面を開き、キャッシュされた管理者表示だけで判断しません。
管理画面へ入れない場合
サーバーパネルのファイル管理とエラーログを使い、対象ドメインとWordPress設置先を照合します。フォルダ名変更などの一時停止は対象一件に限定し、元の名前と変更時刻を記録します。復旧後は管理画面から正式な更新・設定を行い、一時変更を放置しません。
特定のプラグインAPIで止まっているようですが、いきなり停止してサイトが崩れないか心配です。エラーを消すためだけに、本番で全部のプラグインを止めるのも怖いです。
本番で全部止める必要はないよ。エラーの発生操作と時刻を控え、可能ならステージングかトラブルシューティングモードで対象だけを切り分けよう。WAFログも同じ時刻で見るんだ。
待ち時間を長くすればエラー表示だけは消えそうで、少し魅力的に見えます。でも遮断された通信を長く待つだけなら、管理画面まで遅くなってしまいますね。
そう、延長は正常な長時間処理だと分かった後だよ。変更するなら元の秒数を記録し、一項目だけ変えて再実行しよう。改善しなければすぐ元へ戻せるね。
サポートへ相談するときに伝える内容
「直りません」だけでなく、記事タイトルの症状が出たURL、発生時刻、エラー全文、直前の操作、再現手順、試した項目と結果、PHP・WordPress・対象製品のバージョンをまとめます。ログに個人情報、Cookie、APIキー、パスワードがあれば伏せてください。
サーバー会社にはHTTP状態・PHPログ・DNSやWAFなど基盤側の確認を、プラグイン提供元には製品名・バージョン・再現操作を伝えます。問い合わせ先を分けると、同じ確認を何度も繰り返さずに済みます。
直ったと判断する条件
サイトヘルスの再検査でエラーが消え、失敗していた更新・REST・API処理が規定時間内に完了し、PHPログへ同じタイムアウトが増えない状態です。
- 失敗URLと秒数を記録した
- 通信方向を分類した
- DNSとSSLを確認した
- 遮断設定を必要範囲だけ修正した
- 該当機能の結果を確認した
復旧作業を落ち着いて進められるサーバー環境
cURL error 28はサーバー移転を先に行う問題ではありません。利用中サーバーでWAF・DNS・SSL・PHPログを確認できず、サポートへエラー全文と発生時刻を伝えても調査範囲が分からない場合だけ、運用環境を比較します。
エックスサーバー
サーバーパネルのWAF・PHP・ログ確認と、国内サポートへの相談経路を整理したい人の比較候補です。cURL error 28が一時的な相手先障害なら移転は不要です。
エックスサーバーの管理機能と料金を見る広告・PRを含みます。料金・特典は公式ページで最新条件をご確認ください。
よくある質問
タイムアウトを30秒へ増やせば直りますか？
原因が遅い正常処理なら改善する場合がありますが、DNSや遮断なら待ち時間が伸びるだけです。
サイトヘルスの警告は無視できますか？
更新、cron、REST APIなどの機能へ影響するため、失敗URLと対象機能を確認してください。
IPv6を無効にすべきですか？
経路問題の根拠がある場合の切り分け候補です。全体設定を変える前にDNS結果と接続ログを確認します。
最初はcURLを入れ直す話だと思っていました。失敗URL、通信方向、時刻をそろえるだけでも、サーバー会社へ伝えられる内容がずいぶん増えて安心しました。
数字だけで慌てず、どの機能がどこへ通信したか整理できたのがいいね。サイトヘルスの表示だけでなく、更新や予約処理が実際に完了するかまで見られたよ。
一度直っても、負荷が高い時間だけ再発したらまた迷いそうです。次はエラー全文を消さず、発生時刻と一緒に残してから確認します。
それで大丈夫だよ。毎回同じ通信が失敗するなら遮断やDNS、一時的なら相手先や負荷を優先して見よう。原因を確かめる前に待ち時間だけを延ばさないことが一番大切だね。
まとめ：番号ではなく、失敗URLと通信結果を見る
エラー全文からURLと秒数を読み、自サイト通信か外部通信かを分けます。DNS、SSL、WAF、相手先を直し、サイトヘルスだけでなく失敗した機能の結果まで成功して完了です。
通信ログやSSL・WAF設定を一つのパネルで確認したい場合は、失敗URLを特定してからサーバー環境を比較できます。
エックスサーバーの公式情報を確認する