ERR_TOO_MANY_REDIRECTSエラーの解決方法（発生原因と対策）

TL;DR: クイックリカバリ・チェックリスト

サイトをすぐにオンラインに戻す必要がある場合は、以下の手順を順番に試してください。

サイトのクッキーを削除する： 履歴全体を消去する必要はありません。特定のドメインのクッキーのみを削除して、ページを更新してください。
CloudflareのSSL設定を確認する： Cloudflareを使用している場合は、SSL/TLS設定を「Flexible」から「Full」に変更してください。これでリダイレクトループの約80%が解決します。
プラグインを無効化する： WordPressを使用している場合は、FTP経由で /wp-content/plugins フォルダを /plugins_old にリネームし、サイトが読み込まれるか確認してください。
.htaccess または Nginx の設定を監査する： HTTPとHTTPSを同時に強制するような、矛盾したルールがないか確認してください。

リダイレクトループとは一体何か？

このエラーは、デジタル版の「あっちが言った、こっちが言った」の状態だと考えてください。ブラウザが、URL AはURL Bへ行くように指示し、URL BはURL Aに戻るように指示するというループに陥っています。Chromeなどの最近のブラウザは、この「ピンポン」を20回試行した後、CPUの暴走を防ぐために諦めて ERR_TOO_MANY_REDIRECTS 画面を表示します。

1. 「Flexible SSL」の罠

これは現在、ループが発生する主な原因です。CloudflareのようなCDNで「Flexible」設定を使用している場合、CDNはサーバーとプレーンなHTTP（ポート80）で通信します。サーバー側ですべてのHTTPトラフィックをHTTPSに自動リダイレクトするように設定されていると、ブラウザをCDNに送り返します。CDNは依然としてHTTPを使用すべきだと考え、再びサーバーにリクエストを送ります。このループが永遠に繰り返されます。

2. サーバーディレクティブの競合

.htaccess (Apache) や nginx.conf などのサーバー設定ファイルは強力ですが、デリケートです。たった1行の記述ミスで、www ありと www なしのバージョン間、あるいはHTTPとHTTPSプロトコル間で競合が発生することがあります。

3. CMSの設定エラー

WordPressはサイトのホームURLとサイトURLをデータベースに保存しています。これらが http://example.com に設定されている一方で、サーバーが https:// を強制している場合、アプリケーションとサーバーの間で使用するプロトコルを巡って競合が発生します。

ステップバイステップの解決策

解決策1：Curlでチェーンを検査する

設定を変更し始める前に、サーバーが実際に何を行っているかを確認しましょう。これにはブラウザは不要です。ターミナルを開き、以下を実行してください：

curl -IL https://yourwebsite.com

出力を確認してください。HTTP/1.1 301 Moved Permanently レスポンスが長く続き、その後に同じURLが何度も表示される場合は、ローカルマシンではなくサーバー側でループが発生していることが確認できます。

解決策2：Cloudflareとオリジンサーバーを同期させる

Cloudflareを使用している場合、通常はワンクリックで解決します：

Cloudflareのダッシュボードにログインします。
SSL/TLS > Overview（概要）に移動します。
暗号化モードを Full または Full (Strict) に切り替えます。

これにより、CloudflareはHTTPS（ポート443）経由でサーバーと通信するようになります。オリジンサーバーにSSL証明書がインストールされていることを確認してください。無料の Let's Encrypt や自己署名証明書でも動作します。

解決策3：Nginx設定のクリーンアップ

通常 /etc/nginx/sites-available/ にあるサイトの設定ファイルを確認してください。よくある間違いは、すでにポート443をリスンしているブロック内に汎用的なリダイレクトを配置してしまうことです。

# 間違った方法（ループの原因）
server {
    listen 443 ssl;
    server_name example.com;
    return 301 https://example.com$request_uri;
}

代わりに、役割を分けましょう。HTTPからHTTPSへのジャンプ用に1つのブロックを使用し、実際のサイトコンテンツ用にもう1つのブロックを使用します：

# 正しい方法
server {
    listen 80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;
    # 実際のサイトロジックをここに記述
}

解決策4：WordPress URLをハードコードする

ループのせいで /wp-admin ダッシュボードにログインできない場合は、手動でデータベース設定を上書きできます。wp-config.php ファイルの「That's all, stop editing!」というコメントの直前に、以下の2行を追加してください：

define('WP_HOME','https://example.com');
define('WP_SITEURL','https://example.com');

予防策とベストプラクティス

複雑なネットワークやVPCを管理している場合、ロードバランサーとオリジンサーバーの間でトラフィックが誤ってルーティングされがちです。私はファイアウォールルールを設定する際、CIDRブロックを再確認するために ToolCraftのサブネット計算機をよく利用します。IPレンジを整理しておくことで、プロキシレイヤーが誤ってSSLヘッダーを削除したり、トラフィックを間違ったゲートウェイにルーティングしたりするのを防ぐことができます。

新しいリダイレクトルールをテストするときは、常に 302 (Temporary) ステータスコードを使用してください。ブラウザは 301 (Permanent) リダイレクトを非常に強力にキャッシュします。誤って301でループを作成してしまうと、サーバー側のコードを修正した後でもブラウザがリダイレクトし続ける可能性があります。すべてが正常に動作することをシークレットウィンドウで確認してから、301に切り替えてください。

最終確認

問題が完全に解決したか確認するには、ブラウザのデベロッパーツール（F12）を開き、Network（ネットワーク）タブに移動します。「Disable Cache」（キャッシュを無効化）にチェックを入れ、ページをリロードしてください。正常な 200 OK ステータスが表示されるはずです。1つの 301 リダイレクトの後に 200 OK が続く場合は、全く問題ありません。それはHTTPからHTTPSへのリダイレクトが意図通りに動作していることを意味します。