ERR_TOO_MANY_REDIRECTS の直し方（全ブラウザ対応）

ERR_TOO_MANY_REDIRECTSとは？

ERR_TOO_MANY_REDIRECTSは、ウェブサイトが無限リダイレクトループに陥ったときに発生するブラウザエラーです。ページを読み込む代わりに、ブラウザがURL間を行き来し続け、リダイレクト上限に達すると諦めてこのエラーを表示します。

すべてのブラウザには、無限ループによるリソース消費を防ぐためのリダイレクト上限が組み込まれています。ページがその上限を超えると、接続が切断されエラーメッセージが表示されます。

リダイレクトループで使われるHTTPステータスコードは通常、301（恒久的リダイレクト）または302（一時的リダイレクト）です。典型的なループは次のように発生します：ブラウザがURL Aをリクエスト → サーバーがURL Bへの301を返す → URL BがURL Aへの301を返す → ブラウザが上限に達するまでこのサイクルが繰り返されます。

リダイレクトループの原因

リダイレクトループは、2つ以上のリダイレクトルールが競合するときに発生します。サーバーがブラウザをあるURLに送り、そのURLがブラウザを元に戻します。最も一般的な原因は以下の通りです：

• SSL/HTTPSの設定ミス — 最も一般的な原因です。サーバーがHTTPからHTTPSへのリダイレクトを強制していますが、CDNやロードバランサーがHTTPでオリジンに接続するため、ループが発生します：CDN → HTTP → サーバーがHTTPSにリダイレクト → CDNがHTTPSを除去 → HTTP → ループ

• CloudflareのFlexible SSL — CloudflareのFlexible SSLモードは、オリジンサーバーへのリクエストをHTTPで送信します。オリジンにもHTTPからHTTPSへのリダイレクトがある場合、CloudflareとサーバーPの間で無限ループが発生します

• 競合する.htaccessルール — .htaccess内の複数のリダイレクトルールが矛盾している場合（例：一方がwwwを強制し、もう一方が同時にwwwなしを強制する）

• WordPressのURL不一致 — 設定 > 一般のWordPressアドレス（URL）とサイトアドレス（URL）が一致しない、または一方がHTTPでもう一方がHTTPSを使用している

• 古いブラウザCookie — 以前のリダイレクト指示やセッションデータを含む古いCookieが、存在しなくなったURLや移動したURLへブラウザを強制する

• CDNまたはプロキシのキャッシュされたリダイレクト — CDNが現在のサーバー設定と競合する古い301リダイレクトをキャッシュしている

• サーバー設定の競合 — NginxまたはApacheの設定ファイルで、serverブロックと.htaccessの両方でリダイレクトするなど、競合するリダイレクトブロックがある

リダイレクトループの診断方法

修正を試みる前に、正確なリダイレクトチェーンを特定しましょう。これにより、どのURLが関与し、どのリダイレクトルールがループを引き起こしているかが正確にわかります。

方法1：curlでリダイレクトを追跡する

リダイレクトチェーンを確認する最速の方法は、ターミナルでcurlを使うことです。-Iフラグはヘッダーのみを取得し、-Lはリダイレクトを追跡し、--max-redirsは追跡する最大回数を制限します：

# Trace redirect chain (limit to 10 hops)
curl -ILs --max-redirs 10 https://example.com 2>&1 | grep -i 'HTTP/\|location:'

# Example output showing a redirect loop:
# HTTP/2 301
# location: http://example.com/
# HTTP/1.1 301 Moved Permanently
# Location: https://example.com/
# HTTP/2 301
# location: http://example.com/
# (repeats...)

Locationヘッダーで同じ2つのURLが交互に表示される場合、リダイレクトループが確認できます。HTTPステータスコードに注目してください — 301は恒久的リダイレクト（ブラウザにキャッシュされる）、302は一時的リダイレクト（キャッシュされない）です。

