実際には何が起きているのか？WordPressのサイトヘルス画面を開き、すべてが正常であることを期待したのに、代わりに致命的なエラーが表示されることがあります：サイトへのループバックリクエストに失敗しました。
これは単なる煩わしい通知ではありません。ループバックリクエストとは、WordPressが回線の状態を確認するために、自分自身の電話番号に電話をかけるようなものだと考えてください。これに失敗すると、即座に影響が出ます。予約投稿がいつまでも「予約済み」状態のままになったり、ブロックエディター（Gutenberg）で保存ボタンを押した時にフリーズしたりします。さらに、現代のWordPressの基盤であるREST APIも、実質的に麻痺してしまいます。
ステップ 1：cURLで診断するWordPressの設定を調べる前に、サーバーが物理的に自分自身にアクセスできるかを確認してください。SSHでサーバーにアクセスし、自身のAPIエンドポイントに対してcURLコマンドを実行します。ヘッダーのみを表示するには、-Iフラグを使用します。
# yourdomain.com を実際のサイトURLに置き換えてください
curl -I https://yourdomain.com/wp-json/
出力を詳しく確認してください。403 Forbiddenや500 Internal Server Errorが表示される場合、サーバーが自身をブロックしています。curl: (60) SSL certificate problemと表示される場合は、サーバーが自身のセキュリティ証明書を信頼していません。これは、新しいVPSに移行した際によく発生する問題です。
ステップ 2：/etc/hosts ファイルを確認するDigitalOceanやAWS Lightsailなどの多くのVPSプロバイダーは、「ヘアピンNAT」を自動的に設定しません。つまり、サーバーがパブリックDNS経由で自身のドメインを検索し、自身のパブリックIPを取得して、結果として自分自身への接続に失敗します。ドメインをローカルにマッピングすることで、これを回避できます。
sudo nano /etc/hosts
サーバーがドメインに対してローカルインターフェース（127.0.0.1）を参照するように、以下の行を追加します：
127.0.0.1 yourdomain.com www.yourdomain.com
保存して終了します（Ctrl+O、Enter、Ctrl+X）。ステップ1のcURLコマンドを再度実行してください。200 OKが返ってくれば、ルーティングの競合は解決です。
ステップ 3：SSL証明書の信頼を解決するWordPressはループバック呼び出しにPHPのcURLライブラリを使用します。ブラウザで緑色の鍵マークが表示されていても、CA（認証局）バンドルが古い場合や自己署名証明書を使用している場合、サーバー側のPHPでは失敗することがあります。
Let's Encryptを使用している場合は、証明書が有効であるだけでなく、チェーンに正しくインストールされていることを確認してください。次のコマンド1つで、サーバーの信頼済みストアを更新できます：
# UbuntuまたはDebianシステムの場合
sudo apt-get update
sudo apt-get install --only-upgrade ca-certificates
「SSL検証を無効にする」プラグインを使いたい誘惑に駆られるかもしれませんが、避けてください。それは、エンジン警告灯の上にテープを貼って隠すようなものです。問題は見えなくなりますが、サーバーは脆弱なまま放置されます。
ステップ 4：ベーシック認証をバイパスするパスワード保護（ベーシック認証）されたステージングサイトでテストしていませんか？ WordPressはあなたの認証情報を知るほど賢くありません。REST APIにアクセスしようとすると、ログインプロンプトに阻まれ、401 Unauthorizedエラーが発生します。
サーバー自身からのリクエストにはパスワードを要求しないよう、Webサーバーに設定する必要があります。 Nginxの場合：
location / {
satisfy any;
allow 127.0.0.1;
allow 192.168.1.100; # 実際のサーバーIPに置き換えてください
auth_basic "Restricted";
auth_basic_user_file /etc/nginx/.htpasswd;
}
ステップ 5：ファイアウォールとセキュリティプラグインを調査するセキュリティツールは、頻繁なループバックリクエストをDDoS攻撃やボットによるスクレイピングと誤解することがよくあります。WordPressは数秒の間に数十のリクエストをトリガーすることがあるため、自身のソフトウェアによってレート制限を受けている可能性があります。
- **Wordfence:** 一時的にファイアウォールを「Learning Mode」に切り替えてください。エラーが消えるなら、Wordfenceが127.0.0.1をブロックしていたことになります。
- **Cloudflare:** Orange Cloud（プロキシ）を使用している場合は、Cloudflareダッシュボードの「Security > WAF > IP Access Rules」で、サーバーのIPがホワイトリストに登録されていることを確認してください。
- **Fail2Ban:** サーバー自身を誤って隔離（jail）していないか確認してください：`sudo fail2ban-client status nginx-http-auth`。
ステップ 6：WP-CLIによる競合テストサーバーログに異常がなく、それでもエラーが続く場合は、プラグインがhttp_request_argsフィルターを妨害している可能性があります。UIを操作する代わりに、WP-CLIを使って数秒で診断しましょう。
# すべてを一括で無効化する
wp plugin deactivate --all
# サイトヘルスを確認します。正常になれば、プラグインを1つずつ有効化していきます。
検証ツール → サイトヘルスに戻ります。致命的なエラーは消えているはずです。バックグラウンドタスクが正常に戻ったことを100%確実にするために、cronのスケジュールを確認してください：
wp cron event list --format=table
「Next Run」列が過去ではなく未来の時間を示していれば、ループバックリクエストは正式に正常な状態です。
クイックヒント
- 常に`/var/log/nginx/error.log`（またはApacheの相当するもの）を確認してください。ログは接続が切断された理由について嘘をつきません。
- Dockerを使用している場合は、WordPressコンテナが内部ブリッジネットワークを介してNginxコンテナと通信できることを確認してください。
- WP-Cronのような根本的な機能が依然として失敗しているなら、グリーンのチェックマークだけで満足しないでください。ダッシュボードの状態よりも、実際の機能性が重要です。