ERR_TOO_MANY_REDIRECTSの意味と原因、解決方法（Chrome・Gmail）

ERR_TOO_MANY_REDIRECTSとは？

ERR_TOO_MANY_REDIRECTSは、ページが一度も読み込まれないまま、ブラウザが20回を超えて別のアドレスへ転送された（リダイレクトループに陥った）という意味です。 Chromeでは「このページは動作していません」「example.com でリダイレクトが繰り返し行われました。」と表示され、Firefoxでは「ページの自動転送設定が正しくありません」、Safariでは「ページを開けません」「多くのリダイレクトが発生しています」と表示されます。

サイトを見ているだけなら、そのサイトのCookieを削除して再読み込みしてください。ほかの人には普通に表示されているなら、原因はたいてい古いCookieです。自分のサイトで起きている場合、原因はほぼ必ず、HTTPS（またはwww）への転送を2か所で同時に強制していることで、最も多いのはCloudflareのFlexible SSLモードとサーバー側のHTTPSリダイレクトの組み合わせです。

どのブラウザでも上限が同じなのは、各ブラウザが実装しているFetch Standardに「リクエストのリダイレクト回数が20なら、ネットワークエラーを返す」と定められているためです。ループ自体はたいてい、互いを指し合う2つの301または302レスポンスです。URL AがURL Bへ、URL BがURL Aへ送り返し、ブラウザは20回目で数えるのをやめます。

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

リダイレクトループは、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とサーバーの間で無限ループが発生します
• 競合する.htaccessルール — .htaccess内の複数のリダイレクトルールが矛盾している場合（例：一方がwwwを強制し、もう一方が同時にwwwなしを強制する）
• WordPressのURL不一致 — 設定 > 一般のWordPressアドレス（URL）とサイトアドレス（URL）が一致しない、または一方がHTTPでもう一方がHTTPSを使用している
• 古いブラウザCookie — 以前のリダイレクト指示やセッションデータを含む古いCookieが、存在しなくなったURLや移動したURLへブラウザを強制する
• CDNまたはプロキシのキャッシュされたリダイレクト — CDNが現在のサーバー設定と競合する古い301リダイレクトをキャッシュしている
• サーバー設定の競合 — NginxまたはApacheの設定ファイルで、serverブロックと.htaccessの両方でリダイレクトするなど、競合するリダイレクトブロックがある
• アプリのログインループ — ログアウト状態の訪問者を自分自身にリダイレクトしてしまうログインページや、ブラウザが保存を拒否するセッションCookie（OAuth、Supabase Auth、NextAuth）。修正8を参照

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

修正を試みる前に、正確なリダイレクトチェーンを特定しましょう。これにより、どの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が交互に表示されていれば、リダイレクトループが確定です。ステータスコードにも注目してください。301はブラウザがキャッシュする恒久的なリダイレクト、302は一時的なリダイレクトで、レスポンスで指定されない限りキャッシュされません。

各Locationヘッダーのスキームも確認してください。同じURLのhttp://版とhttps://版の間で起きるループが最も多いパターンで、SSLの設定が原因だとすぐにわかります。

方法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：オンラインリダイレクトチェッカー

ターミナルが使えない場合は、URLをDNS Robotのリダイレクトチェッカーに貼り付けてください。当サーバーからすべてのホップをたどって各ステータスコードとLocationヘッダーを表示し、チェーンが元に戻ってループしている場合はそう知らせます。あなたのブラウザのCookieを使わずに確認するので、ループの原因がサイト側にあるのか、あなたのブラウザ側にあるのかがすぐにわかります。

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

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

ChromeでCookieをクリアする

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

• ステップ1 — アドレスバーのURL横にある鍵アイコン（またはチューンアイコン）をクリック
• ステップ2 — サイトの設定をクリック
• ステップ3 — データを削除をクリックして、そのサイトのCookieとキャッシュデータのみを削除
• ステップ4 — ページを再読み込み

# Chrome keyboard shortcut to open Delete browsing data:
# Windows/Linux: Ctrl + Shift + Delete
# macOS: Cmd + Shift + Delete