方法2：ブラウザのDevToolsネットワークタブ

Chrome DevToolsでリダイレクトを視覚的に追跡することもできます：

• ステップ1 — Chrome DevToolsをF12またはCtrl+Shift+I（Mac: Cmd+Option+I）で開く

• ステップ2 — Networkタブに移動し、Preserve logにチェックを入れる（リダイレクト間のログを保持します）

• ステップ3 — エラーが発生するページを読み込む

• ステップ4 — リクエストの順序を確認する。各リダイレクトはステータス301または302の別々のエントリとして表示されます。Location列に各リダイレクト先が表示されます

Networkタブはリダイレクトチェーン全体を時系列で表示します。通常、2つまたは3つのURLがサイクルで繰り返されるパターンが見えます。DNS RobotのHTTPヘッダーチェッカーを使用して、ブラウザキャッシュの外からレスポンスヘッダーを確認できます。

方法3：オンラインリダイレクトチェッカー

ターミナルにアクセスできない場合は、DNS Robotのリダイレクトチェッカーを使用してリダイレクトチェーン全体を追跡できます。URLを入力すると、すべてのホップ、ステータスコード、最終目的地が表示されます — またはループの存在が確認されます。ブラウザCookieの影響を受けない中立的な場所からチェックするため便利です。

修正1：ブラウザのCookieとキャッシュをクリアする

最もシンプルな修正から始めましょう。ブラウザ内の古いCookieやキャッシュされたリダイレクトは、サーバー設定が正しい場合でもループを引き起こすことがあります。特に、サイトがHTTPからHTTPSに移行した後に多く見られます — 古いCookieがまだHTTP URLを参照している場合があります。

ChromeでCookieをクリアする

すべてのCookieではなく、特定のサイトのCookieをクリアしましょう — これにより他のサイトのログイン状態が保持されます：

• ステップ1 — アドレスバーのURL横にある鍵アイコン（またはチューンアイコン）をクリック

• ステップ2 — サイトの設定をクリック

• ステップ3 — データを消去をクリックして、そのサイトのCookieとキャッシュデータのみを削除

• ステップ4 — ページを再読み込み

# Chrome keyboard shortcut to open Clear Browsing Data:
# Windows/Linux: Ctrl + Shift + Delete
# macOS: Cmd + Shift + Delete

または、chrome://settings/clearBrowserDataにアクセスし、Cookieと他のサイトデータとキャッシュされた画像とファイルを選択、期間を全期間に設定して「データを消去」をクリックします。

FirefoxとSafariでCookieをクリアする

Firefox: Ctrl+Shift+Delete（Mac: Cmd+Shift+Delete）を押し、Cookieとキャッシュを選択、期間をすべてに設定して今すぐ消去をクリックします。

Safari: Safari > 設定 > プライバシー > Webサイトデータを管理 で該当ドメインを検索し、選択して削除をクリックします。次にCmd+Option+Eでキャッシュをクリアします。

修正2：SSL/HTTPS設定を確認する

SSLの設定ミスはリダイレクトループの最大の原因です。最も一般的なシナリオは、CDN/プロキシとオリジンサーバーの間でHTTPとHTTPSのどちらを使用するかの競合です。

典型的な問題はこうです：CDNがHTTPでオリジンに接続（SSL終端を処理するため）しますが、オリジンにHTTPからHTTPSへのリダイレクトがあります。オリジンがCDNをHTTPSに送り返し、CDNがHTTPSを除去して再びHTTPを送信 — 無限ループとなります。

• SSL証明書を確認 — DNS RobotのSSLチェッカーを使用して、証明書が有効で期限切れではなく、正しいドメインをカバーしていることを確認する

• プロトコルを一致させる — CDNがSSLを終端する場合、オリジンのHTTPからHTTPSへのリダイレクトを削除するか、CDNがHTTPSでオリジンに接続するよう設定する

