WordPress サイトヘルスチェックでcURLエラー28が発生する原因と対処法（REST API・ループバック）

最近、ちょっと興味深い小さな問題に遭遇しました。私は書籍関連のコンテンツのみを扱うサイトでWordPressを運用しており、ドメインに変更を加える前には、必ずすべてが正常に動作しているかを確認するテストを行っています。その確認作業のきっかけとなったのが、WordPress 5.2で導入された「サイトヘルスチェック」機能です。このツールは、サイト設定における重大な問題や推奨される対応策を教えてくれます。

それ自体は便利な機能なのですが、5.4へアップデートしたところ、突然「重大なエラー」が2件表示されるようになりました。ドメインに新たな問題が発生したことを示すものです。表示されたエラーは「REST APIでエラーが発生しました」と「サイトがループバックリクエストを完了できませんでした」の2つ。いずれの詳細にも「Error: cURL error 28: Operation timed out after 10000 milliseconds with 0 bytes received (http_request_failed)」と記載されていました。奇妙です。では、デバッグしてみましょう。

問題の詳細

「重大な問題」と聞くと不安になりますが、実際の影響を正しく理解するには、潜在的な問題を冷静に見極める必要があります。セキュリティに関わる問題への対応が甘いと責められたくないため、企業がバグやトラブルに過度に厳格になるケースは少なくありません。まずはステータスレポートを見てみましょう。

1つ目の問題は次のように表示されます。

REST APIでエラーが発生しました

REST APIは、WordPressや他のアプリケーションがサーバーと通信するための手段の一つです。一例としてブロックエディター画面が挙げられ、投稿や固定ページの表示・保存はこれに依存しています。

REST APIリクエストがエラーにより失敗しました。
Error: cURL error 28: Operation timed out after 10001 milliseconds with 0 bytes received (http_request_failed)

2つ目は以下の内容です。

サイトがループバックリクエストを完了できませんでした

ループバックリクエストは、定期実行イベントの処理に使われるほか、テーマやプラグインの組み込みエディターがコードの安定性を検証する際にも利用されます。

サイトへのループバックリクエストが失敗しました。この機能に依存する機能は現在、期待どおりに動作していない可能性があります。
Error: cURL error 28: Operation timed out after 10001 milliseconds with 0 bytes received (http_request_failed)

1つ目のエラーは、REST APIがWordPressとサーバーの通信手段の「一つ」であることを示しています。つまり、他の通信手段も存在するということです。エラー自体は、各種操作の実行時に実際に支障が出るかどうかまでは明確にしていません。

エラーではブロックエディターが具体的に言及されています。これはWordPress 5.0で導入されたGutenbergのことですが、私は使用しておらず、優れたClassic Editor（クラシックエディター）プラグインに頼っています。つまり、そもそも私の環境では無関係な問題かもしれません。さらに実際の機能面でも、言及された機能には何の影響もなく、WordPressはすべて期待どおりに動作しています。もしかすると誤検出（false positive）なのでしょうか。すぐに分かります。

2つ目のエラーは、定期実行イベント（バックグラウンドでの更新処理や夜間タスクなど）に関するものです。これも同様に、そうした設定を行っていないのであれば無関係です。設定していても正常に動作していれば、影響は受けません。エラーには「期待どおりに動作していない」とありますが、これはあまり決定的で正確な表現とは言えず、かえってトラブルシューティングを難しくしています。

問題の発生源

しかし、ここでは仮にこれらが本当に深刻な問題だと想定してみましょう。問題は、どこに起因するのかをどう切り分けるかです。これは簡単な作業ではなく、エラーメッセージの中には正しい方向を示す手がかりが一切ありません。

そこで私が行ったのは、デフォルト以外のコンポーネントを一つずつ手動で無効化し、その都度ヘルスチェックを再実行して、どの要素が原因かを特定することでした。幸い余裕を持ってテストできる環境でしたが、本番環境だったらどうなるか想像してみてください。

しばらく試行錯誤を重ね、使用中のすべてのプラグインとテーマを確認しましたが、どれも結果に影響を与えている様子はありません。WordPressは文句を言い続けます。そこで調査範囲を広げることにしました。私は管理ページへのアクセス制御を二重化するため、.htaccessファイルでBasic認証などの設定を行っていました。試しに認証部分を削除してみたところ、なんと問題が解消。ヘルスチェックのエラーは消えたのです！

AuthType Basic
AuthName restricted
AuthUserFile /home/mastablasta/wp-admin/passwd
Require valid-user

つまり、WordPressのサイトヘルスチェックは.htaccessファイルを好まないようです。具体的にどの仕組みでチェックが引っかかるのかまでは調べていませんが、調べる必要もありません。第一に、問題の発生源が特定できたこと。第二に、エラーは私が必要とする機能に影響を与えないため、無視できる問題だからです。

まとめ

サイトヘルスチェックの問題は内部にあることは明らかです。そもそも、WordPress 5.4への移行とともに現れ始めたのですから。もちろん、どこかのコードが変更されたのでしょう。しかし本質的に、コア製品の挙動がアップデート直前と比べて突然大きく変わり、サイトの他の機能に大きな問題がないなら、原因はコアのアップデートにある可能性が高いと言えます。

サイトの問題を一目で把握できる仕組みというのは良いアイデアだと思います。しかし、誤検出や、エラーによる無駄な追跡作業（短時間とはいえ）には満足していません。エラーには意味が必要です。エラーの現れ方から何が問題なのか推測できないのであれば、技術的な詳細を表示してもほとんど意味がありません。cURL error 28と.htaccessは、一見まったく結びつかないように見えるのです。

ともあれ、同じような問題に悩まされている方は、サイトの設定を確認し、Basic認証を使用していないかチェックしてみてください。同じ潜在バグに苦しんでいるかもしれません。以上です。

それでは、また。