今回の問題点
表題の通り、WordPressの管理画面から「ツール」→「サイトヘルス」を実行すると「cURL error 28: Connection timed out」になってしまう不具合が発生。
しかし、システム上はエラーになる要因が無かったので調査と解決に少し手間取ってしまった。
原因も解決方法も単純だったのですが、Webで検索しても該当する情報が少く解決するのに苦労したので備忘録としてブログに残します。
不具合の原因と解決方法
-
症状
- WordPressの管理画面「ツール」→「サイトヘルス」を開いたときに
「cURL error 28: Connection timed out after 10000 milliseconds」と表示されてしまう。
症状としては以下のFAQに近い
サイトヘルスでREST API エラーサイトヘルスでREST API エラー susumu0607 (@susumu0607) 3年、 9ヶ月前 サ… - WordPressの管理画面「ツール」→「サイトヘルス」を開いたときに
-
原因
- WordPressの管理画面「ツール」→「サイトヘルス」を開いたときに該当ページのphpが正しく動作していなかった(php-curlが動作しなかった)
- 動作しなかった原因はブラウザのキャッシュ(Chromeの履歴)が影響していた
-
解決方法
ブラウザ履歴(キャッシュ)が影響していたので、ブラウザ履歴を削除すれば解決した。
TL;DR
-
調査の手順
- ログを確認する
- ググる
- 不具合が発生したブラウザと別のブラウザで同じ症状が発生するか確認する
※参考までにChrome系ブラウザで履歴を削除する手順を下記する
- ChromeやFirefox等のブラウザを開く
- 設定 ⇨ 左メニュー「プライバシーとセキュリティ」⇨ 「閲覧履歴データの削除」を開く
- 「詳細設定」タブを選択
- 「期間」プルダウンから「全期間」を選択
- チェックボックスから以下3点を選択する
- 閲覧履歴
- Cookieと他のサイトデータ
- キャッシュされた画像とファイル
- 「データ削除」ボタンを実行
その他にも同じエラーが発生する要因があるので箇条書きで纏めておく
-
サイトヘルスのチェック用URLに疎通しているかどうか
-
Firewallやiptables,SELinux,nginxのIP制限等で外部への通信を接続制限している場合は、443ポートからwordpress.orgへ接続できるように設定しておく(※wordpress.orgからの内向き=inbound通信は必要ないので、通常はFirewall等の接続制限が原因である可能性は低い)
-
公式資料では wordpress.orgへの接続が必要だとなっているが、実際には api.wordpress.orgに接続している
- ブログ記載の時点で、
wordpress.orgのIPアドレスは 198.143.164.252,
api.wordpress.orgのIPアドレスは 198.143.164.251
2点のGIP疎通が必要になるように見える(※公式情報ではないので各自で要確認)
- ブログ記載の時点で、
-
公式のアナウンスだと、プラグインやテーマの影響で、前述のURLへの接続に失敗する場合があるらしいので、通信を阻害する疑いのあるプラグインは無効化する(※実際には影響する可能性は低いので、プラグイン無効化よりも後述のブラウザ履歴削除から先に試した方がいい。信頼性を疑うプラグインは不具合の有無に関わらず無効化した方がいい)
-
公式ではアナウンスされていないが、ブラウザの履歴(キャッシュしたファイルとCookie)を削除すると解決する場合がある
- ブラウザのキャッシュが影響していると管理画面の/wp-admin/site-health.php にアクセスしてもphp-curlが実行されない場合があった
-
PWAやAMPの設定が影響して管理画面が正しく動作しない場合がある
- PWAには便利そうな機能が多数公開されているが、実際には悪意のある攻撃者にとってのターゲットになるので、ユーザーとしても開発者としても無効化しておいた方がいい
-
Chromeを使うなら、必ずServiceWorkersを無効化しよう
Chromeを使うなら、必ずServiceWorkersを無効化しよう - Qiita2022/01/17追記:この方法では無効化できません。【Chrome】ServiceWorkerを今度こそ決定的かつ完全に消去するを参照してください。ServiceWorkersというAPIが存…
調査に苦労した点
-
ググっても適切な回答が少ない
-
WordPressにありがちだが、曖昧な表現で「プラグインを全て無効化する」等の現実的ではない回答が目立つ
-
「設定に問題がある」回答が前提なので、調査する方法等が殆ど見当たらない
- 複数のWordPressを運用しているので設定に問題がない事は確認済
- ログにも問題点が出力されないので、phpのコードを追ってパケットの通信を見張ることにした
-
「キャッシュ全削除」や「別ブラウザで試す」のような調査手順の情報が少ない
-
自前の開発だと真っ先にキャッシュを疑うのだが、Webで検索すると「キャッシュ全削除」のような回答が少ない
-
-
tcpdumpでの調査例
- tcpdumpでパケットを見張ると、正常なブラウザでWordPress管理画面「サイトヘルス」を表示するとwordpress.orgへ接続する通信が発生する
- 過去のページキャッシュが残っているブラウザで、履歴が問題の原因になっている場合は、wordpress.orgへのパケットが発生しない
sudo tcpdump -v |grep "wordpress.org"
sudo tcpdump -v |grep "198.143.164."
良くある事例だが、仕様上問題がある
今回は「サイトヘルス」診断で「問題がない」のに「問題あり」と判定されてしまったのだが、
解決方法のアドバイスに危険な内容が多く「ファイヤウォールを開ける」とか「プラグインを全て削除する」とか、原因の1つとしてはあり得るが、問題のないシステムを危険に晒すことになってしまう。
そして「問題がある」状態で「問題なし」と判断される可能性もある。
Webアプリケーションの管理画面が提供する診断機能として、設計を見直して改善した方がいいと思う。