WordPress の管理者画面でサイトヘルスが「Should be improved（改善が必要）」と出ているのが気になって仕方がありません。
ひとまず critical issue だけでも解決したい。
みなさんも同様に気になっているようで、「WordPress サイトヘルス」で検索するといろいろ情報が出てきます。
大抵のケースはそれら先人の知恵で解決できると思うのですが、苦戦したのが以下の２つです。
- REST API でエラーが発生しました
- サイトでループバックリクエストが完了できませんでした
結論から言うと、ファイアウォールの設定で解決しました。以下、調査の過程です。
REST API でエラーが発生しました
REST API は WordPress や他のアプリケーションがサーバーと通信する手段の1つです。たとえばブロックエディター画面は、投稿や固定ページの表示や保存に REST API を使用しています。
REST API リクエストはエラーのために失敗しました。
エラー: cURL error 7: (http_request_failed)
１つ目のエラーはこれです。
REST API にアクセスできないとのことです。
この画面が表示できていたり、プラグインが動いている時点であまり問題のないような気がするけど・・・？
サイトでループバックリクエストが完了できませんでした
ループバックリクエストは予約イベントの実行に使用されます。またテーマやプラグインの組み込みエディターでは、コードの安定性の確認に使用されます。
サイトへのループバックリクエストは失敗しました。現在、依存する機能は想定どおりに動作していません。
エラー: cURL error 7: (http_request_failed)
２つ目はこちら。
ループバックリクエストができない？curl のエラーコードが同じなので、どうも REST API のエラーと原因は同じようです。
ググってみるが・・・
いくつかの情報は見つけられるものの、そのものズバリな情報がない・・・
SiteGuard プラグインは入れてなかったし、入れてもそもそも標準で「除外パス」の欄に site-health.php は追加済みだし。
curl でアクセスできない？
curl でアクセスできないとかそんなバカな・・・と思いましたが一応念のため確認してみたところ。
> curl --trace-ascii - http://hplugr2.zapto.org
== Info: Trying XXX.XXX.XXX.XXX:80...
== Info: Immediate connect fail for XXX.XXX.XXX.XXX: パーミッションが拒絶されました
== Info: Closing connection 0
curl: (7) Couldn't connect to serverあれ？確かに Permission denied エラーが発生します。
というかサイトヘルス画面にアクセスできている時点で Permission denied とかありえないはず。
ということは、ループバックアクセスだけダメ？というわけで別の Ubuntu から同じように試してみると、
$ curl --trace-ascii - http://hplugr2.zapto.org
== Info: Rebuilt URL to: http://hplugr2.zapto.org/
== Info: Trying XXX.XXX.XXX.XXX...
== Info: TCP_NODELAY set
== Info: Connected to hplugr2.zapto.org (xxx.xxx.xxx.xxx) port 80 (#0)
=> Send header, 81 bytes (0x51)
0000: GET / HTTP/1.1
0010: Host: hplugr2.zapto.org
0029: User-Agent: curl/7.58.0
0042: Accept: */*
004f:
（以下略）今度はアクセスできました。
ファイアウォールがブロックしていた
ここまでくるともう WordPress は関係なくて、ネットワーク系の問題、特にファイアウォールまわりが怪しそうです。
ということでいったん PF（FreeBSD で使用しているファイアウォール）を切ってみると・・・
消えた！（recommended improvement へ移っただけ？）
後で調査してみたところ、ループバックデバイスの in/out 両方向でパケットをブロックしていました。以下の設定を追加することで、critical issue はなくすことができました。
pass out quick on $lo_if from $int_net to $int_net
pass in quick on $lo_if from $int_net to $int_net（$lo_if はループバックデバイス、$int_net は内部ネットワーク）
REST API の項目は、自分自身へのアクセスだからパケットフィルタでハネられてエラーになっていた、ということですね。
そのあと時間を置いてみてみると、すべてパスするようになっていました。リロードするとたまに結果が変わるので、あまり細かいことは気にしない方がいいかもしれません。
コメント