ERR_TOO_MANY_REDIRECTS

このエラーの意味と見分け方

• ブラウザーに「このページは動作していません — [domain] でリダイレクトが多すぎます」またはエラーコード ERR_TOO_MANY_REDIRECTS が表示されます。
• ブラウザーが読み込みを停止するまで、アドレスバーが HTTP と HTTPS の間、または www と非 www のホスト名の間で繰り返し切り替わります。
• サイト全体で発生する場合もあれば、1つの URL、管理画面、ログインセッション、特定のデバイスだけに限られる場合もあります。
• HTTPS の有効化、CDN やリバースプロキシの追加、正規ホスト名の変更、リダイレクトまたは SSL プラグインのインストール後に発生することがよくあります。
• 認証やセッションの処理が関係している場合、Cookie を削除すると一時的に挙動が変わることがありますが、サーバー側のリダイレクト競合は解消されません。

可能性の高い順の主な原因

1. HTTP/HTTPS ルールの競合 — あるレイヤーが HTTP を HTTPS にリダイレクトする一方、別のレイヤーが誤って HTTPS を HTTP に戻している状態です。プロキシまたは CDN が TLS を終端しているものの、オリジンが元のリクエストが安全な接続だったことを認識できない場合によく発生します。
2. CDN の SSL/TLS モードの不一致 — CDN がオリジンへの接続に HTTP を使用している一方、オリジンが HTTPS を強制している場合があります。オリジンは HTTPS にリダイレクトしますが、CDN が HTTP でのオリジンリクエストを繰り返すため、ループが発生します。
3. www と非 www の正規化ルールの競合 — CDN、Web サーバー、CMS、プラグインが、どのホスト名を正規とするかで一致していない可能性があります。
4. プロキシまたは転送プロトコルの処理が不適切 — アプリケーションが設定済みのプロキシを信頼していない、または X-Forwarded-Proto などのヘッダーを正しく処理していないため、安全なリクエストを繰り返し HTTP として扱っている可能性があります。
5. 古いリダイレクトのキャッシュ — ブラウザー、CDN、リバースプロキシ、ページキャッシュが、設定を修正する前のリダイレクトをまだ配信している可能性があります。
6. アプリケーションまたはプラグインのルール重複 — SSL 強制、ログイン、メンテナンス、リダイレクト用のプラグインが、サーバーレベルのルールと競合している可能性があります。
7. Cookie またはセッション設定の問題 — Secure、ドメイン、パスの設定が正しくないと、一部のユーザー、特にログイン中の訪問者にだけ認証リダイレクトが発生することがあります。

修正方法

1. まずリダイレクトチェーンを取得する

ターミナルから読み取り専用のリクエストを実行します。プレースホルダーは対象のホスト名に置き換えてください。

curl -IL https://[your-hostname]

このコマンドはヘッダーを取得し、リダイレクトを追跡します。すべての Location: 値と HTTP ステータスコードを記録してください。問題が発生する正確な URL、HTTP 版、関連する場合は www と非 www の両方をテストします。ブラウザーの Network パネルでも同様の情報を確認できます。

次のようなパターンを探してください。

• HTTPS → HTTP → HTTPS
• 非 www → www → 非 www
• 1つの URL が自分自身へ繰り返しリダイレクトされる
• ログイン URL または正規 URL へリダイレクトした直後に、元へ戻る

最初からキャッシュを削除したり、複数の設定を同時に変更したりしないでください。チェーンを確認すると、どのレイヤーを調べるべきかを特定できます。

2. HTTP/HTTPS または CDN のループを修正する

CDN またはリバースプロキシが公開 HTTPS 接続を処理している場合は、その SSL/TLS モードと、オリジンの証明書および HTTPS 設定を確認します。CDN からオリジンへの接続モードは、オリジンがサポートする構成と一致している必要があります。Cloudflare を使用している場合、オリジンが HTTPS を正しくサポートし、オリジン自体が HTTPS を強制するなら、通常は Flexible ではなく Full または Full (strict) が必要です。

