問題の発生「ツール > サイトヘルス」ページを開くと、真っ赤な警告が表示されることがあります。WordPressは、REST APIまたはループバックリクエストが失敗したと報告します。ログを詳しく調べると、次の特定のエラーが見つかります。
cURL error 7: Failed to connect to localhost port 80: Connection refused
これは単なる見た目の問題ではありません。cURLが失敗すると、サイトは不可欠なバックグラウンドタスクを実行できなくなります。プラグインの更新を確認できず、予約投稿（wp-cron）も実行されず、Gutenbergエディターが正常に動作しなくなる可能性さえあります。本質的には、サーバーが自分自身と通信しようとしていますが、その接続が拒否されている状態です。
なぜこの問題が発生するのか？「ループバックリクエスト」は、WordPressが自身のサーバーに対してHTTPリクエストを送信したときに発生します。「Connection refused」というメッセージが表示される場合、通常は次の4つの技術的なボトルネックのいずれかが原因です。
- DNSの不一致: サーバーが
localhostやドメイン名を 127.0.0.1 に解決しようとしますが、Webサービスがその特定のIPでリッスンしていません。- 厳格なファイアウォール: UFWやIPTablesなどのセキュリティツールが、ローカルループバックインターフェース（lo）上のトラフィックをブロックしています。- Webサーバーのバインド設定: NginxまたはApacheがパブリックIPのみでリッスンするように設定されており、127.0.0.1へのリクエストを無視しています。- Dockerの分離: コンテナ内では、localhostはホストマシンではなくコンテナ自身を指します。## ステップ1：CLIで接続を確認するまず、サーバー側からエラーを確認することから始めます。マシンにSSHで接続し、次のコマンドを実行してください。
curl -I http://localhost:80
出力に Connection refused と表示される場合、問題はOSまたはネットワーク設定にあります。一方、ここで 200 OK のレスポンスが返ってくるのにWordPressでエラーが発生する場合は、PHP-FPMや特定のWordPress設定に問題がある可能性があります。
ステップ2：/etc/hostsファイルを更新するサーバーはローカルリクエストをどこに送信すべきかを正確に知る必要があります。ドメイン名の解決に失敗することがよくあります。sudo権限でhostsファイルを開きます。
sudo nano /etc/hosts
ドメインがローカルIPにマッピングされていることを確認してください。サイトが example.com の場合、ファイルは次のようになります。
127.0.0.1 localhost example.com
::1 localhost ip6-localhost ip6-loopback
ファイルを保存して終了します。これにより、サーバーはリクエストをパブリックインターネット経由でルーティングしようとするのではなく、内部を参照するようになります。
ステップ3：Webサーバーの「Listen」ディレクティブを確認するWebサーバーがパブリックIP（例：123.123.123.123）のみでリッスンしている場合、127.0.0.1に送信されたリクエストは無視されます。
Nginxの場合：/etc/nginx/sites-available/ にあるサイト設定を確認してください。listen ディレクティブを探します。
server {
listen 80; # すべてのインターフェースでリッスンします
# または明示的に追加：
listen 127.0.0.1:80;
server_name localhost example.com;
}
Apacheの場合：ports.conf ファイルまたはVirtualHostブロックを確認してください。インターフェースが制限されていないか確認します。
Listen 80
変更後、サービスを再起動します：sudo systemctl restart nginx。
ステップ4：ファイアウォールルールを調整するセキュリティを強化したサーバーでは、ファイアウォールがデフォルトでローカルループバックインターフェースをブロックしていることがよくあります。Ubuntuで UFW を使用している場合は、次のコマンドで「lo」インターフェースのトラフィックを許可します。
sudo ufw allow in on lo
sudo ufw allow out on lo
CentOSやRHELで Firewalld を使用している場合は、インターフェースをtrustedゾーンに追加します：
sudo firewall-cmd --permanent --zone=trusted --add-interface=lo
sudo firewall-cmd --reload
ステップ5：Docker向けの解決策Dockerでは、localhost はコンテナごとに分離されています。WordPressが1つのコンテナにあり、Nginxが別のコンテナにある場合、localhost経由でお互いを認識できません。最も簡単な解決策は、docker-compose.yml のサービス名を使用することです。
URLを変更できない場合は、WordPressサービスに extra_hosts エントリを追加します。これにより、ドメインがDockerブリッジIP（通常は 172.17.0.1）にマッピングされます。
services:
wordpress:
extra_hosts:
- "example.com:172.17.0.1"
ステップ6：プロキシ設定をバイパスするサーバーが企業プロキシの背後にある場合、cURLがそのプロキシ経由でローカルリクエストをルーティングしようとすることがあります。これは通常、タイムアウトや拒否で終わります。wp-config.php ファイルに次の行を追加して、ローカルトラフィックのプロキシを無視するようにWordPressに指示します。
define('WP_PROXY_BYPASS_HOSTS', 'localhost, 127.0.0.1, example.com');
確認「ツール > サイトヘルス」に戻ってください。「REST API」と「ループバックリクエスト」のテストに、緑色の「合格」ステータスが表示されるはずです。100%確実にするために、WP-CLI経由でクイックテストを実行できます。
wp eval "$res = wp_remote_get('http://localhost/wp-json/'); echo is_wp_error($res) ? $res->get_error_message() : 'Connection Successful';"