すべてのサイトのデータをまとめて消す場合は、Ctrl+Shift+Delete（Mac: Cmd+Shift+Delete）を押して閲覧履歴データを削除を開き、Cookie と他のサイトデータとキャッシュされた画像とファイルにチェックを入れ、期間で全期間を選んでデータを削除をクリックします。

FirefoxとSafariでCookieをクリアする

Firefox: Ctrl+Shift+Delete（Mac: Cmd+Shift+Delete）を押し、Cookie とサイトデータと一時的にキャッシュされたファイルとページにチェックを入れ、期間をすべての履歴にして消去をクリックします。

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

Cookieを削除して直った場合は、サーバー側のリダイレクトルールが最近変わったのに、ブラウザに古い状態が残っていたということです。新しいセッションで訪れる人には、このエラーが一度も表示されないこともあります。

Gmail・Googleドライブ・accounts.google.comで「リダイレクトが繰り返し行われました」と出る場合

Chromeに「このページは動作していません」「accounts.google.com でリダイレクトが繰り返し行われました。」「Cookie を削除してみてください」と表示されるなど、メッセージにaccounts.google.com、mail.google.com、drive.google.comが出ている場合、ループはGoogleのログインページとブラウザのCookieの間で起きていて、ウェブサイトの故障ではありません。GoogleのログインはブラウザがGoogleのCookieを保存できるときにしか機能しないため、Cookieをブロックしたり書き換えたりするものがあると、同じページを延々と行き来することになります。

• GoogleのCookieだけを削除する — chrome://settings/content/all（すべてのサイトデータと権限を表示）を開き、google.comを検索してデータを削除してから、もう一度ログインします。Googleのヘルプにあるとおり、削除後はそのブラウザでGoogleアカウントにもう一度ログインする必要があります
• GoogleにCookieを許可する — Cookieの使用を許可しないサイトのリストにgoogle.comが入っていれば外します。サードパーティCookieをブロックしている場合は、[*.]google.comをCookieの使用を許可するサイトに追加してください（Chrome: 設定 → プライバシーとセキュリティ → サードパーティ Cookie）
• すべてのアカウントからログアウトし、1つだけでログインし直す — 複数のアカウントで同時にログインしていたり、会社独自のログインページにログインを引き継ぐ仕事用アカウントを使っていたりすると、その2つの間を行き来することがあります
• Cookieやプライバシー関連の拡張機能をオフにする — ログイン中にCookieを削除したり書き換えたりする拡張機能はよくある原因です。Chromeでは許可しない限りシークレット モードで拡張機能が動かないので、まずシークレット ウィンドウで試してください

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

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

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

同じ構成で証明書に問題がある場合は、別のエラーが表示されます。ERR_SSL_PROTOCOL_ERRORや「この接続ではプライバシーが保護されません」を参照してください。

• SSL証明書を確認 — DNS RobotのSSLチェッカーを使用して、証明書が有効で期限切れではなく、正しいドメインをカバーしていることを確認する
• プロトコルを一致させる — CDNがSSLを終端する場合、オリジンのHTTPからHTTPSへのリダイレクトを削除するか、CDNがHTTPSでオリジンに接続するよう設定する
• HTTPS強制設定を確認 — サーバーレベルのリダイレクト（Nginx/Apache）とCDNレベルのHTTPS強制の両方がある場合、どちらかを削除する
• X-Forwarded-Protoヘッダーを確認 — プロキシの背後にある場合、オリジンは元のリクエストがHTTPSだったかどうかを判断するために、生の接続プロトコルではなくこのヘッダーを確認する必要がある

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

Cloudflareが最も多い原因になるのは、暗号化モードによって、Cloudflareがサーバーに接続する方式がHTTPになるかHTTPSになるかが決まるためです。Cloudflareのトラブルシューティングページ（2026年9月更新）は、ループを起こす設定を5つ挙げています。いずれも、オリジンサーバー側の設定との組み合わせでループします。

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

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

• ステップ1 — Cloudflareダッシュボードにログイン
• ステップ2 — ドメインを選択
• ステップ3 — SSL/TLS > Overviewに移動
• ステップ4 — オリジンに有効な証明書がある場合は、暗号化モードをFull (strict)に変更します（無料のCloudflare Origin CA証明書も有効な証明書に含まれます）。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;
    }
}