• HTTPS強制設定を確認 — サーバーレベルのリダイレクト（Nginx/Apache）とCDNレベルのHTTPS強制の両方がある場合、どちらかを削除する

• X-Forwarded-Protoヘッダーを確認 — プロキシの背後にある場合、オリジンは元のリクエストがHTTPSだったかどうかを判断するために、生の接続プロトコルではなくこのヘッダーを確認する必要がある

修正3：Cloudflareのリダイレクトループを修正する

CloudflareはERR_TOO_MANY_REDIRECTSの最も一般的なトリガーです。SSLモードの動作方法が原因です。修正方法は、使用しているSSL/TLS暗号化モードによって異なります。

Cloudflareリダイレクトループの90%の修正方法：SSL/TLS暗号化モードをFlexibleからFullまたはFull (Strict)に変更します。これにより、CloudflareがHTTPSでオリジンに接続するようになり、HTTPからHTTPSのループが解消されます。

Cloudflare修正のステップバイステップ

• ステップ1 — Cloudflareダッシュボードにログイン

• ステップ2 — ドメインを選択

• ステップ3 — SSL/TLS > Overviewに移動

• ステップ4 — オリジンに有効なSSL証明書がある場合は暗号化モードをFull (Strict)に、自己署名証明書の場合はFullに変更

• ステップ5 — SSL/TLS > Edge Certificatesに移動し、Always Use HTTPSが有効か確認。オリジンが既にHTTPSにリダイレクトしている場合は、二重リダイレクトを避けるためにこれを無効にする

• ステップ6 — Page RulesとRedirect Rulesで競合するURLリダイレクトがないか確認

• ステップ7 — Cloudflareキャッシュをパージ：Caching > Configuration > Purge Everything

修正4：.htaccessのリダイレクトルールを修正する（Apache）

Apacheサーバーでは、.htaccessがリダイレクトルールの最も一般的な場所であり、リダイレクトループが発生する最も一般的な原因です。競合するルール、重複するリダイレクト、条件チェックの欠如がすべてループを引き起こす可能性があります。

• 重複したHTTPSリダイレクトを確認 — ホスティングパネル（cPanel、Plesk）がHTTPSを強制している場合、.htaccessの手動リダイレクトを削除する

• RewriteCond条件を確認 — リダイレクトするすべてのRewriteRuleには、既に一致するURLでは発火しないようにするRewriteCondが必要。これがないと、リダイレクトされたリクエストを含むすべてのリクエストでルールが発火する

• [L]フラグに注意 — [L]フラグは「最後のルール」を意味しますが、現在のパスのみです。サブディレクトリに別の.htaccessがある場合、再度実行されます。Apache 2.4+では代わりに[END]を使用する

• プロキシヘッダーを確認 — CDNの背後では、元のプロトコルを検出するために%{HTTPS}の代わりに%{HTTP:X-Forwarded-Proto}を使用する

# Correct HTTPS redirect behind Cloudflare/CDN:
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

どのルールがループを引き起こしているかわからない場合は、一時的に.htaccessを.htaccess.bakにリネームしてサイトが読み込まれるかテストしてください。読み込まれた場合、問題は.htaccessファイルにあります。ルールを1つずつ再有効化して、問題のルールを特定してください。

修正5：WordPressのリダイレクトループを修正する

WordPressのリダイレクトループは通常、設定でのURL不一致、プラグインの競合、またはwp-config.phpの値の誤りの3つが原因です。リダイレクトループのせいでWordPressダッシュボードにアクセスできない場合は、データベースまたは設定ファイルを直接修正する必要があります。

WordPressのURL設定を確認する

WordPressには一致する必要がある2つのURL設定があります：設定 > 一般のWordPressアドレス（URL）とサイトアドレス（URL）です。一方がhttp://でもう一方がhttps://を使用している場合、または一方にwww.があってもう一方にない場合、リダイレクトループが発生します。

