WordPressのサイトヘルスに出る「ループバックリクエストが失敗しました」は、WordPressが自分のサイトへ内部からアクセスできなかったという警告です。予約投稿や定期処理へ影響することがありますが、原因を見ずにWAFやセキュリティを全部解除するのは危険です。詳細欄のURLとHTTPコードを控え、401・403・404・タイムアウトのどれかに分けて確認します。
最初に見るのは警告文のURLとHTTPコード
管理画面の「ツール」→「サイトヘルス」→「ステータス」を開き、ループバックリクエストの項目を展開します。ここで次の3点を、そのままメモしてください。
- テストされたURL
- 401、403、404などのHTTPコード
- cURL error 28など、コード以外のエラー文
この記録がないまま設定を触ると、Basic認証が原因なのにキャッシュを消したり、URL設定が原因なのにWAFを止めたりしがちです。警告の詳細が長い場合は、画面を保存しておくだけでも構いません。Cookie、パスワード、APIキーが表示されている場合は、第三者へ送る前に伏せます。
| 表示された内容 | 最初に疑う場所 | 最初の確認 |
|---|---|---|
| 401 Unauthorized | Basic認証 | 未ログインの内部通信が認証で止まっていないか |
| 403 Forbidden | WAF・IP制限 | 同じ時刻の遮断ログが残っていないか |
| 404 Not Found | URL・パーマリンク | 警告内のURLをブラウザで開けるか |
| cURL error 28 | 応答遅延・DNS・SSL | 失敗したURLと処理時間を確認する |
ループバックリクエストは何に使われる？
ループバックは、WordPressが自分自身の公開URLへHTTPでアクセスする仕組みです。人がブラウザでページを見る通信とは入口が同じでも、アクセスしている主体が違います。管理者のブラウザには認証Cookieがありますが、サーバー内からのテストには通常そのCookieがありません。
そのため「管理者としては見えるのに、内部テストだけ401になる」ということが起きます。また、予約投稿などのWP-Cron、更新時の安全確認、REST APIを利用する機能に関連するため、公開ページが表示されるという理由だけで放置するのはおすすめできません。
401ならBasic認証を確認する
401は、アクセス先まで到達したものの認証を通過できなかった時に返るコードです。開発中のサイトへBasic認証を付けている場合は、WordPress自身のアクセスもログイン前の訪問者として扱われていないか確認します。
確認のために認証を外す場合も、公開サイト全体を長時間無防備にしないでください。作業時刻を決めて短時間だけ試すか、契約サーバーが案内する内部通信の許可方法を使います。認証を外した瞬間に警告が消えたなら、原因はかなり絞れます。消えなければ元へ戻し、次の項目へ進みます。
403ならWAFとアクセス制限のログを見る
403は「アクセス先はあるが、この通信は許可しない」と拒否された状態です。WAF、セキュリティプラグイン、IP制限、CDNのファイアウォールなどが候補になります。
サイトヘルスを再実行した時刻を控え、サーバーパネルやセキュリティ製品のログで同時刻の遮断を探します。該当URLとルールが一致した時だけ、対象を限定して調整します。「どれかが原因だろう」とWAFとプラグインを同時に止めると、どちらで直ったのか分からず、元へ戻す判断も難しくなります。
404ならWordPressのURL設定を照合する
404の場合は、警告に表示されたURLを新しいタブで開きます。存在しないサブディレクトリ、古いドメイン、wwwの有無などが混ざっていないか確認してください。
「設定」→「一般」のWordPressアドレスとサイトアドレスを、実際のHTTPS URLと照合します。
wp-config.php
でURLを固定しているサイトでは、その定数が管理画面の値より優先されます。値を変更する前に、どちらを正式な設定として使っているサイトなのかを確認します。管理画面へ入れない状態で推測変更するのは避け、バックアップと復旧手段を先に用意してください。
cURL error 28なら「どこで待たされたか」を調べる
cURL error 28は、決められた時間内に応答が終わらなかった時のエラーです。単に「サーバーが遅い」とは限りません。DNS解決、SSL接続、リダイレクト、自サイトのPHP処理、外部サービス待ちのどこでも時間切れは起こります。
まず失敗URLを確認し、同じ時刻のPHPエラーログとアクセスログを見ます。URLが何度も転送されているならURL・SSL設定を、ページ生成そのものに時間がかかるなら直前に更新したプラグインや重い処理を調べます。cURL error 28だけを扱った 失敗URL別の確認手順 も用意しています。
私の画面は403でした。サイトヘルスを実行した時刻を見たら、WAFのログにも同じURLが残っています。
そこまで一致すれば、候補ではなく根拠を持って調整できるね。
ルールを全部無効にせず、その通信だけを検証して、終わったらもう一度ログを確認しよう。
警告が消えたかだけでなく、予約投稿も試します。元の設定と変更時刻も残しておきます。
直ったかどうかは予約投稿まで確認する
設定を一つ変更したらサイトヘルスを再実行します。ループバックとREST APIの警告が消えたら、数分後に公開する短いテスト投稿を予約し、管理画面を閉じても予定時刻に公開されるか確認します。
ここで確認したいのは「警告欄が緑色になった」ことではなく、影響を受けていた機能が動くことです。テスト後は記事を下書きへ戻し、変更した認証・WAF設定が必要以上に緩くなっていないかも見直します。
- サイトヘルスを再実行して警告が消えた
- REST APIの別警告が残っていない
- テスト予約投稿が予定時刻に公開された
- 新しい401・403・タイムアウトがログへ記録されていない
- 一時的に緩めた設定を必要最小限へ戻した
管理画面へ入れない場合は変更より復旧手段を優先する
URL設定の変更後などに管理画面へ入れなくなった場合は、何度も値を書き換えず、契約サーバーのファイル管理、バックアップ、PHPエラーログを確認します。変更前の値が分からない場合や、データベースを直接操作する必要がある場合は、作業を止めてサポートへ相談する方が安全です。
問い合わせ時は、警告が出たURL、発生時刻、HTTPコード、エラー全文、直前に変えた設定、試した内容と結果をまとめます。「ループバックが直りません」だけより、担当者がログを追いやすくなります。
ログやWAFを確認しやすい環境を選ぶ考え方
今回の問題だけを理由に、すぐサーバーを移転する必要はありません。ただし、現在の契約でアクセスログやWAFの履歴を確認できず、問い合わせ方法も分かりにくいなら、次回更新時に管理画面とサポート範囲を比較する材料になります。
広告・PRを含みます。現在の原因を確認し、移転が必要な場合だけ比較してください。
よくある質問
サイトが表示できれば放置してもよいですか？
すぐに公開停止する警告とは限りませんが、予約投稿や定期処理に影響する可能性があります。少なくとも詳細のHTTPコードと、予約投稿が動くかは確認してください。
Basic認証を使っているサイトでは必ず失敗しますか？
構成によります。認証を通れない内部通信だけが失敗する場合があります。利用中のサーバーや認証機能が案内する方法で、必要な内部通信を許可できるか確認します。
WAFを停止すれば直りますか？
403の原因がWAFなら一時停止で変化することはありますが、恒久的な全停止は避けます。遮断ログで該当ルールとURLを特定し、必要最小限の調整にします。
まとめ：エラーコードを見てから一つずつ直す
ループバックリクエスト失敗は、最初に詳細欄のURLとHTTPコードを記録します。401ならBasic認証、403ならWAFやアクセス制限、404ならURL設定、cURL error 28ならタイムアウトした経路を優先して確認します。
設定を変えるのは一度に一項目です。サイトヘルスの再確認だけで終わらせず、短い予約投稿が予定どおり動くところまで確認できれば、実際の機能も含めて復旧したと判断できます。