リダイレクトエラー

このエラーカテゴリーについて

# リダイレクトエラー

リダイレクトエラーは、リクエストがある URL から別の URL へ送信されたものの最終ページに到達しない場合や、必要以上に多くのリダイレクトを経由する場合に発生します。典型的な症状には、ERR_TOO_MANY_REDIRECTS、アドレスバーの URL が繰り返し変化する、HTTP と HTTPS の URL が交互に表示される、複数回のリダイレクト後にページの読み込みに失敗する、といったものがあります。

リダイレクトは通常、HTTPS の強制、優先するホスト名の選択、古い URL の移転、新しいパスへのリクエストのルーティングなど、正当な目的で使用されます。エラーは、複数のレイヤー間でリダイレクトの判断が競合している場合や、キャッシュされた状態によってブラウザが古い結果を繰り返している場合に発生することが一般的です。

リダイレクトエラーの主な種類

リダイレクトループ

リダイレクトループは、一連のリダイレクトが最終的に、すでにリクエストされた URL に戻る場合に発生します。たとえば、あるルールが HTTP を HTTPS にリダイレクトする一方で、別のルールが HTTPS のリクエストを安全でないものとして扱い、HTTP に戻すことがあります。ブラウザはサイクルを停止するまで追従し、その後「リダイレクトが多すぎる」と報告します。

ループは、ホスト名、末尾のスラッシュの有無、パス、アプリケーションの URL とプロキシの URL の間でも発生します。WordPress では、HTTPS への移行後に、WordPress Address、Site Address、force-SSL 設定、プロキシの処理、サーバーのリダイレクトが同じ公開 URL を示していないと、ループが始まることがあります。このケースについては、[WordPressをHTTPSに移行した後のリダイレクトが多すぎる問題](/wordpress-too-many-redirects-https)を参照してください。

長いリダイレクトチェーン

リダイレクトチェーンは、リクエストが最終的な宛先に到達するまでに、複数のリダイレクトが連続して発生する状態です。古い URL がまず変更後のパスにリダイレクトされ、次に優先するホスト名へ、最後に HTTPS へリダイレクトされることがあります。複数回の移行や重複するルールによって、チェーンが残る場合があります。

チェーンは最終的にレスポンスへ到達するため、ループとは異なります。ただし、ナビゲーションを遅くし、最終的な宛先を決めているルールを分かりにくくする可能性があります。診断で重要な問いは、各中間リダイレクトが今も必要かどうかです。

競合するリダイレクトルール

リダイレクトの動作は、リバースプロキシや CDN、ホスティングプラットフォーム、Web サーバー、コンテンツ管理システム、アプリケーションコード、プラグインによって制御されることがあります。これらのレイヤーは、次の点について一致しない場合があります。

• 元のリクエストが HTTP と HTTPS のどちらを使用したか
• 正規のホスト名はどれか
• パスに末尾のスラッシュを付けるべきか
• 古いパスをリライトするべきか、リダイレクトするべきか
• 最終的なアプリケーションのアドレスとして、どの URL を使用するべきか

プロキシは訪問者から HTTPS で受信したリクエストを、異なる接続スキームでオリジンへ転送することがあります。アプリケーションが転送されたスキームを正しく解釈するよう設定されていないと、訪問者がすでに HTTPS を使用しているにもかかわらず、アプリケーションが別の HTTPS リダイレクトを発行する場合があります。

キャッシュされたリダイレクトまたは Cookie に関連する動作

プライベートブラウジングでのテストは、ブラウザ固有の状態と共有設定の問題を切り分けるのに役立ちます。Cookie、キャッシュされたレスポンス、アプリケーションのセッション状態によって、古いドメイン、ログインフロー、プロトコルの判断が保持されることがあります。ただし、これはサーバー設定が正しいことを証明するものではありません。結果がクライアントに保存された状態に依存している可能性を示すだけです。

複数のブラウザと異なるデバイスで同じ URL がループする場合は、ローカルデータを繰り返し消去するのではなく、リダイレクトのレスポンスと共有設定を優先して調査してください。

リダイレクトエラーの診断方法