ダッシュボードにアクセスできない場合は、wp-config.phpでURLをハードコードします：

// Add these lines to wp-config.php (above "That's all, stop editing!"):
define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');

// If behind a reverse proxy (Cloudflare, Nginx proxy):
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

プラグインを無効にして競合を見つける

リダイレクトやキャッシュのプラグインが原因となることが多いです。Redirection、Yoast SEO、Really Simple SSL、WP Super Cache、W3 Total Cacheなどのプラグインは、サーバーやCDN設定と競合するリダイレクトルールを追加する可能性があります。

ダッシュボードにアクセスできない場合は、FTPまたはSSHですべてのプラグインを無効にします：

# Rename the plugins folder to disable all plugins at once:
cd /var/www/html/wp-content/
mv plugins plugins.bak

# If the site loads, rename it back and disable plugins one by one:
mv plugins.bak plugins
# Then rename individual plugin folders to find the culprit:
mv plugins/really-simple-ssl plugins/really-simple-ssl.bak

プラグインを無効にしてエラーが解消された場合、1つずつ再有効化して競合するプラグインを特定します。最も一般的な原因は、サーバーやCDNが既に処理しているHTTPからHTTPSへのリダイレクトを追加するSSLプラグインです。

修正6：サーバーレベルのリダイレクトを修正する（Nginx & Apache）

サーバー設定ファイルには、アプリケーションレベルのリダイレクト（WordPress、.htaccess）やCDN設定と競合するリダイレクトルールが含まれている場合があります。

Nginx：リダイレクトの競合を確認する

Nginxのリダイレクトループは、HTTPサーバーブロックがHTTPSにリダイレクトするが、HTTPSブロック内の何かがHTTPに戻すリダイレクトをする場合に発生します。サイトの設定を確認してください：

# Correct Nginx HTTPS redirect (separate server blocks):
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;
    # SSL certificate configuration here
    # DO NOT add another redirect to HTTPS here
}

# If behind Cloudflare/proxy, check real protocol:
server {
    listen 80;
    server_name example.com;
    if ($http_x_forwarded_proto != 'https') {
        return 301 https://example.com$request_uri;
    }
}

Apache：VirtualHostのリダイレクトを確認する

Apacheでは、VirtualHost設定と.htaccessの両方を確認してください。VirtualHost設定のリダイレクトと.htaccessのリダイレクトが重なると、ループする可能性のある二重リダイレクトが発生します：

# Check Apache config for redirect rules:
grep -r 'Redirect\|RewriteRule' /etc/apache2/sites-enabled/
grep -r 'Redirect\|RewriteRule' /etc/httpd/conf.d/

# Check .htaccess:
cat /var/www/html/.htaccess | grep -i 'rewrite\|redirect'

重複するリダイレクトを削除してください — リダイレクトは1箇所だけに保ちます。ベストプラクティスは、HTTPSリダイレクトをVirtualHost設定で処理することです（.htaccessではなく）。VirtualHostルールはリクエストごとに1回処理されますが、.htaccessはすべてのリクエストで処理されるためです。

修正7：ブラウザ別のトラブルシューティング

エラーが1つのブラウザでのみ表示される場合、問題はサーバーの問題ではなく、キャッシュされたリダイレクトまたは拡張機能の競合である可能性が高いです。

Chrome：HSTSとソケットプールをクリアする

Chromeは、HTTPSを強制するHSTS（HTTP Strict Transport Security）ポリシーをキャッシュします。以前サイトがHSTSヘッダーを送信していたが、現在HTTPSを正しく使用していない場合、Cookieをクリアした後もChromeはHTTPSにリダイレクトし続けます。

• HSTSキャッシュをクリア — chrome://net-internals/#hstsにアクセスし、Delete domain security policiesにドメインを入力してDeleteをクリック

• ソケットプールをフラッシュ — chrome://net-internals/#socketsにアクセスし、Flush socket poolsをクリックしてキャッシュされた接続をクリア

