リダイレクトが多すぎる：ループを見つけて解消する
リダイレクトが多すぎる（ERR_TOO_MANY_REDIRECTS）
リダイレクトが多すぎる：ERR_TOO_MANY_REDIRECTSのループを直す | We.Inc
リダイレクトルールを貼り付けると、ループが現れるまで1ホップずつ追跡します。プロキシ背後のHTTPSループ、wwwのループ、Cookieのループと修正方法を解説。
ERR_TOO_MANY_REDIRECTSは、ページがブラウザーを別のアドレスへ送り続け、最終的に元のアドレスに戻ってくるため、連鎖が終わらずブラウザーが諦めたときに表示されます。よくある原因は、2つのレイヤーがHTTPSやwwwを互いに逆方向へ強制していることです。各リダイレクトをちょうど1つのレイヤーだけが担当するようにすれば解消できます。
「リダイレクトが多すぎる」エラーの主なループ
- プロキシ背後のHTTPS
- プロキシがサーバーと通常のHTTPで通信し、サーバーが再びHTTPSへリダイレクトする
- X-Forwarded-Protoに基づいてリダイレクトするか、プロキシでのみリダイレクトする
- wwwありとなしのドメイン
- あるレイヤーがwwwを付け、別のレイヤーが外す
- ホストを1つに決め、1か所でそこへリダイレクトする
- Cookieやログインのループ
- ログインページがアカウントページへ送り、Cookieが保存されないためアカウントページが送り返す
- CookieのDomain、Path、Secureフラグを確認する
- 末尾のスラッシュ
- あるルールがスラッシュを付け、別のルールが外す
- すべてのURLで形式を1つに決める
サイトが行うリダイレクトを1行に1つずつfrom -> toの形式で書き、開始アドレスを入力すると、シミュレーターがブラウザーと同じように連鎖をたどります。アドレスが繰り返されたとき、一致するルールがないとき、またはFetch Standardの上限である20ホップに達したときに停止します。
- 把握しているリダイレクトをすべて書き出します。サーバーの設定、ホスティングのダッシュボード、CDNのルール、アプリのコードです。
- 完全なアドレスを->でつなぎ、1行に1つずつ書きます。
- ブラウザーで失敗するアドレスを入力し、ホップの一覧を確認します。
- 連鎖をすでに訪れたアドレスへ戻しているルールを削除または変更します。
- 再テストの前に、そのサイトのCookieを削除しましょう。古いCookieが残っていると、設定を直した後もログインのループが続くことがあります。
- ブラウザーは301リダイレクトをキャッシュします。修正の確認はプライベートウィンドウで行うか、curl -Iでキャッシュなしに各レスポンスを確認しましょう。
- 最終的なアドレスへ直接リダイレクトしましょう。http://example.comは、2回経由せず1ホップでhttps://www.example.comへ転送すべきです。
- CDNやホスティングにHTTPS強制のスイッチがある場合は、それかサーバーのルールのどちらかを使い、相互の影響を確認せずに両方を使わないでください。
よくある質問
「リダイレクトの回数が多すぎます」とはどういう意味ですか？
このメッセージとエラーコードERR_TOO_MANY_REDIRECTSは同じことを表しています。サイトがリダイレクトを返し続け、ブラウザーがたどるのをやめたということです。あなたのコンピューターが壊れているわけではありませんが、古いCookieがループの一部になっていることはあります。
ブラウザーは何回までリダイレクトをたどりますか？
ブラウザーが実装しているFetch Standardでは、リクエストのリダイレクト回数が20に達するとネットワークエラーを返します。
プロキシやCDNの背後でHTTPSを強制するとループするのはなぜですか？
訪問者はHTTPSで接続しますが、プロキシはリクエストを通常のHTTPでサーバーに転送します。サーバーはHTTPと判断してHTTPSへリダイレクトし、これが繰り返されます。Cloudflareは、Flexible暗号化モードでのまさにこのループについて文書化しています。
Cookieを削除すれば「リダイレクトが多すぎる」は直りますか？
Cookieがループの一部になっている場合だけです。たとえば、ログインセッションが保存されない場合です。ループの原因がサーバーのルールにあるなら、Cookieを削除しても何も変わりません。
リダイレクトループはSEOに悪影響がありますか？
ループにはまったページは読み込まれないため、クローラーも内容を読めません。ループはすぐに直し、リダイレクトの連鎖は短く保ちましょう。
ループがレイヤー間で起きる理由
- 最近のサイトには、リダイレクトできる場所が3つか4つあることがよくあります。CDN、ホスティングプラットフォーム、Webサーバー、アプリです。それぞれ別の画面で設定するため、そのうち2つがスキーム、ホスト、末尾のスラッシュについて知らないうちに食い違うことがあります。
- 上のシミュレーターはまさにそれを再現します。すべてのレイヤーのルールを同じ一覧に入れると、食い違いが目に見える循環として現れます。
プロキシとスキームの問題
- TLSがプロキシやロードバランサーで終端される場合、サーバーには通常のHTTPしか見えません。すると「HTTPのものはすべてHTTPSへリダイレクト」というルールが、訪問者にとってはHTTPSだったものも含めてすべてのリクエストで発動します。プロキシは元のスキームをX-Forwarded-Protoヘッダーで送るため、サーバーは代わりにそちらを確認すべきです。
ちょうど1回だけリダイレクトする設定
自身でTLSを終端するnginx
1つのserverブロックがすべてのHTTPリクエストを受け、最終的なホストへ直接転送します。
TLSを終端するプロキシの背後にあるnginx
プロキシがX-Forwarded-Protoで送る訪問者の元のスキームがhttpだった場合にのみリダイレクトします。
コマンドラインですべてのホップを確認する
-Iはヘッダーだけを要求し、-Lはリダイレクトをたどります。出力の各ブロックが1ホップです。
リダイレクトループのシミュレーター
リダイレクトルール、1行に1つ（from -> to）
開始アドレス
ブラウザーがたどるホップ
ループ：連鎖が{v}に戻るため、ブラウザーは「リダイレクトが多すぎる」で停止します。
ループなし：{n}回のリダイレクトの後、連鎖は{v}で終わります。
連鎖が終わらないまま{n}ホップを超えたため、ブラウザーは諦めます。
開始アドレスに一致するルールがないため、リダイレクトなしで読み込まれます。
無料で始める · クレジットカード不要
関連: ガイド｜Webマーケティングと集客を学ぶ
製品
ご利用いただける方
機能
リソース
会社情報
サイトマップを見る