Webサイトの管理をしていると「ERR_TOO_MANY_REDIRECTS」というエラーに遭遇することがあります。
このリダイレクトの無限ループは、ユーザーがサイトにアクセスできなくなる深刻な問題です。
本記事では、302リダイレクトが無限ループする原因・解決方法・リダイレクトチェーンの問題・デバッグ方法・ブラウザキャッシュの対処法を詳しく解説していきます。
Webエンジニア・サーバー管理者・Webサイト運営者の方に参考にしていただける内容です。
無限ループの原因は複数あり、発生状況によって対処法が異なります。
本記事のトラブルシューティング手順を参考に、問題を素早く解決していただければ幸いです。
リダイレクト無限ループとは何か？発生のメカニズムと主な原因
それではまず、リダイレクト無限ループの発生メカニズムと主な原因について解説していきます。
リダイレクト無限ループとは、URL AがURL Bにリダイレクトし、URL BがさらにURL Aにリダイレクトするという循環が生じて、ブラウザやサーバーが永遠にリダイレクトを繰り返す状態です。
ブラウザは通常20回程度のリダイレクトを試みた後、「ERR_TOO_MANY_REDIRECTS（リダイレクトが多すぎます）」というエラーを表示して処理を停止します。
【無限ループのパターン例】
単純な循環ループ：
example.com/page-a → example.com/page-b → example.com/page-a → …（無限ループ）
自己参照ループ：
example.com → example.com（自分自身にリダイレクトしてしまう）
HTTP/HTTPSのループ：
http://example.com → https://example.com → http://example.com → …
（SSL設定とリダイレクト設定が競合している場合）
主な発生原因を整理すると次のようになります。
| 原因カテゴリ | 具体的な原因 |
|---|---|
| 設定ミス | .htaccessやNginxの設定でリダイレクト先が自分自身になっている |
| SSL/HTTPS設定の競合 | サーバーがHTTPSにリダイレクトするが、ロードバランサーがHTTPに戻してしまう |
| CMS・プラグインの設定ミス | WordPressのURLが実際のアクセスURLと一致していない |
| Cookieの問題 | ログイン判定やABテストのCookieが正しく機能せずリダイレクトが繰り返される |
| ブラウザキャッシュ | 古いリダイレクト情報がキャッシュに残っている |
無限ループが発生したときは「設定ミス」「SSL競合」「CMS設定」「キャッシュ」の4つの観点からチェックすることが効率的なトラブルシューティングの出発点です。
HTTPS設定とロードバランサーの競合による無限ループの解決方法
続いては、HTTPS設定とロードバランサーの競合による無限ループの解決方法について確認していきます。
クラウド環境やロードバランサーを使った構成でよく発生するパターンが、SSL終端の設定ミスによる無限ループです。
【HTTPS無限ループの発生パターンと解決策】
発生パターン：
①クライアントがhttp://にアクセス
②ロードバランサーがSSL終端してバックエンドにhttpsでなくhttpで転送
③バックエンドのApache/Nginxが「HTTPだからhttpsにリダイレクトしよう」と判断
④ループ発生
解決策①：X-Forwarded-Protoヘッダーを使う（.htaccessの例）
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [R=301,L]
解決策②：ロードバランサー側でHTTPSリダイレクトを処理し、バックエンドではリダイレクトしない
X-Forwarded-Protoヘッダーを確認することで、ロードバランサーを経由した通信でも元のプロトコル（HTTPかHTTPSか）を正しく判断できます。
この設定によりバックエンドサーバーが不必要なHTTPSリダイレクトを行わなくなり、ループが解消されます。
AWS ALB・Nginx Proxy・Cloudflareなどを使った環境では、このパターンの無限ループが特によく発生します。
WordPressやCMSの設定ミスによる無限ループの解決方法
続いては、WordPressやCMSの設定ミスによる無限ループの解決方法について確認していきます。
WordPressで無限ループが発生する代表的なケースとその対処法を確認します。
【WordPress無限ループの主な原因と解決法】
原因①：WordPressのサイトURLが実際のURLと異なる
対処：管理画面→設定→一般で「WordPressアドレス（URL）」と「サイトアドレス（URL）」を正しいURLに修正する
DBに直接アクセスできる場合はwp_optionsテーブルのsiteurl・homeを修正する
原因②：HTTPSへの移行後にURLがhttpのままになっている
対処：wp-config.phpに以下を追加する
define(‘FORCE_SSL_ADMIN’, true);
if (strpos($_SERVER[‘HTTP_X_FORWARDED_PROTO’], ‘https’) !== false)
$_SERVER[‘HTTPS’]=’on’;
原因③：キャッシュプラグインが古いリダイレクトをキャッシュしている
対処：キャッシュプラグインのキャッシュを全クリアする
原因④：.htaccessが壊れているまたは重複している
対処：.htaccessをWordPressのデフォルトの内容にリセットする
WordPress管理画面にアクセスできない場合は、wp-config.phpやデータベースに直接アクセスして設定を修正する必要があります。
WordPressの無限ループでよくあるのが、HTTPSへの移行時にサイトURLの設定更新を忘れてしまうケースです。
移行後は必ずサイトURL設定も合わせて更新することが重要です。
デバッグ方法とブラウザキャッシュのクリア：問題を特定して解決する手順
続いては、無限ループのデバッグ方法とブラウザキャッシュへの対処について確認していきます。
無限ループが発生した際の効率的なデバッグ手順を整理します。
【無限ループのデバッグ手順】
ステップ①：ブラウザキャッシュをクリアして再確認する
Chromeの場合：設定→プライバシーとセキュリティ→閲覧履歴データの削除→Cookieとキャッシュを削除
または：Ctrl+Shift+Delete（Windows）/ Command+Shift+Delete（Mac）
ステップ②：ブラウザの開発者ツールでリダイレクトチェーンを確認する
Chrome DevTools→Networkタブを開いてページにアクセス
→各リクエストのStatusコードとLocationヘッダーを確認してループのパターンを特定する
ステップ③：curlコマンドでリダイレクトを追跡する
curl -I -L https://example.com
→ヘッダーのみ表示しながらリダイレクトを追跡してループを発見する
ステップ④：オンラインのリダイレクトチェッカーを使う
redirect-checker.orgなどのツールでリダイレクトチェーンを可視化する
Chrome DevToolsのNetworkタブでリダイレクトの流れを一つずつ確認することが、無限ループの原因を特定する最も確実なデバッグ方法です。
各リクエストのLocationヘッダーを見ていけば、どのURLがどこにリダイレクトしているかが一目でわかります。
ブラウザキャッシュが原因の場合は、キャッシュをクリアするだけで問題が解決することも多いため、まず最初にキャッシュクリアを試みることが効率的な対処法です。
設定を修正した後も必ずキャッシュをクリアして動作確認を行うことが重要です。
まとめ
リダイレクト無限ループは設定ミス・SSL/HTTPS設定の競合・CMS設定の不整合・ブラウザキャッシュの4つが主な原因です。
HTTPS無限ループはX-Forwarded-Protoヘッダーを使った条件分岐リダイレクトで解決できます。
WordPressでは管理画面のサイトURL設定・wp-config.phpの設定・キャッシュプラグインのクリアが主要な対処法です。
デバッグはブラウザキャッシュのクリア→Chrome DevToolsでのリダイレクトチェーン確認→curlコマンドの順で進めることが効率的です。
無限ループが発生した際は本記事のデバッグ手順を参考に、原因を特定して素早く解決してみてください。