• DNSキャッシュをクリア — chrome://net-internals/#dnsにアクセスし、Clear host cacheをクリック

• シークレットモードでテスト — シークレットウィンドウ（Ctrl+Shift+N）を開いてURLを試す。シークレットモードで動作するが通常のウィンドウでは動作しない場合、キャッシュされたリダイレクトまたは拡張機能が原因

FirefoxとSafariの修正

Firefox: アドレスバーにabout:configと入力し、network.http.redirection-limitを検索して20（デフォルト）に設定されていることを確認します。拡張機能がこの値を非常に低い数値に変更した場合、リダイレクトが早期に失敗する場合があります。サイトデータのクリアも試してください：設定 > プライバシーとセキュリティ > データを管理 > ドメインを検索 > 選択したものを削除。

Safari: Safariは「too many redirects occurred」と表示し、Chromeよりも詳細でないエラーメッセージを提供します。Safari > 設定 > プライバシー > Webサイトデータを管理でドメインを見つけてデータを削除します。問題が解決しない場合は、Safari > 履歴を消去（すべての履歴を選択）を試してください。

リダイレクトループを防ぐ方法

当面のエラーを修正したら、リダイレクトループの再発を防ぐために以下のプラクティスに従ってください：

• リダイレクトは1箇所だけで行う — HTTPSリダイレクトは、CDN、Webサーバー、またはアプリケーションの1つの層だけで行います。複数の層で同時にリダイレクトしないでください

• テスト中は302を使用 — デバッグ中は301（恒久的）ではなく302（一時的）リダイレクトを使用します。ブラウザは301を積極的にキャッシュするため、変更のテストが困難になります。リダイレクトが正しく動作することを確認してから301に切り替えてください

• 常にcurlでテスト — リダイレクトルールを追加した後、curl -ILs https://yoursite.com | grep -i 'HTTP/\|location:'を実行して、リダイレクトチェーンが最終的に200レスポンスで解決することを確認する

• ツールで監視する — DNS RobotのHTTPヘッダーチェッカーを定期的に使用して、サイトが予期しないリダイレクトなしにクリーンな200レスポンスを返していることを確認する

• リダイレクトを文書化する — サーバー設定、.htaccess、CDNルール、アプリケーション設定にわたるすべてのリダイレクトルールを記録する。複数のチームメンバーがサイトを管理する場合、文書化されていないリダイレクトがループの最大の原因です

• 変更後はCDNキャッシュをパージ — リダイレクトルールを変更した後は、すぐにCDNキャッシュをパージする。キャッシュされた古い301は数日間持続する可能性があります

リダイレクトループのSEOへの影響

リダイレクトループは検索ランキングに直接悪影響を与えます。Googleのクローラー（Googlebot）はURLごとに最大10回のリダイレクトを追跡した後に中断します。Googlebotがリダイレクトループに遭遇すると、そのページをクロールエラーとしてマークし、インデックス登録を停止します。

リダイレクトに関するGoogleのドキュメントによると、リダイレクトチェーンはできるだけ短くすべきです。余分なリダイレクトホップごとに約100〜500msのレイテンシが追加され、クロールバジェット（Googleがあなたのサイトで1日にクロールするページ数）が消費されます。

• インデックスの損失 — リダイレクトループに陥ったページはインデックスされず、検索結果から完全に消えます

• クロールバジェットの浪費 — Googlebotが限られたクロールバジェットを実際のコンテンツのクロールではなくリダイレクトの追跡に費やします

• ページ速度のペナルティ — 各301リダイレクトはフルラウンドトリップ（100〜500ms）を追加します。3つのリダイレクトで読み込み時間が1秒以上増加する可能性があります

• リンクエクイティの希薄化 — リダイレクトURLを指すバックリンクは、ホップごとにPageRank値の約1〜5%を失います

よくある質問