2026年8月3日

WordPressの「リダイレクトが多すぎます（ERR_TOO_MANY_REDIRECTS）」を直す方法｜原因の見分け方と修正手順

エラー・白い画面

「リダイレクトが多すぎます（ERR_TOO_MANY_REDIRECTS）」は、2つ以上の仕組みが互いに逆向きの転送をかけ合い、ループしている状態です。直し方は原因によって異なるため、最初にcurlでリダイレクトの連鎖を見て、何と何がぶつかっているかを特定するのが近道です。この記事では、連鎖の読み方、WordPressのURL設定、SSL化とリバースプロキシ・Cloudflare、.htaccess、プラグインの順に、確認方法と修正手順を説明します。

まずブラウザ側の要因を切り分ける

ブラウザは301リダイレクトをキャッシュし、Cookieも保持しています。サーバー側を直したのに症状が残る、あるいは自分だけ症状が出る、という場合はこれが原因のことがあります。

シークレットウィンドウ（プライベートウィンドウ）で同じURLを開く
症状が出るサイトのCookieとキャッシュだけを削除する
スマートフォンのモバイル回線など、別の環境から開く

シークレットウィンドウで正常に表示されるなら、サーバーはすでに直っていて、手元のキャッシュが古い転送を覚えているだけです。どの環境でもループする場合は、次の手順に進みます。

curlでリダイレクトの連鎖を見る

ループの正体は、転送先のURL（Locationヘッダー）を順に並べると見えてきます。手元のPCやサーバーで次を実行します。

# 最大10回まで転送をたどり、ステータスと転送先だけを表示する
curl -sIL --max-redirs 10 https://example.com/ | grep -iE '^(HTTP|location)'

出力の並び方で、原因の見当がつきます。

http:// と https:// が交互に出る：SSL化の設定がどこかで食い違っている（HTTPS判定、Cloudflare、.htaccess の二重設定など）
www. ありとなしが交互に出る：WordPressのURL設定と、サーバーやDNS側のwww統一の向きが逆
同じURLに何度も転送される：プラグインのリダイレクト設定、またはキャッシュされた転送
/wp-admin/ と /wp-login.php の間を行き来する：管理画面のSSL判定かログインCookieの問題

レスポンスヘッダーに server: cloudflare や x-redirect-by: WordPress が出ていれば、転送を出しているのが誰かも分かります。x-redirect-by はWordPressの wp_redirect() が付けるヘッダーで、プラグインによっては独自の値を入れています。このヘッダーがない転送は、Webサーバーや .htaccess、CDNなどWordPressの外で発生している可能性が高いと考えられます。

WordPressのURL設定を確認する

「設定」→「一般」の「WordPressアドレス（URL）」と「サイトアドレス（URL）」は、データベースの siteurl と home に保存されています。ここが実際のURLと違うと、WordPressは自分が正しいと考えるURLへ訪問者を転送します。特にwwwの有無は、WordPressがリクエストされたホスト名を home に合わせて転送するため、サーバー側の統一方向と逆だとループします。

管理画面に入れない場合は、WP-CLIで確認と修正ができます。プラグインが原因の可能性もあるので、プラグインとテーマを読み込まずに実行するのが安全です。

wp option get home --skip-plugins --skip-themes
wp option get siteurl --skip-plugins --skip-themes

# 実際に使うURLに合わせる（作業前にデータベースのバックアップを取る）
wp option update home 'https://example.com' --skip-plugins --skip-themes
wp option update siteurl 'https://example.com' --skip-plugins --skip-themes

WP-CLIが使えない場合は、wp-config.php の /* 編集が必要なのはここまでです */ より上に次の2行を書くと、データベースの値より優先されます。

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

この定数を書くと、管理画面の該当欄はグレーアウトして変更できなくなります。ループが解消したら、データベース側の値も正しく直したうえで定数を削除するか、そのまま運用するかを決めてください。URLの末尾にスラッシュは付けません。

SSL化とHTTPS判定の食い違いを直す

http と https が交互に出る場合、多くは「PHPが自分はHTTPで受けていると誤解している」状態です。WordPressは is_ssl() でHTTPSかどうかを判定しますが、これは $_SERVER['HTTPS'] かポート443を見ています。

ロードバランサーやリバースプロキシの後ろにある場合

ロードバランサーやNginxのリバースプロキシでSSLを終端し、その後ろのWebサーバーへはHTTPで転送する構成では、PHPから見るとすべてのリクエストがHTTPです。この状態で FORCE_SSL_ADMIN やSSL化プラグインが「HTTPSへ転送せよ」と判断すると、プロキシ経由で再びHTTPとして届き、ループします。

