WordPress サイトの健全性 - cURL エラー 28 (REST API、ループバック)

最近、興味深い小さな問題を発見しました。私は書籍のみの Web サイトで WordPress を実行していますが、当然のことながら、ドメインに変更が導入される前に、すべてが正常であることを確認するためにテストを行う必要があります。そのような変更の 1 つが、WordPress 5.2 で導入されたサイト ヘルス チェック ツールです。このツールは、重大な問題とセットアップの推奨アクションを通知します。

これ自体は問題ありませんが、5.4 へのアップデートで重大と思われるいくつかのエラーが表示されることに気付きました。これは、ドメインに関する突然の新しい問題を示しています。エラーは次のとおりです。REST API でエラーが発生し、サイトはループバック リクエストを完了できませんでした。エラー:cURL エラー 28:10000 ミリ秒後に 0 バイトを受信して​​操作がタイムアウトしました (http_request_failed)。変。デバッグしましょう。

問題の詳細

重大な問題は憂慮すべきことです。ただし、潜在的な問題を注意深く調べて、実際の影響を理解する必要があります。多くの場合、企業はバグや問題の処理方法に厳しすぎます。セキュリティの複雑化につながる可能性のある問題に手ぬるすぎると非難されることを誰も望んでいないからです。それでは、ステータス レポートを見てみましょう:

創刊号は次のように書かれています:

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

REST API は、WordPress や他のアプリケーションがサーバーと通信する一方向です。 1 つの例は、ブロック エディター画面で、これに依存して投稿とページを表示および保存します。

エラーのため、REST API リクエストが失敗しました。
エラー:cURL エラー 28:0 バイトを受信して​​ 10001 ミリ秒後に操作がタイムアウトしました (http_request_failed)

2 番目のテキストには次のテキストがあります:

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

ループバック リクエストは、スケジュールされたイベントを実行するために使用され、コードの安定性を検証するために、テーマとプラグインの組み込みエディターでも使用されます。

サイトへのループバック リクエストが失敗しました。これは、それらに依存する機能が現在期待どおりに動作していないことを意味します。
エラー:cURL エラー 28:0 バイトを受信して​​ 10001 ミリ秒後に操作がタイムアウトしました (http_request_failed)

最初のエラーは、これが WordPress がサーバーと通信するために使用する 1 つの方法であることを示しています。これは、他の方法があることを意味します。このエラーは、さまざまな操作を実行する際に実際に問題が発生する可能性があるかどうかについて明確ではありません.

ブロックエディターについて具体的に言及しています - WordPress 5.0 で導入されたまったく新しい Gutenberg のものですが、私は使用せず、代わりにすばらしいクラシックエディターに依存しています。ですから、これはそもそも問題ではないのかもしれません。次に、実際の機能の問題があります。言及された機能はどれも影響を受けません。 WordPress は正常に機能し、すべてを正常に実行します。おそらく偽陽性？すぐにわかります。

2 番目のエラーは、スケジュールされたイベント (バックグラウンド更新、夜間のタスクなど) に関するものです。何も構成していない場合、これは問題ではありません。実行し、それらが正しく実行される場合、問題は影響しません。エラーは「期待どおりに動作する」と言っていますが、これは非常に決定論的で正確なステートメントではありません。トラブルシューティングがより困難になります。

問題の原因

しかし、これらが実際に現実の問題であると仮定してみましょう。問題は、それらがどこから発生したかをどのようにトラブルシューティングするかです。簡単なことではありません。実際のエラー メッセージには、正しい方向に導くものは何もありません。

そのため、私がしなければならなかったことは、デフォルト以外のすべてのコンポーネントを 1 つずつ手動でオフにしてから、ヘルス チェックを再実行して、特定の要素に問題があるかどうかを確認することでした。幸いなことに、暇なときにこれをテストすることができましたが、本番環境での影響を想像してみてください。

今...しばらくして、使用していたすべてのプラグインとテーマを試してみましたが、これらのどれも結果に影響を与えていないようでした. WordPress は不平を言い続けました。次に、検索範囲を広げることにしました。管理ページへのアクセス制御の第 2 層として、たまたま、基本認証とその他のいくつかの有用な詳細を含む .htaccess ファイルを使用しています。ほら、認証部分を削除すると修正されました。ヘルスチェックエラーはもうありません!

AuthType Basic
AuthName 制限あり
AuthUserFile /home/mastablasta/wp-admin/passwd
有効なユーザーが必要

つまり、WordPress Site Health は .htaccess ファイルを好みません。これがどのようにチェックを通過するかを正確に調べたことはありませんが、そうする必要はありません。 1つは、問題の原因が何であるかを知っていることです。 2 つ目は、エラーは必要な機能に影響しないため、これは問題ではありません。

結論

サイト ヘルスの問題が内部的なものであることは明らかです。結局のところ、WordPress 5.4 に移行してから問題が発生し始めたのです。もちろん、どこかのコードが変更されていますが、本質的に、コア製品の動作が更新直前とは急激に異なり、サイトの機能の他の要素に大きな問題がない場合は、この問題は、前述のコア製品の更新に起因する可能性が非常に高いです。

私は、このサイトの問題を一目で確認できるようなアイデアは気に入っていますが、誤検知や、エラーによって作成されたガチョウ追跡には満足していません。エラーは意味のあるものである必要があります。エラーの発生方法から何が問題なのか見当がつかない場合は、技術的な詳細を示す意味がありません。 cURL エラー 28 と .htaccess はかなり離れているようです。とにかく、ここにいます。同様の問題の影響を受けている場合は、サイトの構成を調べて、基本認証を使用しているかどうかを確認し、おそらく同じバグに苦しんでいるかどうかを確認してください。これで完了です。

乾杯。