編集後はnginx -tで構文エラーがないか確認し、systemctl reload nginxでダウンタイムなしに変更を反映します。

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をクリック（ほかの方法はDNSキャッシュをクリアする方法を参照）
• シークレットモードでテスト — シークレットウィンドウ（Ctrl+Shift+N）を開いてURLを試す。シークレットモードで動作するが通常のウィンドウでは動作しない場合、キャッシュされたリダイレクトまたは拡張機能が原因

FirefoxとSafariの修正

Firefox: アドレスバーにabout:configと入力し、network.http.redirection-limitを検索して20（デフォルト）になっていることを確認します。手動や企業ポリシーでこれより小さい値に設定されていると、リダイレクトが早い段階で失敗します。サイトデータのクリアも試してください：設定 > プライバシーとセキュリティ > データを管理 > ドメインを検索 > 選択したサイトデータを削除。

Safari: Safariでは「ページを開けません」「多くのリダイレクトが発生しています」と表示され、Web Inspectorのコンソールには「Load cannot follow more than 20 redirections」と出ます。「Safari」>「設定」>「プライバシー」>「ウェブサイトデータを管理」で該当ドメインを探し、データを削除してください。それでもループする場合はプライベートウインドウで試します。そこでもループするなら、サイト側の設定に問題があります。

修正8：Webアプリのログインリダイレクトループ

Webアプリでは、ループの原因が自分のコードにあることがよくあります。ログインが必要なページが/loginにリダイレクトし、何かが/login（またはログインのコールバック）をすぐに送り返している状態です。ブラウザのコンソールでは、失敗したリクエストにnet::ERR_TOO_MANY_REDIRECTSと表示されます。

• ログインページまで保護されている — すべてのルートで動く認証ミドルウェアが、/loginやコールバックのルートまで/loginにリダイレクトしています。これらはチェックの対象から外してください
• セッションCookieが保存されない — SameSite=Noneを付けたCookieはSecureも付けないとブラウザに破棄され、間違ったドメインに設定したCookieは送り返されません。どちらの場合も、すべてのリクエストがログアウト状態のように見えます
• コールバックURLが一致しない — プロバイダー（Google、GitHub、Supabase Auth）が、アプリで処理していないコールバックにユーザーを送り、そのルートが再びログインへリダイレクトしています
• プロキシの背後でのHTTPとHTTPS — アプリがX-Forwarded-Protoを無視しているため、リダイレクト先のURLをhttp://で組み立てています。修正2のループが1つ上の層で起きている状態です

// Next.js: proxy.ts (middleware.ts before Next.js 16).
// Never run the sign-in check on the sign-in pages themselves.
export const config = {
  matcher: ["/((?!login|auth/callback|_next/static|_next/image|favicon.ico).*)"],
};

修正できたかどうかは、ログアウトした状態でリダイレクトチェッカーかcurl -ILを使って確認してください。正常なチェーンは、さらにリダイレクトするのではなく、ログインページの200で終わります。

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

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

• リダイレクトは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は数日間持続する可能性があります

健全なチェーンのホップは多くても1〜2回です（例：HTTP → HTTPS → 200 OK）。3回以上ある場合は、たいてい不要になったリダイレクトが残っています。

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

リダイレクトループが起きると、そのページは検索結果から消えます。Googleのクロールに関するドキュメントによると、Googleのクローラーは「最大10回のリダイレクトホップをたどります」。ループはコンテンツにたどり着かないため、Search Consoleにはリダイレクトエラーとして報告され、ループが直るまでそのURLはインデックスから外れます。

最終的にページへたどり着くチェーンでも、長いと負担になります。ホップのたびに、ページを読み込む前にブラウザとGooglebotが追加のリクエストを送る必要があるため、リンクやリダイレクトは最終的なURLを直接指すようにしてください。

• インデックスの損失 — リダイレクトループに陥ったページはインデックスされず、検索結果から完全に消えます
• クロールバジェットの浪費 — Googlebotが限られたクロールバジェットを実際のコンテンツのクロールではなくリダイレクトの追跡に費やします
• ページの表示が遅くなる — ホップのたびに、コンテンツが表示される前のリクエストと往復が1回ずつ増えます。別のホストへのホップでは新しい接続も必要です