1. 開始 URL と正確な症状を記録します。 スキーム、ホスト名、パス、末尾のスラッシュ、ブラウザのメッセージ、アドレスが繰り返し変化するかどうかを記録します。
2. 新しいブラウザセッションでテストします。 プライベートウィンドウを使用するか、対象サイトの Cookie とキャッシュデータを消去します。可能であれば、別のブラウザやデバイスでの結果と比較します。
3. リダイレクト履歴を追跡します。 ブラウザの開発者ツールや HTTP ヘッダー検査ツールを使うと、各レスポンスとその Location の宛先を確認できます。各ステップで返されたステータスを特定し、URL の繰り返し、スキームの交互切り替え、ホスト名の変更、不要な中間アドレスがないか確認します。
4. パターンを分類します。 同じアドレスが繰り返される場合はループです。ページで終わる一連の遷移はチェーンです。HTTP と HTTPS の切り替えはプロトコル処理、ホスト名やパスの切り替えは正規化または移行ルールを示します。
5. 公開 URL の設定を確認します。 アプリケーションに設定されたサイト URL が、訪問者に使用させるスキームとホスト名に一致していることを確認します。WordPress では、一方だけを変更するのではなく、WordPress Address と Site Address を比較します。
6. 外側から内側へリダイレクトの各レイヤーを確認します。 CDN またはリバースプロキシ、ホスティング設定、Web サーバーのルール、アプリケーション設定、リダイレクトまたは SSL プラグインを確認します。予期しない Location レスポンスを生成したレイヤーを最初に調べます。
7. 最近の変更を慎重に切り分けます。 HTTPS の有効化、ドメインの変更、サイトの移行、パーマリンクの編集、プラグインのインストール後に問題が始まった場合は、それらの変更とリダイレクトの順序を比較します。権限があり、以前の設定に戻す方法を確保している場合に限り、ルールを無効化または変更します。
8. 元の URL と最終 URL を再テストします。 管理された変更を行うたびに、新しいセッションを使用します。元の URL が意図した宛先に到達し、最終 URL が不要にリダイレクトされなくなったことを確認します。

最初に確認すること

HTTPS の有効化後にエラーが始まった場合

まずプロトコル処理を確認します。HTTPS がどこで終端されているか、アプリケーションが期待どおりの安全なリクエスト情報を受け取っているか、複数のレイヤーが HTTPS を強制していないかを確認します。すでに安全なリクエストを HTTP に戻すルールや、アプリケーションに 2 回目の HTTPS リダイレクトを発行させるルールを探します。

ドメインまたは移行の変更後にエラーが始まった場合

古いホスト名と新しいホスト名、スキーム、パス、末尾のスラッシュの動作を比較します。移行時のリダイレクトとアプリケーションの URL 設定を併せて確認します。ホスト名の一部だけが更新されていたり、古いドメインを対象にしたリダイレクトが残っていたりすると、ループや長いチェーンが発生することがあります。

1 つのブラウザまたはユーザーだけが影響を受ける場合

対象サイトの Cookie とキャッシュデータを使わずにテストします。問題が解消する場合は、共有サーバールールを変更する前に、保存されたセッションやリダイレクトの状態を調査します。複数のブラウザとデバイスで再現する場合は、レスポンスヘッダーと、共通するプロキシ、サーバー、アプリケーションの設定に注目します。

リダイレクトチェーンがページに到達するものの、異常に長い場合

すべての中間 URL を一覧にし、どのルールがそれを導入したかを確認します。意図したリダイレクトを維持し、古い URL が正しい最終宛先に到達することを確認したうえで、必要に応じて古い移行ルールを整理・統合します。

参照するベンダーのドキュメント

実装固有の詳細については、リクエストに関係する Web サーバー、リバースプロキシまたは CDN、ホスティングプラットフォーム、コンテンツ管理システム、リダイレクトまたは SSL プラグインのドキュメントを参照してください。これらのドキュメントでは、HTTPS の終端、転送されたプロトコルヘッダー、正規ホストへのリダイレクト、リダイレクトの優先順位、キャッシュの無効化について検索します。正しい設定は、どのレイヤーが元のリクエストを受信し、どのレイヤーが各リダイレクトを生成するかによって異なります。