プロキシが X-Forwarded-Proto ヘッダーを付けていることを確認したうえで、wp-config.php の require_once ABSPATH . 'wp-settings.php'; より前に次を書きます。

// 信頼できるプロキシの後ろにある場合のみ使う
if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && 'https' === $_SERVER['HTTP_X_FORWARDED_PROTO'] ) {
	$_SERVER['HTTPS'] = 'on';
}

このヘッダーはクライアントが自由に付けられるため、プロキシを通らずに直接Webサーバーへ届く経路がある構成では使わないでください。Nginxをプロキシにしている場合は、proxy_set_header X-Forwarded-Proto $scheme; が設定されているかも確認します。

Cloudflareを使っている場合

CloudflareのSSL/TLS暗号化モードが「フレキシブル」だと、訪問者とCloudflareの間はHTTPS、Cloudflareとサーバーの間はHTTPになります。サーバー側の .htaccess やレンタルサーバーの常時SSL化設定がHTTPSへ転送すると、Cloudflareはまたフレキシブル接続、つまりHTTPでサーバーにリクエストし、ループします。

この場合は、サーバーにSSL証明書を入れたうえで暗号化モードを「フル（厳密）」に変更するのが根本的な対策です（2026年10月現在の表記）。サーバー側の転送設定を外してフレキシブルのまま使う方法もありますが、Cloudflareとサーバーの間が暗号化されないため勧めません。

.htaccessの転送ルールを確認する

.htaccess にHTTPSやwww統一の転送を書いている場合、同じ目的のルールが二重になっていたり、レンタルサーバーのコントロールパネルの常時SSL化設定と重なっていたりすることがあります。編集前に .htaccess のバックアップを取り、転送ルールを見直します。

# HTTPS と non-www に統一する例（# BEGIN WordPress より上に書く）
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]

確認のポイントは次のとおりです。

転送先のホスト名（例では example.com）と、WordPressの home のホスト名が一致しているか
コントロールパネルの常時SSL化やwww設定と、.htaccess のルールが重複していないか
プロキシやCloudflareの後ろにある場合、%{HTTPS} はプロキシとの間の接続を見るため、常に off と判定されないか

切り分けのために転送ルールを一時的にコメントアウトするときは、ブラウザに301がキャッシュされないよう、テスト中は R=302 にしておくと後で混乱しません。# BEGIN WordPress から # END WordPress の間はWordPressが書き換える領域なので、独自のルールはその外に書きます。

プラグインを止めて切り分ける

SSL化プラグイン、リダイレクト管理プラグイン、多言語化プラグイン、キャッシュプラグインは、それぞれ独自に転送を出します。上記を確認しても原因が見えない場合は、プラグインをまとめて止めて様子を見ます。

# すべて無効化してループが止まるか確認
wp plugin deactivate --all --skip-plugins --skip-themes

# 1つずつ有効化して、ループが再発したものが原因
wp plugin activate your-plugin-slug --skip-themes

WP-CLIが使えない場合は、FTPやファイルマネージャーで wp-content/plugins フォルダの名前を一時的に変更すると、すべてのプラグインが読み込まれなくなります。確認後は名前を元に戻し、管理画面のプラグイン一覧から1つずつ有効化してください。

キャッシュプラグインやCDNが転送の応答そのものをキャッシュしていることもあります。設定を直した後は、プラグインのキャッシュとCDNのキャッシュを削除してから確認します。

管理画面だけでループする場合

フロントは表示できるのに、ログイン後に wp-login.php と wp-admin の間を行き来する場合は、前述のHTTPS判定の食い違いに加えて、ログインCookieが保存されていない可能性があります。wp-config.php に COOKIE_DOMAIN を独自に設定していてドメインと合っていない場合や、home と siteurl のホスト名が違う場合に起こりやすい症状です。Cookieを削除して再ログインし、それでも続くならこれらの設定を見直してください。

まとめ

まずシークレットウィンドウで、ブラウザのキャッシュとCookieの影響を切り分ける
curl -sIL でLocationの連鎖を見ると、http/https、www、プラグインのどれがぶつかっているか見当がつく
home と siteurl は実際のURLに合わせる。管理画面に入れなければWP-CLIか WP_HOME・WP_SITEURL 定数で直す
プロキシやCloudflareの後ろでは、PHPがHTTPSと判定できるようにするか、暗号化モードを「フル（厳密）」にする
.htaccess とコントロールパネルの転送設定の重複、プラグインの転送も確認する