モードを変更する前に、CDN を変更する権限があること、また厳格な証明書検証を使用する場合は、オリジンにホスト名用の有効な証明書があることを確認してください。CDN の TLS 設定を変更すると本番トラフィックに影響する可能性があるため、承認済みの変更手順またはメンテナンスウィンドウの要件に従ってください。

3. プロキシ経由の HTTPS 検出を正しく設定する

プロキシの背後で動作するアプリケーションが HTTPS を強制している場合は、アプリケーションまたはフレームワークが意図したプロキシを信頼し、転送されたプロトコルを認識できるように設定します。プラットフォームによって、設定名は trust proxy、trusted proxies、force-SSL などです。

転送プロトコルのヘッダーは、既知の管理下にあるプロキシ経路からのものだけを信頼してください。直接公開されたオリジンで、クライアントが送信したヘッダーを無条件に信頼しないでください。正しい設定についてプラットフォームのドキュメントを確認し、リダイレクトチェーンを再テストします。

4. www と非 www の不一致を解消する

正規ホスト名を1つ選び、その内容を文書化します。CDN、Web サーバー設定、該当する場合は .htaccess ルール、CMS の URL 設定、リダイレクトプラグインを確認してください。

正規ホスト名へのリダイレクトは1つのルールを正とします。たとえば非 www から www、または www から非 www とし、重複または相反するルールを削除します。変更後は HTTP と HTTPS のすべてのバリエーションを確認してください。HTTPS が正しく設定されていても、正規 URL の設定が Web サーバーの転送先と異なると、ループが再発する可能性があります。

5. アプリケーション、ログイン、Cookie の挙動を確認する

匿名ユーザーはページを読み込めるのにログインユーザーが読み込めない場合は、権限のあるテストアカウントまたはプライベートウィンドウを使い、セッション Cookie の有無でリダイレクトチェーンを比較します。force-SSL、ログイン、会員、リダイレクト用プラグインと、アプリケーションに設定されたサイト URL を確認してください。

セッション Cookie が、選択した HTTPS ホスト名に対して正しい Secure 属性、ドメイン、パスを使用していることを確認します。変更管理プロセスの下で、疑わしいプラグインを一度に1つずつ無効化または変更してください。ロールバック計画なしに、本番サイトの認証またはセキュリティ制御を削除しないでください。

6. 古いリダイレクトを削除して再テストする

設定を修正した後、権限がある場合は、関連する CDN、リバースプロキシ、ページキャッシュのエントリを削除します。ブラウザーのリダイレクトも残る可能性があるため、curl、プライベートウィンドウ、必要に応じて別のネットワークまたはデバイスで再テストしてください。

成功したテストでは、Location の繰り返しシーケンスなしに目的のページへ到達します。ホームページだけでなく、正規ホスト名、HTTP から HTTPS への挙動、ログインフロー、代表的な内部 URL を確認してください。

予防と修正確認

• CDN、リバースプロキシ、CMS プラグイン、サーバールールを追加する前に、正規ホスト名と意図する HTTP から HTTPS への挙動を文書化してください。
• 可能な限り、各リダイレクトの判断を1つのレイヤーで正として管理し、他のレイヤーが相反するルールを発行しないようにしてください。
• サイトをプロキシの背後に置く場合は、信頼するプロキシと転送プロトコルの処理を意図的に設定し、クライアントが送信した転送ヘッダーを無差別に受け入れないでください。
• HTTPS、ホスト名、CDN、CMS、プラグインを変更した後は、ユーザーがアクセスする正確な URL を使ってリダイレクトチェーン全体をテストしてください。
• 対応している場合は、デプロイ時の確認に匿名、ログイン中、www、非 www、HTTP、HTTPS のテストを含めてください。
• リダイレクトを変更した後は、関連するキャッシュを削除またはバージョン更新し、プライベートウィンドウまたはクリーンなクライアントから確認してください。

よくある質問